From akatlas@gmail.com Mon Jul 4 09:40:17 2011 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 AEBF611E80B1 for ; Mon, 4 Jul 2011 09:40:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3aXYeIBTwca for ; Mon, 4 Jul 2011 09:40:17 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA7311E80AC for ; Mon, 4 Jul 2011 09:40:17 -0700 (PDT) Received: by pvh18 with SMTP id 18so6891357pvh.31 for ; Mon, 04 Jul 2011 09:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=Xz4vw/b5tOhg4DfJEmdd7Ze0NxOdtJE+7GoTJuvaPgY=; b=v5l0cCMNRael178fNRr01b3T6FklonhrgCzyKGwvM1sKBYufG/kVAaO1Gbwbaw/Rmy wW+ZmqR5iFmobiaXGAwxsMw0pPgLacDzlXS9iJbRxCK/J6CG9b7Z1PWtSvtzk+brX8cb cE7nrm4H/eVMkD86at3JJMV3OJUsXLHbLKdwY= MIME-Version: 1.0 Received: by 10.68.50.161 with SMTP id d1mr7582629pbo.439.1309797616725; Mon, 04 Jul 2011 09:40:16 -0700 (PDT) Received: by 10.68.64.195 with HTTP; Mon, 4 Jul 2011 09:40:16 -0700 (PDT) Date: Mon, 4 Jul 2011 12:40:16 -0400 Message-ID: Subject: IP/LDP Fast-Reroute with Maximally Redundant Trees From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 04 Jul 2011 16:40:17 -0000 We have submitted a new draft proposing a Fast-Reroute architecture based upon Maximally Redundant Trees. It is https://datatracker.ietf.org/doc/draft-atlas-rtgwg-mrt-frr-architecture/?include_text=1 . We'd appreciate any comments and feedback. Thanks, Alia (no-hat) From akatlas@gmail.com Wed Jul 6 13:53:20 2011 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 B9A5421F8BD1 for ; Wed, 6 Jul 2011 13:53:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DH0eAXhR7M-r for ; Wed, 6 Jul 2011 13:53:20 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD2021F8B2F for ; Wed, 6 Jul 2011 13:53:20 -0700 (PDT) Received: by pwj5 with SMTP id 5so273281pwj.31 for ; Wed, 06 Jul 2011 13:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=isrPSmed9E3/F5glG0JsI3D9fCpdy/yfD7W6qQJvPaA=; b=E1+aId19KwySl6T2q5NXkJH9zH7kV+lwImNq7MEQF9QHl119YkqitmjwMSca6uN5Nf zB0bRNrCLVfCi8DX/9Foi3RrrH4M7e5TRAV/e2eUx7gDXlqEmDeRKZX47reePd7eyXH9 ewAfP+Kup3z1wJTwIt6hGMM4eDapm8/fNaJuE= MIME-Version: 1.0 Received: by 10.68.48.74 with SMTP id j10mr49841pbn.37.1309985594067; Wed, 06 Jul 2011 13:53:14 -0700 (PDT) Received: by 10.68.64.195 with HTTP; Wed, 6 Jul 2011 13:53:12 -0700 (PDT) Date: Wed, 6 Jul 2011 16:53:12 -0400 Message-ID: Subject: Request for Agenda items for RTGWG From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 06 Jul 2011 20:53:20 -0000 We have a 2 hour slot on Thursday from 13:00 - 15:00. Please send requests for agenda items with time desired and presenters. Alvaro and I will need to have the presentations by Thursday at 9am to upload. Thanks, Alia From akatlas@gmail.com Wed Jul 6 13:57:13 2011 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 E81A221F89B6 for ; Wed, 6 Jul 2011 13:57:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQeb0Yao-UKQ for ; Wed, 6 Jul 2011 13:57:13 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB0A21F89AE for ; Wed, 6 Jul 2011 13:57:13 -0700 (PDT) Received: by pzk5 with SMTP id 5so391608pzk.31 for ; Wed, 06 Jul 2011 13:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=4BjGhbqDrLUqd/vQNuUCKOiFFKtfy+k1NnLS/y29t/A=; b=rdFRud1bdiiWNtG9t4l/ocfqe+O3nE6CoySTPFKcaCOvvaNtG0L/ezjF0yOVGMG1co 1SHSSm9A/GoRlrGobklJ2pMaTLJxs2BFCgrg9ghrAd5vH5YlCQmiLQRJNnsM2ekdBqDR 8yhabyHWnLwKjPO61WGKA5RtJUv0VhBznb17w= MIME-Version: 1.0 Received: by 10.68.10.98 with SMTP id h2mr17912pbb.372.1309985832753; Wed, 06 Jul 2011 13:57:12 -0700 (PDT) Received: by 10.68.64.195 with HTTP; Wed, 6 Jul 2011 13:57:12 -0700 (PDT) Date: Wed, 6 Jul 2011 16:57:12 -0400 Message-ID: Subject: discussion on fast notification work From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 06 Jul 2011 20:57:14 -0000 The last 2 IETFs, we have had discussions about the idea of fast notification, as described in draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and draft-csaszar-ipfrr-fn-00. Since then, I have not seen substantial discussion or interest on the mailing list. If you are interested in this work, have questions about it, or would like to see RTGWG continue to discuss it, please send email to this mailing list. I'd like to see this conversation happening here before IETF. Thanks, Alia From akatlas@gmail.com Wed Jul 6 14:19:57 2011 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 D787B21F8A93 for ; Wed, 6 Jul 2011 14:19:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KdKVm9rxU0P for ; Wed, 6 Jul 2011 14:19:57 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 656A421F8A8B for ; Wed, 6 Jul 2011 14:19:57 -0700 (PDT) Received: by pwj5 with SMTP id 5so297138pwj.31 for ; Wed, 06 Jul 2011 14:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=jOshxi93RCGGpkG4nDQOhKfveU6wBU9dqMDSNRa+1p4=; b=IKFe4fbp8a1SRcliSruPdRQy2IijXeDo5Are6GuAerfk5E2BH6YmKY/B9aA4LWxmTw 3MCIsRrs+0EnDOe64Uyxrovcyr0RrrjaMm3jyBOvIHlrQzhX5a1v3w/1rjbEQFBy23cO WwtsyThujmcVfMMe/cppFHyGhwtyECc+H1hC0= MIME-Version: 1.0 Received: by 10.68.58.2 with SMTP id m2mr49488pbq.305.1309987197079; Wed, 06 Jul 2011 14:19:57 -0700 (PDT) Received: by 10.68.64.195 with HTTP; Wed, 6 Jul 2011 14:19:57 -0700 (PDT) Date: Wed, 6 Jul 2011 17:19:57 -0400 Message-ID: Subject: draft-so-yong-rtgwg-cl-framework-04 : Make working group item? From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 06 Jul 2011 21:19:57 -0000 I would encourage everyone to read the most recent version of the draft-so-yong-rtgwg-cl-framework-04 and comment on it. Last IETF, we had the question of whether the previous version should become a WG draft. I would like to determine this on the mailing list and verify the conclusion at our RTGWG meeting. The Composite Link work is something that we've agreed to do as a WG. The draft-ietf-rtgwg-cl-requirement-04 will be going to WG Last Call very soon, so this is a good time to read both and comment. Eagerly looking forward to discussion, Alia From akatlas@gmail.com Wed Jul 6 14:30:36 2011 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 641A221F8B20 for ; Wed, 6 Jul 2011 14:30:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMb0o7BriOcZ for ; Wed, 6 Jul 2011 14:30:33 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0AC21F8B12 for ; Wed, 6 Jul 2011 14:30:09 -0700 (PDT) Received: by pzk5 with SMTP id 5so421340pzk.31 for ; Wed, 06 Jul 2011 14:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=W+Ox4nYaLgC45uYhKyIz1m55Iejx/UKO3Z1bCvpcfc8=; b=ZQrW2ohpvUNQI5BDNgHqtAVNtDmVqY7qzaZp7zUOt7hou8aO6L8nis/8QFiScl/TLj jysacqMT0/PUpHboiK2JbGmQ+eFTSbIkXUlurm7wG3WyGoI3tmq3/LmBHjkk11sue8eh s4HqGsxLf/TxKu9/5+yJ0PexGylBjywyQwii0= MIME-Version: 1.0 Received: by 10.68.48.74 with SMTP id j10mr88953pbn.37.1309987809079; Wed, 06 Jul 2011 14:30:09 -0700 (PDT) Received: by 10.68.64.195 with HTTP; Wed, 6 Jul 2011 14:30:09 -0700 (PDT) In-Reply-To: References: <14584D6EE26B314187A4F68BA206060007AF9AF1@ASHEVS008.mcilink.com> Date: Wed, 6 Jul 2011 17:30:09 -0400 Message-ID: Subject: Re: Requesting adoption as WG draft From: Alia Atlas To: "So, Ning" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 06 Jul 2011 21:30:36 -0000 Ning, I have read draft-so-yong-rtgwg-cl-framework-04 and was happy to see that there is more content about what is available in existing protocols and what is not. I do think this is an improvement. I would still prefer to see discussion of the trade-offs between different approaches in the framework draft. An example is around what is advertised for heterogeneous component links and the impact of crankback versus additional data to advertise. Tony Li gave a nice discussion of this a couple IETFs ago and the pros/cons would be good to capture. I understand that the protocol extensions are not yet defined; I tend to think of "for future study" as placing work out of scope rather than implying that it will be coming in companion solution documents. What would be useful is to provide criteria by which different solutions could be judged. I still don't see any such discussion in the draft. Alia On Tue, Jun 21, 2011 at 2:10 PM, Alia Atlas wrote: > I will read carefully the new version in the next week. > Any acceptance as a WG draft would be after querying the list, of course. > > That said, please read this updated draft and comment here. =A0It would b= e good > to get this done and a decision made before the next IETF. > > Alia > > > On Tue, Jun 21, 2011 at 1:28 PM, So, Ning w= rote: >> Dear WG chairs, >> >> >> >> Have you had a chance to look at the updated Composite Link Framework dr= aft >> (draft-so-yong-rtgwg-cl-framework-04)?=A0 Alia made the comment in last = IETF >> meeting that this draft is likely to be adopted as WG draft, because the >> Composite Link Requirement has already passed WG last call.=A0 Just want= to >> check and see when will you have some time to make the announcement. >> =A0=A0Thanks a lot. >> >> >> >> >> >> Best regards, >> >> >> >> Ning So >> >> Network Evolution Planning >> >> Verizon, Inc. >> >> (office) 972-729-7905 >> >> (Cell) 972-955-0914 >> >> >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> >> > From agmalis@gmail.com Wed Jul 6 14:35:50 2011 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 97BFB21F8B55 for ; Wed, 6 Jul 2011 14:35:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AfeJPgYuzAd for ; Wed, 6 Jul 2011 14:35:50 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDA1F21F8A58 for ; Wed, 6 Jul 2011 14:35:49 -0700 (PDT) Received: by qwc23 with SMTP id 23so240140qwc.31 for ; Wed, 06 Jul 2011 14:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xqK8fCh+kw+/LoVIeU0u8Y765SFy6BWvF8qrv98zwB8=; b=hICkD3kSvMXzjtAROKElf/Eda/QYcIRK2f4qLduSV4ja4pjZDH/b0w/e6cSG8TC171 KpgNBAZ1eReQIWdc45aPzFFix2VIhPsF3UXNSJlr6UuXdSeT1uns7dw2TFCYEn7QffHI WJNxdMnDxMIv2fiHJk3c2dwE4iwtb4sAVKhbQ= Received: by 10.229.241.205 with SMTP id lf13mr24379qcb.292.1309988149091; Wed, 06 Jul 2011 14:35:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.36 with HTTP; Wed, 6 Jul 2011 14:35:29 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Wed, 6 Jul 2011 17:35:29 -0400 Message-ID: Subject: Re: draft-so-yong-rtgwg-cl-framework-04 : Make working group item? To: Alia Atlas Content-Type: text/plain; charset=ISO-8859-1 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, 06 Jul 2011 21:35:50 -0000 I support this becoming a WG draft (full disclosure: I'm a co-author). Cheers, Andy On Wed, Jul 6, 2011 at 5:19 PM, Alia Atlas wrote: > I would encourage everyone to read the most recent version of the > draft-so-yong-rtgwg-cl-framework-04 and comment on it. > Last IETF, we had the question of whether the previous version should > become a WG draft. > > I would like to determine this on the mailing list and verify the > conclusion at our RTGWG meeting. > > The Composite Link work is something that we've agreed to do as a WG. > The draft-ietf-rtgwg-cl-requirement-04 will be going > to WG Last Call very soon, so this is a good time to read both and comment. > > Eagerly looking forward to discussion, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From jdrake@juniper.net Wed Jul 6 14:57:19 2011 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 4F1F821F8A97 for ; Wed, 6 Jul 2011 14:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izpUVt94XYb9 for ; Wed, 6 Jul 2011 14:57:18 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 880AA21F8A94 for ; Wed, 6 Jul 2011 14:57:18 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKThTaPYt4l+I5nzrol+pd3O6kKvQ/wtfC@postini.com; Wed, 06 Jul 2011 14:57:18 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 6 Jul 2011 14:53:44 -0700 From: John E Drake To: Alia Atlas , "rtgwg@ietf.org" Date: Wed, 6 Jul 2011 14:53:42 -0700 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8H0n6G1a4V8GGRZmQnro7jTwVSgAB7jCQ Message-ID: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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, 06 Jul 2011 21:57:19 -0000 Alia, Is it okay for me to say that I think that this is a really bad idea and th= at I was glad that interest in it had waned? Thanks, John Sent from my iPhone > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Alia Atlas > Sent: Wednesday, July 06, 2011 1:57 PM > To: rtgwg@ietf.org > Subject: discussion on fast notification work >=20 > The last 2 IETFs, we have had discussions about the idea of fast > notification, as described in > draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and > draft-csaszar-ipfrr-fn-00. >=20 > Since then, I have not seen substantial discussion or interest on the > mailing list. If you are > interested in this work, have questions about it, or would like to see > RTGWG continue to discuss it, > please send email to this mailing list. I'd like to see this > conversation happening here before IETF. >=20 > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From akatlas@gmail.com Wed Jul 6 15:03:21 2011 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 BB88321F8AD6 for ; Wed, 6 Jul 2011 15:03:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbPT24Hc3LjH for ; Wed, 6 Jul 2011 15:03:21 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45AEF21F8AD5 for ; Wed, 6 Jul 2011 15:03:21 -0700 (PDT) Received: by pzk5 with SMTP id 5so448379pzk.31 for ; Wed, 06 Jul 2011 15:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Of9ZTwuYWUiN4C17K3kLOqkSEQmSaxuDwQ3ntBoTQgM=; b=aMK5PdTZv9Pk3bolELSd5JDhbcgDp0rWrB8SHDkiYdTVgO5eUqyoDYnoanyRsl77Zz A4EgQFpvcPDJuiISTi0O+JHS6LFUHXGvAQdCk9rLkKdMnc6aigmmkMIPC3iq8rcIh0yP cLopg+FczZmnIuObyMp8jRyjGP0FdVRIIPiJE= MIME-Version: 1.0 Received: by 10.68.58.2 with SMTP id m2mr89189pbq.305.1309989800696; Wed, 06 Jul 2011 15:03:20 -0700 (PDT) Received: by 10.68.64.195 with HTTP; Wed, 6 Jul 2011 15:03:20 -0700 (PDT) In-Reply-To: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> Date: Wed, 6 Jul 2011 18:03:20 -0400 Message-ID: Subject: Re: discussion on fast notification work From: Alia Atlas To: John E Drake Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 06 Jul 2011 22:03:21 -0000 John, Absolutely - I have not seen positive comments about this being a problem that needs solving and have seen concerns about the security implications. I would prefer to have any discussion about it here so that we do not spend valuable f2f time on this unless there is significant interest. Alia On Wed, Jul 6, 2011 at 5:53 PM, John E Drake wrote: > Alia, > > Is it okay for me to say that I think that this is a really bad idea and = that I was glad that interest in it had waned? > > Thanks, > > John > > Sent from my iPhone > > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf >> Of Alia Atlas >> Sent: Wednesday, July 06, 2011 1:57 PM >> To: rtgwg@ietf.org >> Subject: discussion on fast notification work >> >> The last 2 IETFs, we have had discussions about the idea of fast >> notification, as described in >> draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and >> draft-csaszar-ipfrr-fn-00. >> >> Since then, I have not seen substantial discussion or interest on the >> mailing list. =A0If you are >> interested in this work, have questions about it, or would like to see >> RTGWG continue to discuss it, >> please send email to this mailing list. =A0I'd like to see this >> conversation happening here before IETF. >> >> Thanks, >> Alia >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > From jeff.tantsura@ericsson.com Wed Jul 6 16:06:59 2011 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 B9BDE21F89A7 for ; Wed, 6 Jul 2011 16:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cfg-5DM31bVt for ; Wed, 6 Jul 2011 16:06:59 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 35A8421F89AC for ; Wed, 6 Jul 2011 16:06:59 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p66N5t1l022325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Jul 2011 18:06:56 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 6 Jul 2011 19:04:52 -0400 From: Jeff Tantsura To: John E Drake , Alia Atlas , "rtgwg@ietf.org" Date: Wed, 6 Jul 2011 19:04:51 -0400 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8H0n6G1a4V8GGRZmQnro7jTwVSgAB7jCQAAFdYVA= Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CCA025055@EUSAACMS0701.eamcs.ericsson.se> References: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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, 06 Jul 2011 23:06:59 -0000 Hi Alia/John, Thanks for your comments. We have been listening very carefully and have taken all the critic rather = seriously. We have changed the way we distribute FNs, added authentication and prototy= ped/measured convergence times in networks of different diameters. We have also added some additional clients (protocols to use FN) Updated draft will be published soon. We would really like to present our work. Thanks!=20 Regards, Jeff =20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Wednesday, July 06, 2011 14:54 To: Alia Atlas; rtgwg@ietf.org Subject: RE: discussion on fast notification work Alia, Is it okay for me to say that I think that this is a really bad idea and th= at I was glad that interest in it had waned? Thanks, John Sent from my iPhone > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > Of Alia Atlas > Sent: Wednesday, July 06, 2011 1:57 PM > To: rtgwg@ietf.org > Subject: discussion on fast notification work >=20 > The last 2 IETFs, we have had discussions about the idea of fast > notification, as described in > draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and > draft-csaszar-ipfrr-fn-00. >=20 > Since then, I have not seen substantial discussion or interest on the > mailing list. If you are > interested in this work, have questions about it, or would like to see > RTGWG continue to discuss it, > please send email to this mailing list. I'd like to see this > conversation happening here before IETF. >=20 > Thanks, > Alia > _______________________________________________ > 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 ning.so@verizonbusiness.com Wed Jul 6 16:07:19 2011 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 D9E1421F89B2 for ; Wed, 6 Jul 2011 16:07: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=[AWL=0.001, BAYES_00=-2.599, 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 Pp2y9scC36lL for ; Wed, 6 Jul 2011 16:07:19 -0700 (PDT) Received: from ashesmtp01.verizonbusiness.com (ashesmtp01.verizonbusiness.com [198.4.8.163]) by ietfa.amsl.com (Postfix) with ESMTP id 067EE21F89A2 for ; Wed, 6 Jul 2011 16:07:18 -0700 (PDT) Received: from pdcismtp03.vzbi.com ([unknown] [166.40.77.73]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LNX00GCNPK2IP50@firewall.verizonbusiness.com> for rtgwg@ietf.org; Wed, 06 Jul 2011 23:07:14 +0000 (GMT) Received: from pdcismtp03.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LNX00275PK21X00@pdcismtp03.vzbi.com> for rtgwg@ietf.org; Wed, 06 Jul 2011 23:07:14 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([unknown] [153.39.68.168]) by pdcismtp03.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LNX0018YPK1UF00@pdcismtp03.vzbi.com> for rtgwg@ietf.org; Wed, 06 Jul 2011 23:07:14 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 06 Jul 2011 23:07:14 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Subject: RE: Requesting adoption as WG draft Date: Wed, 06 Jul 2011 23:07:12 +0000 Message-id: <14584D6EE26B314187A4F68BA206060007C16081@ASHEVS008.mcilink.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Requesting adoption as WG draft Thread-index: Acw8I+SNny3kFW73Q0qgmwaC7LNHswAC878Q References: <14584D6EE26B314187A4F68BA206060007AF9AF1@ASHEVS008.mcilink.com> From: "So, Ning" To: Alia Atlas X-OriginalArrivalTime: 06 Jul 2011 23:07:14.0253 (UTC) FILETIME=[718557D0:01CC3C31] 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, 06 Jul 2011 23:07:20 -0000 Alia, First of all, I support this draft to become WG draft (as co-author). =20 The current draft kept the framework flexible, so different local = implementation can be done without violating the draft. As for the = advantages and trade-offs of how to advertise component links, we have = had some lengthy discussions on e-mails before between Tony, Curtis, = Dave, Lucy, and myself. I recall we come to a conclusion that either = way (summary vs. detailed) would work, and we might want to leave that = as a tunable nob for the operator to control. I would welcome more = discussion if anything new comes up, but I do not recall any other = disagreement in previous discussions. As for the detailed protocol gap analysis, we mentioned a few in the = draft, but I don't think they will impact the framework itself. We can = further strengthen that section, or on an equally valid note, we can = also leave that to the solution draft. I would like to hear other = people's preference on that. =20 Best regards, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 -----Original Message----- From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Wednesday, July 06, 2011 4:30 PM To: So, Ning Cc: rtgwg@ietf.org Subject: Re: Requesting adoption as WG draft Ning, I have read draft-so-yong-rtgwg-cl-framework-04 and was happy to see = that there is more content about what is available in existing protocols = and what is not. I do think this is an improvement. I would still prefer to see discussion of the trade-offs between = different approaches in the framework draft. An example is around what = is advertised for heterogeneous component links and the impact of crankback versus additional data to advertise. Tony Li gave a nice discussion of this a couple IETFs ago and the pros/cons would be good to = capture. I understand that the protocol extensions are not yet defined; I tend to = think of "for future study" as placing work out of scope rather than = implying that it will be coming in companion solution documents. What would be useful is to provide criteria by which different solutions = could be judged. I still don't see any such discussion in the draft. Alia On Tue, Jun 21, 2011 at 2:10 PM, Alia Atlas wrote: > I will read carefully the new version in the next week. > Any acceptance as a WG draft would be after querying the list, of = course. > > That said, please read this updated draft and comment here. =A0It = would=20 > be good to get this done and a decision made before the next IETF. > > Alia > > > On Tue, Jun 21, 2011 at 1:28 PM, So, Ning = wrote: >> Dear WG chairs, >> >> >> >> Have you had a chance to look at the updated Composite Link Framework = >> draft (draft-so-yong-rtgwg-cl-framework-04)?=A0 Alia made the comment = >> in last IETF meeting that this draft is likely to be adopted as WG=20 >> draft, because the Composite Link Requirement has already passed WG=20 >> last call.=A0 Just want to check and see when will you have some time = to make the announcement. >> =A0=A0Thanks a lot. >> >> >> >> >> >> Best regards, >> >> >> >> Ning So >> >> Network Evolution Planning >> >> Verizon, Inc. >> >> (office) 972-729-7905 >> >> (Cell) 972-955-0914 >> >> >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> >> > From Andras.Csaszar@ericsson.com Thu Jul 7 03:52:24 2011 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 0EDB321F85CA for ; Thu, 7 Jul 2011 03:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwglU0bv4Z0M for ; Thu, 7 Jul 2011 03:52:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1A77921F85C5 for ; Thu, 7 Jul 2011 03:52:22 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-15-4e158fe4d522 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D6.B5.20773.4EF851E4; Thu, 7 Jul 2011 12:52:20 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.174]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 7 Jul 2011 12:52:20 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: Alia Atlas , "rtgwg@ietf.org" Date: Thu, 7 Jul 2011 12:52:19 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8H0pFV/FD4JKaRdaUKdEnz26TaAAc2ZTQ Message-ID: <8DCD771BDA4A394E9BCBA8932E8392973216EA6154@ESESSCMS0363.eemea.ericsson.se> References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 07 Jul 2011 10:52:24 -0000 Dear All, As a recap, the basic idea was to explore how one could approximate 1. near instantaneous notification of failures to neighbour and remote node= s 2. near instantaneous update of the FIB=20 1 is approximated by a completely dataplane-based fast notification (FN) fr= amework. 2 is approximated by pre-calculating and pre-downloading backup routes for = RELEVANT failures and doing the FIB update from within the linecard. Since last IETF, based on the comments we received, we have been working on= (and prototyping) a method where FNs are propagated on the shortest path a= nd each hop performs SHA256 authentication in the dataplane before forwardi= ng the packet. Important highlights proving feasibility: - In a 1000-node area with a diameter of 20 hops and 500k external routes, = the backup FIB even in a very bad case is not bigger than 30MB with very di= verse ECMP (10 ECMP alternatives for each destination). The download of thi= s backup FIB size should be no problem. - A naive serial FIB update procedure after a failure in the above network = takes less than 15ms within a dataplane card (assuming 5MT/sec memory perfo= rmance and 1 memory controller). But there may be more intelligent approach= es, such as a lazy (on-demand) FIB update. - In reality, our calculations show that typically only nodes between 1 and= 3 hops away need to prepare for a failure, i.e. failures only 1-2-3 hops a= way are RELEVANT (the above calculation assumes that for each destination n= eeds to prepare for all failures of the 20-hop diameter) - Very important: the FN packet always proceeds AHEAD OF normal data packet= s, so re-routed data packets typically find nodes on their way which have f= inished or almost finished reconfiguring. (In this way long links do not ca= use problems as both FN and normal data packets are delayed the same.) - Pre-calculation complexity is in the same order of magnitude as with Not-= Via, and it's done "offline" Conclusions of our na=EFve implementation are the following: - The solution can be implemented on a current platform, and we don't seem = to use any operation that would make it less useful on other platforms incl= uding e.g. EZChip NP-4 - A FN packet can be originated in less than 200us (micro-sec) after failur= e detection=20 - An FN packet can be forwarded at each hop in ca. 180us (this already incl= udes SHA256 verification and duplicate check!) Andr=E1s =20 > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20 > On Behalf Of Alia Atlas > Sent: 2011. j=FAlius 6. 22:57 > To: rtgwg@ietf.org > Subject: discussion on fast notification work >=20 > The last 2 IETFs, we have had discussions about the idea of fast > notification, as described in > draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and > draft-csaszar-ipfrr-fn-00. >=20 > Since then, I have not seen substantial discussion or interest on the > mailing list. If you are > interested in this work, have questions about it, or would like to see > RTGWG continue to discuss it, > please send email to this mailing list. I'd like to see this > conversation happening here before IETF. >=20 > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > = From Andras.Csaszar@ericsson.com Thu Jul 7 03:53:16 2011 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 BB9F021F87A3 for ; Thu, 7 Jul 2011 03:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by1eHsFdAbpI for ; Thu, 7 Jul 2011 03:53:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 088AF21F85C5 for ; Thu, 7 Jul 2011 03:53:15 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-fa-4e15901afebe Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CD.D5.20773.A10951E4; Thu, 7 Jul 2011 12:53:14 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.174]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 7 Jul 2011 12:53:14 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: John E Drake , Alia Atlas , "rtgwg@ietf.org" Date: Thu, 7 Jul 2011 12:53:12 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8H0n6G1a4V8GGRZmQnro7jTwVSgAB7jCQABr4YLA= Message-ID: <8DCD771BDA4A394E9BCBA8932E8392973216EA6157@ESESSCMS0363.eemea.ericsson.se> References: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 07 Jul 2011 10:53:16 -0000 Hi John, Why exactly do you think it is "a really bad idea"? Kind regards, Andr=E1s=20 > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20 > On Behalf Of John E Drake > Sent: 2011. j=FAlius 6. 23:54 > To: Alia Atlas; rtgwg@ietf.org > Subject: RE: discussion on fast notification work >=20 > Alia, >=20 > Is it okay for me to say that I think that this is a really=20 > bad idea and that I was glad that interest in it had waned? >=20 > Thanks, >=20 > John >=20 > Sent from my iPhone >=20 >=20 > > -----Original Message----- > > From: rtgwg-bounces@ietf.org=20 > [mailto:rtgwg-bounces@ietf.org] On Behalf > > Of Alia Atlas > > Sent: Wednesday, July 06, 2011 1:57 PM > > To: rtgwg@ietf.org > > Subject: discussion on fast notification work > >=20 > > The last 2 IETFs, we have had discussions about the idea of fast > > notification, as described in > > draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and > > draft-csaszar-ipfrr-fn-00. > >=20 > > Since then, I have not seen substantial discussion or=20 > interest on the > > mailing list. If you are > > interested in this work, have questions about it, or would=20 > like to see > > RTGWG continue to discuss it, > > please send email to this mailing list. I'd like to see this > > conversation happening here before IETF. > >=20 > > Thanks, > > Alia > > _______________________________________________ > > 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 Andras.Csaszar@ericsson.com Thu Jul 7 04:01:39 2011 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 3C77021F8645 for ; Thu, 7 Jul 2011 04:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAQv7X7F9lP1 for ; Thu, 7 Jul 2011 04:01:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 19F8521F8609 for ; Thu, 7 Jul 2011 04:01:37 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-8e-4e159211e0ae Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5D.37.20773.112951E4; Thu, 7 Jul 2011 13:01:37 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.174]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 7 Jul 2011 13:01:37 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: Alia Atlas Date: Thu, 7 Jul 2011 13:01:36 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8KIdReFssJbZsQaSGeYWkWrZogQAa878A Message-ID: <8DCD771BDA4A394E9BCBA8932E8392973216EA616B@ESESSCMS0363.eemea.ericsson.se> References: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 07 Jul 2011 11:01:39 -0000 Alia, The problem is clear: how to do fast fail-over in IP and LDP with full fail= ure coverage in arbitrary network topologies. Several other ongoing proposa= ls are targeting the same problem (just to mention Not-Via or MRT). So, I t= hink there is consensus that the problem needs solving. Per-hop authentication should minimise the security implications considerab= ly. We have been working on a prototype doing this with SHA256 and we are a= dding this to the draft now. Cheers, Andr=E1s > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20 > On Behalf Of Alia Atlas > Sent: 2011. j=FAlius 7. 0:03 > To: John E Drake > Cc: rtgwg@ietf.org > Subject: Re: discussion on fast notification work >=20 > John, >=20 > Absolutely - I have not seen positive comments about this being a > problem that needs solving and have seen concerns about the security > implications. >=20 > I would prefer to have any discussion about it here so that we do not > spend valuable f2f time on this unless there is significant interest. >=20 > Alia >=20 > On Wed, Jul 6, 2011 at 5:53 PM, John E Drake=20 > wrote: > > Alia, > > > > Is it okay for me to say that I think that this is a really=20 > bad idea and that I was glad that interest in it had waned? > > > > Thanks, > > > > John > > > > Sent from my iPhone > > > > > >> -----Original Message----- > >> From: rtgwg-bounces@ietf.org=20 > [mailto:rtgwg-bounces@ietf.org] On Behalf > >> Of Alia Atlas > >> Sent: Wednesday, July 06, 2011 1:57 PM > >> To: rtgwg@ietf.org > >> Subject: discussion on fast notification work > >> > >> The last 2 IETFs, we have had discussions about the idea of fast > >> notification, as described in > >> draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and > >> draft-csaszar-ipfrr-fn-00. > >> > >> Since then, I have not seen substantial discussion or=20 > interest on the > >> mailing list. =A0If you are > >> interested in this work, have questions about it, or would=20 > like to see > >> RTGWG continue to discuss it, > >> please send email to this mailing list. =A0I'd like to see this > >> conversation happening here before IETF. > >> > >> Thanks, > >> Alia > >> _______________________________________________ > >> 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 jdrake@juniper.net Thu Jul 7 04:27:05 2011 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 2228421F879F for ; Thu, 7 Jul 2011 04:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.571 X-Spam-Level: X-Spam-Status: No, score=-5.571 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eoe9WNS8HiV4 for ; Thu, 7 Jul 2011 04:27:04 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 69F9C21F86F5 for ; Thu, 7 Jul 2011 04:27:04 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKThWYBWkj+sm0aXv676Vr2XYpXZ8ypzI8@postini.com; Thu, 07 Jul 2011 04:27:04 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 7 Jul 2011 04:22:49 -0700 From: John E Drake To: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= , Alia Atlas , "rtgwg@ietf.org" Date: Thu, 7 Jul 2011 04:22:45 -0700 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8H0n6G1a4V8GGRZmQnro7jTwVSgAB7jCQABr4YLAAAU/skA== Message-ID: <5E893DB832F57341992548CDBB333163A0A8EEFC2F@EMBX01-HQ.jnpr.net> References: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> <8DCD771BDA4A394E9BCBA8932E8392973216EA6157@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <8DCD771BDA4A394E9BCBA8932E8392973216EA6157@ESESSCMS0363.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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, 07 Jul 2011 11:27:05 -0000 Please see my previous emails to the list. Sent from my iPhone > -----Original Message----- > From: Andr=E1s Cs=E1sz=E1r [mailto:Andras.Csaszar@ericsson.com] > Sent: Thursday, July 07, 2011 3:53 AM > To: John E Drake; Alia Atlas; rtgwg@ietf.org > Subject: RE: discussion on fast notification work >=20 > Hi John, >=20 > Why exactly do you think it is "a really bad idea"? >=20 > Kind regards, > Andr=E1s >=20 > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] > > On Behalf Of John E Drake > > Sent: 2011. j=FAlius 6. 23:54 > > To: Alia Atlas; rtgwg@ietf.org > > Subject: RE: discussion on fast notification work > > > > Alia, > > > > Is it okay for me to say that I think that this is a really > > bad idea and that I was glad that interest in it had waned? > > > > Thanks, > > > > John > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: rtgwg-bounces@ietf.org > > [mailto:rtgwg-bounces@ietf.org] On Behalf > > > Of Alia Atlas > > > Sent: Wednesday, July 06, 2011 1:57 PM > > > To: rtgwg@ietf.org > > > Subject: discussion on fast notification work > > > > > > The last 2 IETFs, we have had discussions about the idea of fast > > > notification, as described in > > > draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and > > > draft-csaszar-ipfrr-fn-00. > > > > > > Since then, I have not seen substantial discussion or > > interest on the > > > mailing list. If you are > > > interested in this work, have questions about it, or would > > like to see > > > RTGWG continue to discuss it, > > > please send email to this mailing list. I'd like to see this > > > conversation happening here before IETF. > > > > > > Thanks, > > > Alia > > > _______________________________________________ > > > 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 asmirnov@cisco.com Thu Jul 7 05:02:08 2011 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 C988A22800E for ; Thu, 7 Jul 2011 05:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 BS0mmdYhENZS for ; Thu, 7 Jul 2011 05:02:08 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E368E21F86B4 for ; Thu, 7 Jul 2011 05:02:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67BsRde019667; Thu, 7 Jul 2011 13:54:27 +0200 (CEST) Received: from asm-lnx.cisco.com (ams-asmirnov-8716.cisco.com [10.55.140.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67BsQpg021427; Thu, 7 Jul 2011 13:54:27 +0200 (CEST) Message-ID: <4E159E72.1000400@cisco.com> Date: Thu, 07 Jul 2011 13:54:26 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= Subject: Re: discussion on fast notification work References: <8DCD771BDA4A394E9BCBA8932E8392973216EA6154@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <8DCD771BDA4A394E9BCBA8932E8392973216EA6154@ESESSCMS0363.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:02:08 -0000 Hi András, > 2. near instantaneous update of the FIB > I am no specialist in FIB implementations but it would appear to me that implementations and their requirements vary so much that intention itself of improving them all is incorrect and bound to fail. > 1. near instantaneous notification of failures to neighbour and remote nodes Here is my vision of the problem: My logic says that good inter-router notification cannot be made as fast as good intra-router API notification. So all good local repair techniques are intrinsically superior to [even good] inter-router notification approach. Superior first of all in speed of restoration but obviously things like deployment ease add attractiveness. That is, remote notification technique's niche is squeezed; it can be applied as an aid to local repair techniques in those cases where network topology provides redundancy but local repair techniques can't use it. Since more elaborate local repair techniques are being developed which expand their coverage, niche for remote notification technique is contracting to the point when people don't want to bother with it (not even care to criticize it :-) ) I am guessing that authors of the proposal don't agree with this part: "My logic says that good inter-router notification cannot be made as fast as good intra-router API." May I suggest to authors to work on this perception? Otherwise I am afraid there again will be total misunderstanding and disinterest. Anton On 07/07/2011 12:52 PM, András Császár wrote: > Dear All, > > As a recap, the basic idea was to explore how one could approximate > 1. near instantaneous notification of failures to neighbour and remote nodes > 2. near instantaneous update of the FIB > > 1 is approximated by a completely dataplane-based fast notification (FN) framework. > 2 is approximated by pre-calculating and pre-downloading backup routes for RELEVANT failures and doing the FIB update from within the linecard. > > Since last IETF, based on the comments we received, we have been working on (and prototyping) a method where FNs are propagated on the shortest path and each hop performs SHA256 authentication in the dataplane before forwarding the packet. > > Important highlights proving feasibility: > > - In a 1000-node area with a diameter of 20 hops and 500k external routes, the backup FIB even in a very bad case is not bigger than 30MB with very diverse ECMP (10 ECMP alternatives for each destination). The download of this backup FIB size should be no problem. > > - A naive serial FIB update procedure after a failure in the above network takes less than 15ms within a dataplane card (assuming 5MT/sec memory performance and 1 memory controller). But there may be more intelligent approaches, such as a lazy (on-demand) FIB update. > > - In reality, our calculations show that typically only nodes between 1 and 3 hops away need to prepare for a failure, i.e. failures only 1-2-3 hops away are RELEVANT (the above calculation assumes that for each destination needs to prepare for all failures of the 20-hop diameter) > > - Very important: the FN packet always proceeds AHEAD OF normal data packets, so re-routed data packets typically find nodes on their way which have finished or almost finished reconfiguring. (In this way long links do not cause problems as both FN and normal data packets are delayed the same.) > > - Pre-calculation complexity is in the same order of magnitude as with Not-Via, and it's done "offline" > > > Conclusions of our naďve implementation are the following: > > - The solution can be implemented on a current platform, and we don't seem to use any operation that would make it less useful on other platforms including e.g. EZChip NP-4 > > - A FN packet can be originated in less than 200us (micro-sec) after failure detection > > - An FN packet can be forwarded at each hop in ca. 180us (this already includes SHA256 verification and duplicate check!) > > > András > > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: 2011. július 6. 22:57 >> To: rtgwg@ietf.org >> Subject: discussion on fast notification work >> >> The last 2 IETFs, we have had discussions about the idea of fast >> notification, as described in >> draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and >> draft-csaszar-ipfrr-fn-00. >> >> Since then, I have not seen substantial discussion or interest on the >> mailing list. If you are >> interested in this work, have questions about it, or would like to see >> RTGWG continue to discuss it, >> please send email to this mailing list. I'd like to see this >> conversation happening here before IETF. >> >> Thanks, >> Alia >> _______________________________________________ >> 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 gabor.sandor.enyedi@ericsson.com Thu Jul 7 05:06:37 2011 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 2E5F19E8004 for ; Thu, 7 Jul 2011 05:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTnq5fzyYtZ3 for ; Thu, 7 Jul 2011 05:06:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C238721F85A7 for ; Thu, 7 Jul 2011 05:06:34 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ba-4e15a149d1c7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A9.02.20773.941A51E4; Thu, 7 Jul 2011 14:06:33 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.227]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 7 Jul 2011 14:06:33 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: John E Drake , =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= , Alia Atlas , "rtgwg@ietf.org" Date: Thu, 7 Jul 2011 14:06:31 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8H0n6G1a4V8GGRZmQnro7jTwVSgAB7jCQABr4YLAAAU/skAAA8aNw Message-ID: References: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> <8DCD771BDA4A394E9BCBA8932E8392973216EA6157@ESESSCMS0363.eemea.ericsson.se> <5E893DB832F57341992548CDBB333163A0A8EEFC2F@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A0A8EEFC2F@EMBX01-HQ.jnpr.net> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 07 Jul 2011 12:08:35 -0000 I may missed something, since I found only 1 mail you wrote to this list be= fore in this year. Based on that mail, I think you are mixing things; there= you were writing about draft-kini-ospf-fast-notification-01, while Andras = is speaking about draft-csaszar-ipfrr-fn-00. While the first one is just wa= nting to increase the speed of LSA advertisement, the second one is doing r= eal FRR using only data plane. Am I right, were you speaking about the form= er draft? BR, Gabor Enyedi =20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of J= ohn E Drake Sent: Thursday, July 07, 2011 1:23 PM To: Andr=E1s Cs=E1sz=E1r; Alia Atlas; rtgwg@ietf.org Subject: RE: discussion on fast notification work Please see my previous emails to the list. Sent from my iPhone > -----Original Message----- > From: Andr=E1s Cs=E1sz=E1r [mailto:Andras.Csaszar@ericsson.com] > Sent: Thursday, July 07, 2011 3:53 AM > To: John E Drake; Alia Atlas; rtgwg@ietf.org > Subject: RE: discussion on fast notification work >=20 > Hi John, >=20 > Why exactly do you think it is "a really bad idea"? >=20 > Kind regards, > Andr=E1s >=20 > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On=20 > > Behalf Of John E Drake > > Sent: 2011. j=FAlius 6. 23:54 > > To: Alia Atlas; rtgwg@ietf.org > > Subject: RE: discussion on fast notification work > > > > Alia, > > > > Is it okay for me to say that I think that this is a really bad idea=20 > > and that I was glad that interest in it had waned? > > > > Thanks, > > > > John > > > > Sent from my iPhone > > > > > > > -----Original Message----- > > > From: rtgwg-bounces@ietf.org > > [mailto:rtgwg-bounces@ietf.org] On Behalf > > > Of Alia Atlas > > > Sent: Wednesday, July 06, 2011 1:57 PM > > > To: rtgwg@ietf.org > > > Subject: discussion on fast notification work > > > > > > The last 2 IETFs, we have had discussions about the idea of fast=20 > > > notification, as described in=20 > > > draft-lu-fast-notification-framework, draft-lu-fn-transport-00,=20 > > > and draft-csaszar-ipfrr-fn-00. > > > > > > Since then, I have not seen substantial discussion or > > interest on the > > > mailing list. If you are > > > interested in this work, have questions about it, or would > > like to see > > > RTGWG continue to discuss it, > > > please send email to this mailing list. I'd like to see this=20 > > > conversation happening here before IETF. > > > > > > Thanks, > > > Alia > > > _______________________________________________ > > > 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 From gabor.sandor.enyedi@ericsson.com Thu Jul 7 05:20:04 2011 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 4205021F87A3 for ; Thu, 7 Jul 2011 05:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGoPIl8DYISL for ; Thu, 7 Jul 2011 05:20:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E704021F875E for ; Thu, 7 Jul 2011 05:20:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-95-4e15a471426d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.8A.09774.174A51E4; Thu, 7 Jul 2011 14:20:02 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.227]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 7 Jul 2011 14:20:01 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: Anton Smirnov , =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= Date: Thu, 7 Jul 2011 14:19:58 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8nbTFJm0D9HbLT8iQ0L2Dq8Je/QAAX/tw Message-ID: References: <8DCD771BDA4A394E9BCBA8932E8392973216EA6154@ESESSCMS0363.eemea.ericsson.se> <4E159E72.1000400@cisco.com> In-Reply-To: <4E159E72.1000400@cisco.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 07 Jul 2011 12:20:04 -0000 Hi Anton, "That is, remote notification technique's niche is squeezed; it can be appl= ied as an aid to local repair techniques in those cases where network topol= ogy provides redundancy but local repair techniques can't use it. Since mor= e elaborate local repair techniques are being developed which expand their = coverage niche for remote notification technique is contracting to the poin= t when people don't want to bother with it (not even care to criticize it := -) )" When you are saying "local repair", are you speaking about just the LFA, or= do you include techniques like Not-via? BR, Gabor -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= nton Smirnov Sent: Thursday, July 07, 2011 1:54 PM To: Andr=E1s Cs=E1sz=E1r Cc: rtgwg@ietf.org Subject: Re: discussion on fast notification work Hi Andr=E1s, > 2. near instantaneous update of the FIB > I am no specialist in FIB implementations but it would appear to me tha= t implementations and their requirements vary so much that intention itself= of improving them all is incorrect and bound to fail. > 1. near instantaneous notification of failures to neighbour and remote n= odes Here is my vision of the problem: My logic says that good inter-router notification cannot be made as fas= t as good intra-router API notification. So all good local repair technique= s are intrinsically superior to [even good] inter-router notification appro= ach. Superior first of all in speed of restoration but obviously things lik= e deployment ease add attractiveness. That is, remote notification technique's niche is squeezed; it can be a= pplied as an aid to local repair techniques in those cases where network to= pology provides redundancy but local repair techniques can't use it. Since = more elaborate local repair techniques are being developed which expand the= ir coverage, niche for remote notification technique is contracting to the = point when people don't want to bother with it (not even care to criticize = it :-) ) I am guessing that authors of the proposal don't agree with this part: "My logic says that good inter-router notification cannot be made as = fast as good intra-router API." May I suggest to authors to work on this perception? Otherwise I am afr= aid there again will be total misunderstanding and disinterest. Anton On 07/07/2011 12:52 PM, Andr=E1s Cs=E1sz=E1r wrote: > Dear All, > > As a recap, the basic idea was to explore how one could approximate 1.=20 > near instantaneous notification of failures to neighbour and remote=20 > nodes 2. near instantaneous update of the FIB > > 1 is approximated by a completely dataplane-based fast notification (FN) = framework. > 2 is approximated by pre-calculating and pre-downloading backup routes fo= r RELEVANT failures and doing the FIB update from within the linecard. > > Since last IETF, based on the comments we received, we have been working = on (and prototyping) a method where FNs are propagated on the shortest path= and each hop performs SHA256 authentication in the dataplane before forwar= ding the packet. > > Important highlights proving feasibility: > > - In a 1000-node area with a diameter of 20 hops and 500k external routes= , the backup FIB even in a very bad case is not bigger than 30MB with very = diverse ECMP (10 ECMP alternatives for each destination). The download of t= his backup FIB size should be no problem. > > - A naive serial FIB update procedure after a failure in the above networ= k takes less than 15ms within a dataplane card (assuming 5MT/sec memory per= formance and 1 memory controller). But there may be more intelligent approa= ches, such as a lazy (on-demand) FIB update. > > - In reality, our calculations show that typically only nodes between=20 > 1 and 3 hops away need to prepare for a failure, i.e. failures only=20 > 1-2-3 hops away are RELEVANT (the above calculation assumes that for=20 > each destination needs to prepare for all failures of the 20-hop=20 > diameter) > > - Very important: the FN packet always proceeds AHEAD OF normal data=20 > packets, so re-routed data packets typically find nodes on their way=20 > which have finished or almost finished reconfiguring. (In this way=20 > long links do not cause problems as both FN and normal data packets=20 > are delayed the same.) > > - Pre-calculation complexity is in the same order of magnitude as with No= t-Via, and it's done "offline" > > > Conclusions of our na=EFve implementation are the following: > > - The solution can be implemented on a current platform, and we don't=20 > seem to use any operation that would make it less useful on other=20 > platforms including e.g. EZChip NP-4 > > - A FN packet can be originated in less than 200us (micro-sec) after=20 > failure detection > > - An FN packet can be forwarded at each hop in ca. 180us (this already=20 > includes SHA256 verification and duplicate check!) > > > Andr=E1s > > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On=20 >> Behalf Of Alia Atlas >> Sent: 2011. j=FAlius 6. 22:57 >> To: rtgwg@ietf.org >> Subject: discussion on fast notification work >> >> The last 2 IETFs, we have had discussions about the idea of fast=20 >> notification, as described in draft-lu-fast-notification-framework,=20 >> draft-lu-fn-transport-00, and draft-csaszar-ipfrr-fn-00. >> >> Since then, I have not seen substantial discussion or interest on the=20 >> mailing list. If you are interested in this work, have questions=20 >> about it, or would like to see RTGWG continue to discuss it, please=20 >> send email to this mailing list. I'd like to see this conversation=20 >> happening here before IETF. >> >> Thanks, >> Alia >> _______________________________________________ >> 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 From gabor.sandor.enyedi@ericsson.com Thu Jul 7 06:13:07 2011 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 3A86921F873F for ; Thu, 7 Jul 2011 06:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.211 X-Spam-Level: X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCoUjIdrnOku for ; Thu, 7 Jul 2011 06:13:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id F3E5D21F8739 for ; Thu, 7 Jul 2011 06:13:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-05-4e15b0e07877 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.84.09774.0E0B51E4; Thu, 7 Jul 2011 15:13:05 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.227]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 7 Jul 2011 15:13:04 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: Anton Smirnov Date: Thu, 7 Jul 2011 15:13:05 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8pCTgtsYPfA0JRAmDGld2V2D2/wAA2k1Q Message-ID: References: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> <8DCD771BDA4A394E9BCBA8932E8392973216EA6157@ESESSCMS0363.eemea.ericsson.se> <5E893DB832F57341992548CDBB333163A0A8EEFC2F@EMBX01-HQ.jnpr.net> <4E15AA22.7090606@cisco.com> In-Reply-To: <4E15AA22.7090606@cisco.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 07 Jul 2011 13:13:07 -0000 Hi Anton, OK, I see what you meant. You are completely right, intra router notificati= on must be much faster, we are just saying that we can be fast enough even = in this way. Naturally, being a bit slower is a disadvantage. But we have a= dvantages as well. E.g. LFA cannot do 100% single failure coverage - FN can= ; NotVia, LW-NotVia and MRC needs several extra IP addresses - FN doesn't n= eed such addresses; FIFR needs per interface FIB - we do not need such thin= gs. And so on... Unfortunately, all the current solutions have drawbacks, o= urs is being a bit slower. We believe we can still meet the 50ms limit, so = this drawback may not be really important compared to the advantages. BR, Gabor=20 -----Original Message----- From: Anton Smirnov [mailto:asmirnov@cisco.com]=20 Sent: Thursday, July 07, 2011 2:44 PM To: G=E1bor S=E1ndor Enyedi Cc: John E Drake; Andr=E1s Cs=E1sz=E1r; Alia Atlas; rtgwg@ietf.org Subject: Re: discussion on fast notification work Hi Gabor, I am not speaking of any particular draft, I am speaking of families of= solutions - rerouting decision made entirely within router adjacent to fai= lure vs. router close to failure point communicating with other routers to = reroute traffic remotely. All FN drafts fall into category of remote notification; LFA, not-via a= nd other works FN being compared with fall into category of local repair. Anton On 07/07/2011 02:06 PM, G=E1bor S=E1ndor Enyedi wrote: > I may missed something, since I found only 1 mail you wrote to this list = before in this year. Based on that mail, I think you are mixing things; the= re you were writing about draft-kini-ospf-fast-notification-01, while Andra= s is speaking about draft-csaszar-ipfrr-fn-00. While the first one is just = wanting to increase the speed of LSA advertisement, the second one is doing= real FRR using only data plane. Am I right, were you speaking about the fo= rmer draft? > BR, > > Gabor Enyedi > > > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf=20 > Of John E Drake > Sent: Thursday, July 07, 2011 1:23 PM > To: Andr=E1s Cs=E1sz=E1r; Alia Atlas; rtgwg@ietf.org > Subject: RE: discussion on fast notification work > > Please see my previous emails to the list. > > Sent from my iPhone > >> -----Original Message----- >> From: Andr=E1s Cs=E1sz=E1r [mailto:Andras.Csaszar@ericsson.com] >> Sent: Thursday, July 07, 2011 3:53 AM >> To: John E Drake; Alia Atlas; rtgwg@ietf.org >> Subject: RE: discussion on fast notification work >> >> Hi John, >> >> Why exactly do you think it is "a really bad idea"? >> >> Kind regards, >> Andr=E1s >> >>> -----Original Message----- >>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On=20 >>> Behalf Of John E Drake >>> Sent: 2011. j=FAlius 6. 23:54 >>> To: Alia Atlas; rtgwg@ietf.org >>> Subject: RE: discussion on fast notification work >>> >>> Alia, >>> >>> Is it okay for me to say that I think that this is a really bad idea=20 >>> and that I was glad that interest in it had waned? >>> >>> Thanks, >>> >>> John >>> >>> Sent from my iPhone >>> >>> >>>> -----Original Message----- >>>> From: rtgwg-bounces@ietf.org >>> [mailto:rtgwg-bounces@ietf.org] On Behalf >>>> Of Alia Atlas >>>> Sent: Wednesday, July 06, 2011 1:57 PM >>>> To: rtgwg@ietf.org >>>> Subject: discussion on fast notification work >>>> >>>> The last 2 IETFs, we have had discussions about the idea of fast=20 >>>> notification, as described in draft-lu-fast-notification-framework,=20 >>>> draft-lu-fn-transport-00, and draft-csaszar-ipfrr-fn-00. >>>> >>>> Since then, I have not seen substantial discussion or >>> interest on the >>>> mailing list. If you are >>>> interested in this work, have questions about it, or would >>> like to see >>>> RTGWG continue to discuss it, >>>> please send email to this mailing list. I'd like to see this=20 >>>> conversation happening here before IETF. >>>> >>>> Thanks, >>>> Alia >>>> _______________________________________________ >>>> 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 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From asmirnov@cisco.com Thu Jul 7 06:17:52 2011 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 C258421F871A for ; Thu, 7 Jul 2011 06:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 xRTopMwTYdqe for ; Thu, 7 Jul 2011 06:17:52 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0579321F8712 for ; Thu, 7 Jul 2011 06:17:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67CiVUb026093; Thu, 7 Jul 2011 14:44:31 +0200 (CEST) Received: from asm-lnx.cisco.com (ams-asmirnov-8716.cisco.com [10.55.140.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p67CiIeM005547; Thu, 7 Jul 2011 14:44:18 +0200 (CEST) Message-ID: <4E15AA22.7090606@cisco.com> Date: Thu, 07 Jul 2011 14:44:18 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11 MIME-Version: 1.0 To: =?ISO-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= Subject: Re: discussion on fast notification work References: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> <8DCD771BDA4A394E9BCBA8932E8392973216EA6157@ESESSCMS0363.eemea.ericsson.se> <5E893DB832F57341992548CDBB333163A0A8EEFC2F@EMBX01-HQ.jnpr.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 13:17:52 -0000 Hi Gabor, I am not speaking of any particular draft, I am speaking of families of solutions - rerouting decision made entirely within router adjacent to failure vs. router close to failure point communicating with other routers to reroute traffic remotely. All FN drafts fall into category of remote notification; LFA, not-via and other works FN being compared with fall into category of local repair. Anton On 07/07/2011 02:06 PM, Gábor Sándor Enyedi wrote: > I may missed something, since I found only 1 mail you wrote to this list before in this year. Based on that mail, I think you are mixing things; there you were writing about draft-kini-ospf-fast-notification-01, while Andras is speaking about draft-csaszar-ipfrr-fn-00. While the first one is just wanting to increase the speed of LSA advertisement, the second one is doing real FRR using only data plane. Am I right, were you speaking about the former draft? > BR, > > Gabor Enyedi > > > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of John E Drake > Sent: Thursday, July 07, 2011 1:23 PM > To: András Császár; Alia Atlas; rtgwg@ietf.org > Subject: RE: discussion on fast notification work > > Please see my previous emails to the list. > > Sent from my iPhone > >> -----Original Message----- >> From: András Császár [mailto:Andras.Csaszar@ericsson.com] >> Sent: Thursday, July 07, 2011 3:53 AM >> To: John E Drake; Alia Atlas; rtgwg@ietf.org >> Subject: RE: discussion on fast notification work >> >> Hi John, >> >> Why exactly do you think it is "a really bad idea"? >> >> Kind regards, >> András >> >>> -----Original Message----- >>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On >>> Behalf Of John E Drake >>> Sent: 2011. július 6. 23:54 >>> To: Alia Atlas; rtgwg@ietf.org >>> Subject: RE: discussion on fast notification work >>> >>> Alia, >>> >>> Is it okay for me to say that I think that this is a really bad idea >>> and that I was glad that interest in it had waned? >>> >>> Thanks, >>> >>> John >>> >>> Sent from my iPhone >>> >>> >>>> -----Original Message----- >>>> From: rtgwg-bounces@ietf.org >>> [mailto:rtgwg-bounces@ietf.org] On Behalf >>>> Of Alia Atlas >>>> Sent: Wednesday, July 06, 2011 1:57 PM >>>> To: rtgwg@ietf.org >>>> Subject: discussion on fast notification work >>>> >>>> The last 2 IETFs, we have had discussions about the idea of fast >>>> notification, as described in >>>> draft-lu-fast-notification-framework, draft-lu-fn-transport-00, >>>> and draft-csaszar-ipfrr-fn-00. >>>> >>>> Since then, I have not seen substantial discussion or >>> interest on the >>>> mailing list. If you are >>>> interested in this work, have questions about it, or would >>> like to see >>>> RTGWG continue to discuss it, >>>> please send email to this mailing list. I'd like to see this >>>> conversation happening here before IETF. >>>> >>>> Thanks, >>>> Alia >>>> _______________________________________________ >>>> 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 > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From akatlas@gmail.com Thu Jul 7 07:01:00 2011 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 4B5761F0C46 for ; Thu, 7 Jul 2011 07:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 E1C0iNcmXDTq for ; Thu, 7 Jul 2011 07:00:59 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5C8C21F8743 for ; Thu, 7 Jul 2011 07:00:59 -0700 (PDT) Received: by pvh18 with SMTP id 18so604397pvh.31 for ; Thu, 07 Jul 2011 07:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3AF93hWyBx1LHTeIdtA8+PizomO3eDx6ovoFiMQL5NI=; b=F3bD66FDIjv6omnzBpRcBHVuRcCD+FhIArx09M0l8OYviPn3QWRcDJBwzbltavs4JD HffbzyfO04XhrF8RSFmvElg5wXsf5YGPg0kud1WAWinf5fgkmVX8UeMp5L/MxtGyrtZ/ DuzGnJgAQWZ7kGog9gFVyGTrrc19IQCBb4vHY= MIME-Version: 1.0 Received: by 10.68.58.2 with SMTP id m2mr1187092pbq.305.1310047259216; Thu, 07 Jul 2011 07:00:59 -0700 (PDT) Received: by 10.68.64.195 with HTTP; Thu, 7 Jul 2011 07:00:59 -0700 (PDT) In-Reply-To: <8DCD771BDA4A394E9BCBA8932E8392973216EA616B@ESESSCMS0363.eemea.ericsson.se> References: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> <8DCD771BDA4A394E9BCBA8932E8392973216EA616B@ESESSCMS0363.eemea.ericsson.se> Date: Thu, 7 Jul 2011 10:00:59 -0400 Message-ID: Subject: Re: discussion on fast notification work From: Alia Atlas To: =?ISO-8859-1?B?QW5kcuFzIENz4XN64XI=?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 07 Jul 2011 14:01:00 -0000 Hi Andras, Thanks for the email better describing the idea and scaling. 2011/7/7 Andr=E1s Cs=E1sz=E1r : > Alia, > > The problem is clear: how to do fast fail-over in IP and LDP with full fa= ilure coverage in > arbitrary network topologies. Several other ongoing proposals are targeti= ng the same > problem (just to mention Not-Via or MRT). So, I think there is consensus = that the problem > needs solving. Not-Via, MRT, and LFA are all mechanism for a router to do local repair in response to a local failure. This proposal is an effort to take the idea to the next step and attempt to have all the routers converge to the new topology very very quickly. Converging very very quickly has the advantage of not having micro-forwarding loops for long. It also means there's no need for fast-reroute, since everyone learns about and reacts to the failure rapidly enough. The scaling, computation, and speed are real concerns with this approach. I was quite interested to see your numbers. Thanks for doing that work. One issue, of course, is that there is a large installed base of routers that are not NP-based; I'm not sure of the practicality there. > Per-hop authentication should minimise the security implications consider= ably. We have been working on a prototype doing this with SHA256 and we are= adding this to the draft now. I look forward to it. Alia > Cheers, > Andr=E1s > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: 2011. j=FAlius 7. 0:03 >> To: John E Drake >> Cc: rtgwg@ietf.org >> Subject: Re: discussion on fast notification work >> >> John, >> >> Absolutely - I have not seen positive comments about this being a >> problem that needs solving and have seen concerns about the security >> implications. >> >> I would prefer to have any discussion about it here so that we do not >> spend valuable f2f time on this unless there is significant interest. >> >> Alia >> >> On Wed, Jul 6, 2011 at 5:53 PM, John E Drake >> wrote: >> > Alia, >> > >> > Is it okay for me to say that I think that this is a really >> bad idea and that I was glad that interest in it had waned? >> > >> > Thanks, >> > >> > John >> > >> > Sent from my iPhone >> > >> > >> >> -----Original Message----- >> >> From: rtgwg-bounces@ietf.org >> [mailto:rtgwg-bounces@ietf.org] On Behalf >> >> Of Alia Atlas >> >> Sent: Wednesday, July 06, 2011 1:57 PM >> >> To: rtgwg@ietf.org >> >> Subject: discussion on fast notification work >> >> >> >> The last 2 IETFs, we have had discussions about the idea of fast >> >> notification, as described in >> >> draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and >> >> draft-csaszar-ipfrr-fn-00. >> >> >> >> Since then, I have not seen substantial discussion or >> interest on the >> >> mailing list. =A0If you are >> >> interested in this work, have questions about it, or would >> like to see >> >> RTGWG continue to discuss it, >> >> please send email to this mailing list. =A0I'd like to see this >> >> conversation happening here before IETF. >> >> >> >> Thanks, >> >> Alia >> >> _______________________________________________ >> >> 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 lucy.yong@huawei.com Thu Jul 7 12:23:23 2011 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 3F67921F88CE for ; Thu, 7 Jul 2011 12:23:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ma2UiLKgOpas for ; Thu, 7 Jul 2011 12:23:22 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFFF21F88CC for ; Thu, 7 Jul 2011 12:23:22 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNZ00HU79UWTL@usaga04-in.huawei.com> for rtgwg@ietf.org; Thu, 07 Jul 2011 14:23:21 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LNZ00ABR9UVHL@usaga04-in.huawei.com> for rtgwg@ietf.org; Thu, 07 Jul 2011 14:23:20 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 07 Jul 2011 12:23:14 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.159]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 07 Jul 2011 12:23:19 -0700 Date: Thu, 07 Jul 2011 19:22:59 +0000 From: Lucy yong Subject: RE: Requesting adoption as WG draft In-reply-to: X-Originating-IP: [10.47.138.197] To: Alia Atlas , "So, Ning" Message-id: <2691CE0099834E4A9C5044EEC662BB9D0498B16C@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: Requesting adoption as WG draft Thread-index: AcwwOAA+2lCeP/jkTWyNQ4Enqa36XAAQTduAAvlVhoAAHo1GwA== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <14584D6EE26B314187A4F68BA206060007AF9AF1@ASHEVS008.mcilink.com> 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, 07 Jul 2011 19:23:23 -0000 Hi Alia, I support the draft to become WG draft as co-author. If you think that "for futhre study" cause a confusion here, we can change = to "will be addressed in other drafts".=20 In the requirment draft, Apeendix A and B already describes today's practic= s and protocol usage for mutliple paths; it gives some new requirements on = the compositel ink. IMHO, we don't need to respin it in this draft. Regards, Lucy -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lia Atlas Sent: Wednesday, July 06, 2011 4:30 PM To: So, Ning Cc: rtgwg@ietf.org Subject: Re: Requesting adoption as WG draft Ning, I have read draft-so-yong-rtgwg-cl-framework-04 and was happy to see that t= here is more content about what is available in existing protocols and what= is not. I do think this is an improvement. I would still prefer to see discussion of the trade-offs between different = approaches in the framework draft. An example is around what is advertised= for heterogeneous component links and the impact of crankback versus additional data to advertise. Tony Li gave a nice discussion of this a couple IETFs ago and the pros/cons would be good to ca= pture. I understand that the protocol extensions are not yet defined; I tend to th= ink of "for future study" as placing work out of scope rather than implying= that it will be coming in companion solution documents. What would be useful is to provide criteria by which different solutions co= uld be judged. I still don't see any such discussion in the draft. Alia On Tue, Jun 21, 2011 at 2:10 PM, Alia Atlas wrote: > I will read carefully the new version in the next week. > Any acceptance as a WG draft would be after querying the list, of course. > > That said, please read this updated draft and comment here. =A0It would=20 > be good to get this done and a decision made before the next IETF. > > Alia > > > On Tue, Jun 21, 2011 at 1:28 PM, So, Ning w= rote: >> Dear WG chairs, >> >> >> >> Have you had a chance to look at the updated Composite Link Framework=20 >> draft (draft-so-yong-rtgwg-cl-framework-04)?=A0 Alia made the comment=20 >> in last IETF meeting that this draft is likely to be adopted as WG=20 >> draft, because the Composite Link Requirement has already passed WG=20 >> last call.=A0 Just want to check and see when will you have some time to= make the announcement. >> =A0=A0Thanks a lot. >> >> >> >> >> >> Best regards, >> >> >> >> Ning So >> >> Network Evolution Planning >> >> Verizon, Inc. >> >> (office) 972-729-7905 >> >> (Cell) 972-955-0914 >> >> >> >> _______________________________________________ >> 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 russ@cisco.com Thu Jul 7 15:13:56 2011 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 153DA21F890C for ; Thu, 7 Jul 2011 15:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-3.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 DQZmg-7duJF8 for ; Thu, 7 Jul 2011 15:13:55 -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 72F7A21F87A3 for ; Thu, 7 Jul 2011 15:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=russ@cisco.com; l=1011; q=dns/txt; s=iport; t=1310076835; x=1311286435; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=oaB4Qt/y5xBtmDB0ypWDFYB2USy8rzMaL7VAk69xXCc=; b=Es1/yhKvdya4EfqS8VhguXHOE9deiFfjc69TVwR7Hmjkv0XKe5015Mtk x+fZFAWvc4imq6v8XW9xYiAusrDMD4MpIzrWG9u2byWdVel5qS/+la5BO +ZscvKcD5IzXB6xZEmc/qEbINWzo+oLYP7U7xRw6RuokwfKBUjj/8vB9A s=; X-Files: signature.asc : 260 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcHAJ4uFk6rRDoJ/2dsb2JhbABTmEyOcneIe6UQnXOGOASNW4RqhHyLXw X-IronPort-AV: E=Sophos;i="4.65,495,1304294400"; d="asc'?scan'208";a="843915" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jul 2011 22:13:55 +0000 Received: from [10.116.137.179] (rtp-russwh-8712.cisco.com [10.116.137.179]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p67MDsmi020937 for ; Thu, 7 Jul 2011 22:13:54 GMT Message-ID: <4E162FA2.9080700@cisco.com> Date: Thu, 07 Jul 2011 18:13:54 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110528 Thunderbird/5.0b1 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: Requesting adoption as WG draft References: <14584D6EE26B314187A4F68BA206060007AF9AF1@ASHEVS008.mcilink.com> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA85ABF53C0AA4985FDBFE758" X-Mailman-Approved-At: Thu, 07 Jul 2011 15:25:14 -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: Thu, 07 Jul 2011 22:13:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA85ABF53C0AA4985FDBFE758 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > I have read draft-so-yong-rtgwg-cl-framework-04 and was happy to see > that there is more content about what is available in existing > protocols and what is not. I do think this is an improvement. I do, as well... I support adopting this as a WG draft. Russ --------------enigA85ABF53C0AA4985FDBFE758 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4WL6IACgkQER27sUhU9OTyJACgscQmXGVGJIY2t73uzqOZxr6g 9cUAoLL3Ej3haRHpHPbTolp7ArLdGWx4 =j4kj -----END PGP SIGNATURE----- --------------enigA85ABF53C0AA4985FDBFE758-- From curtis@occnc.com Thu Jul 7 16:19:19 2011 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 E691C21F88EE for ; Thu, 7 Jul 2011 16:19:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4u45MhHqB0b for ; Thu, 7 Jul 2011 16:19:18 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 47CB821F88E4 for ; Thu, 7 Jul 2011 16:19:15 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p67NJ9pD035115; Thu, 7 Jul 2011 19:19:09 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107072319.p67NJ9pD035115@harbor.orleans.occnc.com> To: Jeff Tantsura From: Curtis Villamizar Subject: Re: discussion on fast notification work In-reply-to: Your message of "Wed, 06 Jul 2011 19:04:51 EDT." <0ED867EB33AB2B45AAB470D5A64CDBF60CCA025055@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 07 Jul 2011 19:19:09 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 23:19:20 -0000 I agree with John that there doesn't seem to be a problem to solve. To add to that. In this case there seem to be consensus that this was a bad idea. If the authors want to change that consensus, a draft should come well ahead of the meeting with discussion on the list, and only then if there is interest, should be spend meeting time on this. For example, on the list we can discuss what vendor equipment was used in the networks that were prototyped/measured. We don't want a protocol fix that addresses a bad implementation of a perfectly good protocol. I prefer draft first, well in advance of the meeting, then consider a time slot allocation after discussion on list. [ begin aside The issue is whether it is possible to keep the flooding latency low relative to geographic delay and detection time. A somewhat worst case flooding delay in a good implementation consists of 1) receive packet on line card, check if it is a known change, 2) send it to another processor to verify if it is known, 3) receive it agains and recheck, 4) send it again to line cards, 5) receive it and send it on the line interface. Some implementations multicast from the receiving node, yielding only one internal hop, for two context switches total. Even absent of geographic delay, detection time is order 10 msec. If we assume a context switch time of 1 msec even receiving a packet three times within the same node adds on the order of 3 msec per hop. In a good implementiation, this processing is done on the line cards which have little else to do other than react to low effort near real time requirements such as protection and flooding and installing new state at a slightly lower priority (and with good CPU starvation prevention in the scheduling). If the line card processor is doing real time work and there is a desire to reduce latency, most cards today can support a change to the clock interrupt from a 1000 Hz clock to something a bit faster. The down side is increasing the amount of time spent in the RTC interrupt code. In a bad implementation there is a chance that a CPU delays flooding while waiting for an SPF or for some high CPU user link BGP to finish up some increment of work. Then the delays can be quite long. One advantage of flooding is that after a fault the flooding does not rely on assumptions about the remaining topology. Multiple simultaous faults due to failure of a shared resource can and often do occur. Any mechanism that relys on forwarding or relies on source routing through a best guess at what links remain will fail to deliver notifications in such a case. In that case we are back to the flooding delay anyway, so might as well work on keeping that short. Maybe on the list the authors can describe the motivation, the target flooding or notification delay, and how the shortcomings discussed previously are addressed. end aside ] Curtis In message <0ED867EB33AB2B45AAB470D5A64CDBF60CCA025055@EUSAACMS0701.eamcs.ericsson.se> Jeff Tantsura writes: > > Hi Alia/John, > > Thanks for your comments. > > We have been listening very carefully and have taken all the critic > rather seriously. > > We have changed the way we distribute FNs, added authentication and > prototyped/measured convergence times in networks of different > diameters. We have also added some additional clients (protocols to > use FN) > > Updated draft will be published soon. > > We would really like to present our work. > > Thanks! > > Regards, > Jeff > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of John E Drake > Sent: Wednesday, July 06, 2011 14:54 > To: Alia Atlas; rtgwg@ietf.org > Subject: RE: discussion on fast notification work > > Alia, > > Is it okay for me to say that I think that this is a really bad idea > and that I was glad that interest in it had waned? > > Thanks, > > John > > Sent from my iPhone > > > > -----Original Message----- > > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf > > Of Alia Atlas > > Sent: Wednesday, July 06, 2011 1:57 PM > > To: rtgwg@ietf.org > > Subject: discussion on fast notification work > > > > The last 2 IETFs, we have had discussions about the idea of fast > > notification, as described in > > draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and > > draft-csaszar-ipfrr-fn-00. > > > > Since then, I have not seen substantial discussion or interest on the > > mailing list. If you are > > interested in this work, have questions about it, or would like to see > > RTGWG continue to discuss it, > > please send email to this mailing list. I'd like to see this > > conversation happening here before IETF. > > > > Thanks, > > Alia From curtis@occnc.com Thu Jul 7 16:43:43 2011 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 E975421F8A6C for ; Thu, 7 Jul 2011 16:43:43 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E1 hex): cc: Andr\341s Cs\341sz\341r ; Thu, 7 Jul 2011 16:43:43 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id ED4DA21F8A6A for ; Thu, 7 Jul 2011 16:43:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p67NhcIJ035360; Thu, 7 Jul 2011 19:43:38 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107072343.p67NhcIJ035360@harbor.orleans.occnc.com> To: Anton Smirnov From: Curtis Villamizar Subject: Re: discussion on fast notification work In-reply-to: Your message of "Thu, 07 Jul 2011 13:54:26 +0200." <4E159E72.1000400@cisco.com> Date: Thu, 07 Jul 2011 19:43:38 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 23:43:44 -0000 Anton, A key point made below is. Protection at the PLR is always faster than inter-node protection. That said, if someone wants fast protection with full coverage, run MPLS with RSVP-TE and enable FRR and join the rest of the world that has already figured that out. Then there is complete (single failure) protection at every PLR. If multiple failures occur, then precomputed protection is impractical, notification schemes don't work, and flooding needs to work well and SPF and/or CSPF and installation of new FIB needs to be fast. Of course, those that think the idea of running MPLS is way too scary or think that reinventing the wheel is great fun can continue this conversation as long as they like. After all if people didn't think MPLS was scary we wouldn't even have IPFRR in the first place. Curtis In message <4E159E72.1000400@cisco.com> Anton Smirnov writes: Hi András, > 2. near instantaneous update of the FIB > I am no specialist in FIB implementations but it would appear to me that implementations and their requirements vary so much that intention itself of improving them all is incorrect and bound to fail. > 1. near instantaneous notification of failures to neighbour and remote nodes Here is my vision of the problem: My logic says that good inter-router notification cannot be made as fast as good intra-router API notification. So all good local repair techniques are intrinsically superior to [even good] inter-router notification approach. Superior first of all in speed of restoration but obviously things like deployment ease add attractiveness. That is, remote notification technique's niche is squeezed; it can be applied as an aid to local repair techniques in those cases where network topology provides redundancy but local repair techniques can't use it. Since more elaborate local repair techniques are being developed which expand their coverage, niche for remote notification technique is contracting to the point when people don't want to bother with it (not even care to criticize it :-) ) I am guessing that authors of the proposal don't agree with this part: "My logic says that good inter-router notification cannot be made as fast as good intra-router API." May I suggest to authors to work on this perception? Otherwise I am afraid there again will be total misunderstanding and disinterest. Anton On 07/07/2011 12:52 PM, András Császár wrote: > Dear All, > > As a recap, the basic idea was to explore how one could approximate > 1. near instantaneous notification of failures to neighbour and remote nodes > 2. near instantaneous update of the FIB > > 1 is approximated by a completely dataplane-based fast notification (FN) framework. > 2 is approximated by pre-calculating and pre-downloading backup routes for RELEVANT failures and doing the FIB update from within the linecard. > > Since last IETF, based on the comments we received, we have been working on (and prototyping) a method where FNs are propagated on the shortest path and each hop performs SHA256 authentication in the dataplane before forwarding the packet. > > Important highlights proving feasibility: > > - In a 1000-node area with a diameter of 20 hops and 500k external routes, the backup FIB even in a very bad case is not bigger than 30MB with very diverse ECMP (10 ECMP alternatives for each destination). The download of this backup FIB size should be no problem. > > - A naive serial FIB update procedure after a failure in the above network takes less than 15ms within a dataplane card (assuming 5MT/sec memory performance and 1 memory controller). But there may be more intelligent approaches, such as a lazy (on-demand) FIB update. > > - In reality, our calculations show that typically only nodes between 1 and 3 hops away need to prepare for a failure, i.e. failures only 1-2-3 hops away are RELEVANT (the above calculation assumes that for each destination needs to prepare for all failures of the 20-hop diameter) > > - Very important: the FN packet always proceeds AHEAD OF normal data packets, so re-routed data packets typically find nodes on their way which have finished or almost finished reconfiguring. (In this way long links do not cause problems as both FN and normal data packets are delayed the same.) > > - Pre-calculation complexity is in the same order of magnitude as with Not-Via, and it's done "offline" > > > Conclusions of our naďve implementation are the following: > > - The solution can be implemented on a current platform, and we don't seem to use any operation that would make it less useful on other platforms including e.g. EZChip NP-4 > > - A FN packet can be originated in less than 200us (micro-sec) after failure detection > > - An FN packet can be forwarded at each hop in ca. 180us (this already includes SHA256 verification and duplicate check!) > > > András > > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] >> On Behalf Of Alia Atlas >> Sent: 2011. július 6. 22:57 >> To: rtgwg@ietf.org >> Subject: discussion on fast notification work >> >> The last 2 IETFs, we have had discussions about the idea of fast >> notification, as described in >> draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and >> draft-csaszar-ipfrr-fn-00. >> >> Since then, I have not seen substantial discussion or interest on the >> mailing list. If you are >> interested in this work, have questions about it, or would like to see >> RTGWG continue to discuss it, >> please send email to this mailing list. I'd like to see this >> conversation happening here before IETF. >> >> Thanks, >> Alia >> _______________________________________________ >> 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 From curtis@occnc.com Thu Jul 7 16:55:09 2011 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 7CF1411E8090 for ; Thu, 7 Jul 2011 16:55:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyu32D5uG8nO for ; Thu, 7 Jul 2011 16:55:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7641711E807C for ; Thu, 7 Jul 2011 16:55:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p67Nsw5N035482; Thu, 7 Jul 2011 19:54:58 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107072354.p67Nsw5N035482@harbor.orleans.occnc.com> To: Lucy yong From: Curtis Villamizar Subject: Re: Requesting adoption as WG draft In-reply-to: Your message of "Thu, 07 Jul 2011 19:22:59 -0000." <2691CE0099834E4A9C5044EEC662BB9D0498B16C@dfweml503-mbx.china.huawei.com> Date: Thu, 07 Jul 2011 19:54:58 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 23:55:09 -0000 Lucy, I think the point is that a framework document is supposed to provide a description of what exists and provide a description of the approach that will be taken to extend protocols to accomplish the requirements that are not met. After the framework document is completed we should have a clear picture of what protocol extensions are going to be needed. We are not there yet. That said, I still owe you contributed text in that area but have been busy. My time should be freed up quite a bit after this next IETF. I will try to get rough text together that we can discuss at the IETF at least among authors. Curtis In message <2691CE0099834E4A9C5044EEC662BB9D0498B16C@dfweml503-mbx.china.huawei.com> Lucy yong writes: Hi Alia, I support the draft to become WG draft as co-author. If you think that "for futhre study" cause a confusion here, we can change to "will be addressed in other drafts". In the requirment draft, Apeendix A and B already describes today's practics and protocol usage for mutliple paths; it gives some new requirements on the compositel ink. IMHO, we don't need to respin it in this draft. Regards, Lucy -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas Sent: Wednesday, July 06, 2011 4:30 PM To: So, Ning Cc: rtgwg@ietf.org Subject: Re: Requesting adoption as WG draft Ning, I have read draft-so-yong-rtgwg-cl-framework-04 and was happy to see that there is more content about what is available in existing protocols and what is not. I do think this is an improvement. I would still prefer to see discussion of the trade-offs between different approaches in the framework draft. An example is around what is advertised for heterogeneous component links and the impact of crankback versus additional data to advertise. Tony Li gave a nice discussion of this a couple IETFs ago and the pros/cons would be good to capture. I understand that the protocol extensions are not yet defined; I tend to think of "for future study" as placing work out of scope rather than implying that it will be coming in companion solution documents. What would be useful is to provide criteria by which different solutions could be judged. I still don't see any such discussion in the draft. Alia On Tue, Jun 21, 2011 at 2:10 PM, Alia Atlas wrote: > I will read carefully the new version in the next week. > Any acceptance as a WG draft would be after querying the list, of course. > > That said, please read this updated draft and comment here.  It would > be good to get this done and a decision made before the next IETF. > > Alia > > > On Tue, Jun 21, 2011 at 1:28 PM, So, Ning wrote: >> Dear WG chairs, >> >> >> >> Have you had a chance to look at the updated Composite Link Framework >> draft (draft-so-yong-rtgwg-cl-framework-04)?  Alia made the comment >> in last IETF meeting that this draft is likely to be adopted as WG >> draft, because the Composite Link Requirement has already passed WG >> last call.  Just want to check and see when will you have some time to make the announcement. >>   Thanks a lot. >> >> >> >> >> >> Best regards, >> >> >> >> Ning So >> >> Network Evolution Planning >> >> Verizon, Inc. >> >> (office) 972-729-7905 >> >> (Cell) 972-955-0914 >> >> >> >> _______________________________________________ >> 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 From Andras.Csaszar@ericsson.com Fri Jul 8 01:33:48 2011 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 2CFA621F873D for ; Fri, 8 Jul 2011 01:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGqYTqYfjNfB for ; Fri, 8 Jul 2011 01:33:47 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6542721F873C for ; Fri, 8 Jul 2011 01:33:47 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d6-4e16c0eae955 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E6.7F.20773.AE0C61E4; Fri, 8 Jul 2011 10:33:47 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.174]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 8 Jul 2011 10:33:46 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: Anton Smirnov Date: Fri, 8 Jul 2011 10:33:45 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8nSgmMg9bcfVZQnS/3b7JYThs2wAqXfmA Message-ID: <8DCD771BDA4A394E9BCBA8932E8392973216EA640A@ESESSCMS0363.eemea.ericsson.se> References: <8DCD771BDA4A394E9BCBA8932E8392973216EA6154@ESESSCMS0363.eemea.ericsson.se> <4E159E72.1000400@cisco.com> In-Reply-To: <4E159E72.1000400@cisco.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 08 Jul 2011 08:33:48 -0000 Hi Anton,=20 > > 2. near instantaneous update of the FIB > > >=20 > I am no specialist in FIB implementations but it would=20 > appear to me=20 > that implementations and their requirements vary so much that=20 > intention=20 > itself of improving them all is incorrect and bound to fail. Just like any other IPFRR solution, IPFRR-FN assumes that backup alternativ= e routes are pre-calculated and pre-downloaded to the linecards. The specif= ication should and does NOT mandate any specific implementation - this is c= ompletely platform dependent. > > 1. near instantaneous notification of failures to neighbour and=20 > remote nodes >=20 > Here is my vision of the problem: > My logic says that good inter-router notification cannot=20 > be made as=20 > fast as good intra-router API notification. So all good local repair=20 > techniques are intrinsically superior to [even good] inter-router=20 > notification approach.=20 The above opinion and also that of John, all challenge that IPFRF-FN is not= relying on local repair. Local repair is a principle that would be good to have, I agree. But, this = is the root cause why LFA cannot cannot give 100% coverage. *SOME* informat= ion must be given to even remote nodes to do forwarding differently. Not-Vi= a, MRT and MRC are trying to overcome this problem by squeezing some inform= ation into EVERY data packet on detour. And neither of these solutions have= , as of yet, consensus, since HACKING this info onto the packet brings addi= tional complexities. Now, if there is *no solution* that provides 100% coverage AND has WG conse= nsus, then we should look at the cause for the problem - local repair. But IPFRR-FN still sticks to other principles of classic IPFRR: pre-computa= tion and pre-installation. And still you are right: if it was impossible or infeasible to notify remot= e nodes of failures quickly enough, or if it was impossible/infeasible to p= repare for remote failures, then remote repair cannot fly. We are suggesting that both notification and preparation are actually possi= ble and even feasible. And yes, it may be not exactly as fast as local repair but: - It is still fast enough and can deliver sub-50ms repair - There is actually no local repair based IPFRR solution with 100% coverage= and consensus Regards, Andr=E1s From Andras.Csaszar@ericsson.com Fri Jul 8 01:48:06 2011 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 9F71921F86C6 for ; Fri, 8 Jul 2011 01:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKz-2sxYnR0T for ; Fri, 8 Jul 2011 01:48:06 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C94BC21F86C4 for ; Fri, 8 Jul 2011 01:48:05 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-be-4e16c4442b5e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 25.D1.20773.444C61E4; Fri, 8 Jul 2011 10:48:05 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.174]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 8 Jul 2011 10:48:04 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: Alia Atlas Date: Fri, 8 Jul 2011 10:48:03 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8rk0lOrqevw7oSoeellU2ZyZ6BQAm3lxw Message-ID: <8DCD771BDA4A394E9BCBA8932E8392973216EA642B@ESESSCMS0363.eemea.ericsson.se> References: <5E893DB832F57341992548CDBB333163A0A8EEF877@EMBX01-HQ.jnpr.net> <8DCD771BDA4A394E9BCBA8932E8392973216EA616B@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 08 Jul 2011 08:48:06 -0000 Hi Alia, > > The problem is clear: how to do fast fail-over in IP and=20 > LDP with full failure coverage in > > arbitrary network topologies. Several other ongoing=20 > proposals are targeting the same > > problem (just to mention Not-Via or MRT). So, I think there=20 > is consensus that the problem > > needs solving. >=20 > Not-Via, MRT, and LFA are all mechanism for a router to do local > repair in response to a local failure. >=20 > This proposal is an effort to take the idea to the next step and > attempt to have all the routers converge to the new topology very very > quickly. Please note that in IPFRR-FN (http://tools.ietf.org/html/draft-csaszar-ipfr= r-fn)=20 we are NOT suggesting ANY modification to IGPs. So, in fact we are not changing the convergence properties of ISIS or OSPF = at all. (This has been suggested in http://tools.ietf.org/html/draft-kini-o= spf-fast-notification but this thread should NOT be about that. It's an OSP= F WG matter.) Looking at IPFRR-FN, while it does not affect IGP convergence, it can be sa= id that IPFRR-FN lets the routers converge onto a consistent backup forward= ing state, which is actually mostly identical to what the IGP will calculat= e once it converges. (Since the pre-calculation was also done on the IGP to= po database.) > The scaling, computation, and speed are real concerns with this > approach. I was quite interested to see your numbers. Thanks for > doing that work. One issue, of course, is that there is a large > installed base of routers that are not NP-based; I'm not sure of the > practicality there. Please note that our prototype/measurements are not based on NP-based linec= ard either. By mentioning NP, which is a completely different platform from= ours, I was just highlighting that after discussing with a guy more famili= ar with programming NP we believe that there is no hinderniss for IPFRR-FN = to be implemented on NP, either. Andr=E1s= From Andras.Csaszar@ericsson.com Fri Jul 8 02:09:36 2011 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 EC90221F88C0 for ; Fri, 8 Jul 2011 02:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyrXFYBlXudl for ; Fri, 8 Jul 2011 02:09:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9F45E21F877A for ; Fri, 8 Jul 2011 02:09:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-81-4e16c94e7d1f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AC.EC.09774.E49C61E4; Fri, 8 Jul 2011 11:09:34 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.174]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 8 Jul 2011 11:09:34 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: "curtis@occnc.com" Date: Fri, 8 Jul 2011 11:09:32 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8/FAHIL0adQsyTMGWjmZrv+blmgAUL9tw Message-ID: <8DCD771BDA4A394E9BCBA8932E8392973216EA6463@ESESSCMS0363.eemea.ericsson.se> References: Your message of "Wed, 06 Jul 2011 19:04:51 EDT." <0ED867EB33AB2B45AAB470D5A64CDBF60CCA025055@EUSAACMS0701.eamcs.ericsson.se> <201107072319.p67NJ9pD035115@harbor.orleans.occnc.com> In-Reply-To: <201107072319.p67NJ9pD035115@harbor.orleans.occnc.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 08 Jul 2011 09:09:37 -0000 Hello Curtis,=20 > We don't want a > protocol fix that addresses a bad implementation of a perfectly good > protocol. Please note we are not trying to develop a protocol fix. Currently there exist not standard protocol for - IPFRR - with 100% failure coverage There are proposals only. So there is nothing to fix. Note that IPFRR-FN has no intention to fix/improve OSPF/ISIS routing conver= gence. Instead, we acknowledge that there are practical reasons why IGPs ty= pically do not provide fail-over times below a few hundred milliseconds. Bu= t if sub-50ms fail-over is really needed (which could actually be another t= hread for debate IMHO), then something else is needed. We are almost finishing the new drafts, but it is unlikely we can submit th= em much earlier before Monday's cut-off. Andr=E1s > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org]=20 > On Behalf Of Curtis Villamizar > Sent: 2011. j=FAlius 8. 1:19 > To: Jeff Tantsura > Cc: rtgwg@ietf.org > Subject: Re: discussion on fast notification work=20 >=20 >=20 > I agree with John that there doesn't seem to be a problem to solve. >=20 > To add to that. >=20 > In this case there seem to be consensus that this was a bad idea. If > the authors want to change that consensus, a draft should come well > ahead of the meeting with discussion on the list, and only then if > there is interest, should be spend meeting time on this. >=20 > For example, on the list we can discuss what vendor equipment was used > in the networks that were prototyped/measured. We don't want a > protocol fix that addresses a bad implementation of a perfectly good > protocol. I prefer draft first, well in advance of the meeting, then > consider a time slot allocation after discussion on list. >=20 > [ begin aside >=20 > The issue is whether it is possible to keep the flooding latency low > relative to geographic delay and detection time. A somewhat worst > case flooding delay in a good implementation consists of 1) receive > packet on line card, check if it is a known change, 2) send it to > another processor to verify if it is known, 3) receive it agains and > recheck, 4) send it again to line cards, 5) receive it and send it on > the line interface. Some implementations multicast from the receiving > node, yielding only one internal hop, for two context switches total. >=20 > Even absent of geographic delay, detection time is order 10 msec. If > we assume a context switch time of 1 msec even receiving a packet > three times within the same node adds on the order of 3 msec per hop. >=20 > In a good implementiation, this processing is done on the line cards > which have little else to do other than react to low effort near real > time requirements such as protection and flooding and installing new > state at a slightly lower priority (and with good CPU starvation > prevention in the scheduling). If the line card processor is doing > real time work and there is a desire to reduce latency, most cards > today can support a change to the clock interrupt from a 1000 Hz clock > to something a bit faster. The down side is increasing the amount of > time spent in the RTC interrupt code. >=20 > In a bad implementation there is a chance that a CPU delays flooding > while waiting for an SPF or for some high CPU user link BGP to finish > up some increment of work. Then the delays can be quite long. >=20 > One advantage of flooding is that after a fault the flooding does not > rely on assumptions about the remaining topology. Multiple simultaous > faults due to failure of a shared resource can and often do occur. > Any mechanism that relys on forwarding or relies on source routing > through a best guess at what links remain will fail to deliver > notifications in such a case. In that case we are back to the > flooding delay anyway, so might as well work on keeping that short. >=20 > Maybe on the list the authors can describe the motivation, the target > flooding or notification delay, and how the shortcomings discussed > previously are addressed. >=20 > end aside ] >=20 > Curtis >=20 > In message=20 > <0ED867EB33AB2B45AAB470D5A64CDBF60CCA025055@EUSAACMS0701.eamcs > .ericsson.se> > Jeff Tantsura writes: > > =20 > > Hi Alia/John, > > =20 > > Thanks for your comments. > > =20 > > We have been listening very carefully and have taken all the critic > > rather seriously. > > =20 > > We have changed the way we distribute FNs, added authentication and > > prototyped/measured convergence times in networks of different > > diameters. We have also added some additional clients (protocols to > > use FN) > > =20 > > Updated draft will be published soon. > > =20 > > We would really like to present our work. > > =20 > > Thanks!=20 > > =20 > > Regards, > > Jeff =20 > > =20 > > -----Original Message----- > > From: rtgwg-bounces@ietf.org=20 > [mailto:rtgwg-bounces@ietf.org] On Behalf Of John E Drake > > Sent: Wednesday, July 06, 2011 14:54 > > To: Alia Atlas; rtgwg@ietf.org > > Subject: RE: discussion on fast notification work > > =20 > > Alia, > > =20 > > Is it okay for me to say that I think that this is a really bad idea > > and that I was glad that interest in it had waned? > > =20 > > Thanks, > > =20 > > John > > =20 > > Sent from my iPhone > > =20 > > =20 > > > -----Original Message----- > > > From: rtgwg-bounces@ietf.org=20 > [mailto:rtgwg-bounces@ietf.org] On Behalf > > > Of Alia Atlas > > > Sent: Wednesday, July 06, 2011 1:57 PM > > > To: rtgwg@ietf.org > > > Subject: discussion on fast notification work > > >=20 > > > The last 2 IETFs, we have had discussions about the idea of fast > > > notification, as described in > > > draft-lu-fast-notification-framework,=20 > draft-lu-fn-transport-00, and > > > draft-csaszar-ipfrr-fn-00. > > >=20 > > > Since then, I have not seen substantial discussion or=20 > interest on the > > > mailing list. If you are > > > interested in this work, have questions about it, or=20 > would like to see > > > RTGWG continue to discuss it, > > > please send email to this mailing list. I'd like to see this > > > conversation happening here before IETF. > > >=20 > > > Thanks, > > > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > = From Andras.Csaszar@ericsson.com Fri Jul 8 02:16:15 2011 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 F41F721F857D for ; Fri, 8 Jul 2011 02:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4q6Juz83XrgU for ; Fri, 8 Jul 2011 02:16:14 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7E521F8907 for ; Fri, 8 Jul 2011 02:16:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-b2-4e16cadd8b03 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EF.ED.09774.DDAC61E4; Fri, 8 Jul 2011 11:16:13 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.174]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 8 Jul 2011 11:16:13 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: "curtis@occnc.com" Date: Fri, 8 Jul 2011 11:16:11 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8/7RCt6Q1PPxzSmqkFi1gm5LHAAATxO6g Message-ID: <8DCD771BDA4A394E9BCBA8932E8392973216EA646D@ESESSCMS0363.eemea.ericsson.se> References: Your message of "Thu, 07 Jul 2011 13:54:26 +0200." <4E159E72.1000400@cisco.com> <201107072343.p67NhcIJ035360@harbor.orleans.occnc.com> In-Reply-To: <201107072343.p67NhcIJ035360@harbor.orleans.occnc.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 08 Jul 2011 09:16:15 -0000 > That said, if someone wants fast protection with full coverage, run > MPLS with RSVP-TE and enable FRR and join the rest of the world that > has already figured that out. =20 Yes, that is right, with RSVP-TE you can solve it. We haven't challanged th= e fact that there are operators who do not want to bother with at least RSV= P-TE (but rather use LDP) or do not want to bother with MPLS at all. > Then there is complete (single failure) > protection at every PLR. If multiple failures occur, then precomputed > protection is impractical, notification schemes don't work, and > flooding needs to work well and SPF and/or CSPF and installation of > new FIB needs to be fast. Agreed, speeding up FIB installation is an important task on most platforms= , although that seems to me more of an implementation question. Andr=E1s= From asmirnov@cisco.com Fri Jul 8 02:47:52 2011 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 6DF4721F88BD for ; Fri, 8 Jul 2011 02:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 byYR4GikOyxK for ; Fri, 8 Jul 2011 02:47:51 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAF021F88BA for ; Fri, 8 Jul 2011 02:47:51 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p689aXbK019390; Fri, 8 Jul 2011 11:36:33 +0200 (CEST) Received: from asm-lnx.cisco.com (ams-asmirnov-8716.cisco.com [10.55.140.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p689aW5x018015; Fri, 8 Jul 2011 11:36:33 +0200 (CEST) Message-ID: <4E16CFA0.1010206@cisco.com> Date: Fri, 08 Jul 2011 11:36:32 +0200 From: Anton Smirnov Organization: Cisco Systems User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11 MIME-Version: 1.0 To: curtis@occnc.com Subject: Re: discussion on fast notification work References: <201107072343.p67NhcIJ035360@harbor.orleans.occnc.com> In-Reply-To: <201107072343.p67NhcIJ035360@harbor.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 09:47:52 -0000 Curtis, yes, that was my message though without giving too much credit to LFA versus other local repair methods and without being too MPLS-centric. Anton On 07/08/2011 01:43 AM, Curtis Villamizar wrote: > Anton, > > A key point made below is. > > Protection at the PLR is always faster than inter-node protection. > > That said, if someone wants fast protection with full coverage, run > MPLS with RSVP-TE and enable FRR and join the rest of the world that > has already figured that out. Then there is complete (single failure) > protection at every PLR. If multiple failures occur, then precomputed > protection is impractical, notification schemes don't work, and > flooding needs to work well and SPF and/or CSPF and installation of > new FIB needs to be fast. > > Of course, those that think the idea of running MPLS is way too scary > or think that reinventing the wheel is great fun can continue this > conversation as long as they like. After all if people didn't think > MPLS was scary we wouldn't even have IPFRR in the first place. > > Curtis > > > In message<4E159E72.1000400@cisco.com> > Anton Smirnov writes: > > Hi András, > > > 2. near instantaneous update of the FIB > > > > I am no specialist in FIB implementations but it would appear to me > that implementations and their requirements vary so much that intention > itself of improving them all is incorrect and bound to fail. > > > > 1. near instantaneous notification of failures to neighbour and > remote nodes > > Here is my vision of the problem: > My logic says that good inter-router notification cannot be made as > fast as good intra-router API notification. So all good local repair > techniques are intrinsically superior to [even good] inter-router > notification approach. Superior first of all in speed of restoration but > obviously things like deployment ease add attractiveness. > That is, remote notification technique's niche is squeezed; it can > be applied as an aid to local repair techniques in those cases where > network topology provides redundancy but local repair techniques can't > use it. Since more elaborate local repair techniques are being developed > which expand their coverage, niche for remote notification technique is > contracting to the point when people don't want to bother with it (not > even care to criticize it :-) ) > > I am guessing that authors of the proposal don't agree with this > part: "My logic says that good inter-router notification cannot be made > as fast as good intra-router API." > May I suggest to authors to work on this perception? Otherwise I am > afraid there again will be total misunderstanding and disinterest. > > Anton > > > On 07/07/2011 12:52 PM, András Császár wrote: >> Dear All, >> >> As a recap, the basic idea was to explore how one could approximate >> 1. near instantaneous notification of failures to neighbour and remote nodes >> 2. near instantaneous update of the FIB >> >> 1 is approximated by a completely dataplane-based fast notification (FN) framework. >> 2 is approximated by pre-calculating and pre-downloading backup routes for RELEVANT failures and doing the FIB update from within the linecard. >> >> Since last IETF, based on the comments we received, we have been working on (and prototyping) a method where FNs are propagated on the shortest path and each hop performs SHA256 authentication in the dataplane before forwarding the packet. >> >> Important highlights proving feasibility: >> >> - In a 1000-node area with a diameter of 20 hops and 500k external routes, the backup FIB even in a very bad case is not bigger than 30MB with very diverse ECMP (10 ECMP alternatives for each destination). The download of this backup FIB size should be no problem. >> >> - A naive serial FIB update procedure after a failure in the above network takes less than 15ms within a dataplane card (assuming 5MT/sec memory performance and 1 memory controller). But there may be more intelligent approaches, such as a lazy (on-demand) FIB update. >> >> - In reality, our calculations show that typically only nodes between 1 and 3 hops away need to prepare for a failure, i.e. failures only 1-2-3 hops away are RELEVANT (the above calculation assumes that for each destination needs to prepare for all failures of the 20-hop diameter) >> >> - Very important: the FN packet always proceeds AHEAD OF normal data packets, so re-routed data packets typically find nodes on their way which have finished or almost finished reconfiguring. (In this way long links do not cause problems as both FN and normal data packets are delayed the same.) >> >> - Pre-calculation complexity is in the same order of magnitude as with Not-Via, and it's done "offline" >> >> >> Conclusions of our naďve implementation are the following: >> >> - The solution can be implemented on a current platform, and we don't seem to use any operation that would make it less useful on other platforms including e.g. EZChip NP-4 >> >> - A FN packet can be originated in less than 200us (micro-sec) after failure detection >> >> - An FN packet can be forwarded at each hop in ca. 180us (this already includes SHA256 verification and duplicate check!) >> >> >> András >> >> >>> -----Original Message----- >>> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] >>> On Behalf Of Alia Atlas >>> Sent: 2011. július 6. 22:57 >>> To: rtgwg@ietf.org >>> Subject: discussion on fast notification work >>> >>> The last 2 IETFs, we have had discussions about the idea of fast >>> notification, as described in >>> draft-lu-fast-notification-framework, draft-lu-fn-transport-00, and >>> draft-csaszar-ipfrr-fn-00. >>> >>> Since then, I have not seen substantial discussion or interest on the >>> mailing list. If you are >>> interested in this work, have questions about it, or would like to see >>> RTGWG continue to discuss it, >>> please send email to this mailing list. I'd like to see this >>> conversation happening here before IETF. >>> >>> Thanks, >>> Alia >>> _______________________________________________ >>> 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 > From gabor.sandor.enyedi@ericsson.com Fri Jul 8 03:35:24 2011 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 1C69621F8A0D for ; Fri, 8 Jul 2011 03:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLm3hNsyyB12 for ; Fri, 8 Jul 2011 03:35:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8B56221F8A08 for ; Fri, 8 Jul 2011 03:35:22 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ec-4e16dd697070 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F7.A9.09774.96DD61E4; Fri, 8 Jul 2011 12:35:21 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.227]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 8 Jul 2011 12:35:21 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: "curtis@occnc.com" , Anton Smirnov Date: Fri, 8 Jul 2011 12:35:03 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw8/7cg6uN78EUAS12okKR2Y/IGHAAUz7mA Message-ID: References: Your message of "Thu, 07 Jul 2011 13:54:26 +0200." <4E159E72.1000400@cisco.com> <201107072343.p67NhcIJ035360@harbor.orleans.occnc.com> In-Reply-To: <201107072343.p67NhcIJ035360@harbor.orleans.occnc.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 08 Jul 2011 10:35:24 -0000 Hi Curtis, At this point I feel, that there was a terrible mistake, and drafts were mi= xed. I try to make clear what the situation is. Draft 1. - draft-kini-ospf-fast-notification-01: This draft is trying to increase the speed of LSA/LSP propagation. This pro= blem can be easily challenged, since currently the bottleneck of convergenc= e time is not the propagation. Later this may change, but currently you are= right, this draft may have no attention. Draft 2. - draft-csaszar-ipfrr-fn-00 This is a full-fledged protection technique for IP (and LDP) networks, exac= tly like e.g. LFA, and trying to address the same problems. I know, that se= veral people think that protection MUST be local, but it is not true. The d= ifference between protection and restoration is that while restoration does= all the work AFTER the failure, protection is proactive, and only some min= or reaction is needed when the failure occurs (e.g. switching to the precom= puted detours). Therefore we were thinking that: "OK, everybody wants to do= local protection for IP, but why? They want to avoid the latency of propag= ating an information packet, but that is not an issue for 99% of the areas!= We have 50ms, in the very worst case 10-15ms is enough to get through most= of the areas... So some not local but still protection technique may fit t= o the requirements." So we thought that we can try to do some non-local PRO= TECTION for IP, and see what we get for the price of being say 10ms slower = than the LFA, NotVia, or any other regular IPFRR. We got that we can protec= t 100% of single link, node and single SRLG failures, we get to the shortes= t paths after the failure immediately (so no second convergence is needed a= fter the new topology was explored), we do not need any extra protection ad= dress or even tunneling. Recall, that we are speaking about a protection mechanism, not some OSPF/IS= -IS hack. So this draft describes a mechanism, where alternatives are predo= wnloaded, and failure reaction is done without involving the control plane.= This means that we need time for: 1. detecting the failure - T1 2. propagating the notification - T2 3. doing the failover - T3 The third one is now needed at all the routers, but it is done parallel, so= the network is fully recovered when the last node is reconfigured, T1+T2+T= 3 time after the failure. And with a "local" protection? We would need T1+T= 3 time. We are saying that we can afford spending that extra T2 time in mos= t of the networks to get the previous advantages. Please do not mix the two drafts! BR, Gabor P.S.: We are currently modifying draft-csaszar-ipfrr-fn-00, and address its= most important problems (e.g. authentication). If you can wait till Monday= , it may worth to read the new version. -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of C= urtis Villamizar Sent: Friday, July 08, 2011 1:44 AM To: Anton Smirnov Cc: rtgwg@ietf.org Subject: Re: discussion on fast notification work=20 Anton, A key point made below is. Protection at the PLR is always faster than inter-node protection. That said, if someone wants fast protection with full coverage, run MPLS wi= th RSVP-TE and enable FRR and join the rest of the world that has already f= igured that out. Then there is complete (single failure) protection at eve= ry PLR. If multiple failures occur, then precomputed protection is impract= ical, notification schemes don't work, and flooding needs to work well and = SPF and/or CSPF and installation of new FIB needs to be fast. Of course, those that think the idea of running MPLS is way too scary or th= ink that reinventing the wheel is great fun can continue this conversation = as long as they like. After all if people didn't think MPLS was scary we w= ouldn't even have IPFRR in the first place. Curtis In message <4E159E72.1000400@cisco.com> Anton Smirnov writes: Hi Andr=E1s, > 2. near instantaneous update of the FIB > I am no specialist in FIB implementations but it would appear to me tha= t implementations and their requirements vary so much that intention itself= of improving them all is incorrect and bound to fail. > 1. near instantaneous notification of failures to neighbour and remote n= odes Here is my vision of the problem: My logic says that good inter-router notification cannot be made as fas= t as good intra-router API notification. So all good local repair technique= s are intrinsically superior to [even good] inter-router notification appro= ach. Superior first of all in speed of restoration but obviously things lik= e deployment ease add attractiveness. That is, remote notification technique's niche is squeezed; it can be a= pplied as an aid to local repair techniques in those cases where network to= pology provides redundancy but local repair techniques can't use it. Since = more elaborate local repair techniques are being developed which expand the= ir coverage, niche for remote notification technique is contracting to the = point when people don't want to bother with it (not even care to criticize = it :-) ) I am guessing that authors of the proposal don't agree with this part: "My logic says that good inter-router notification cannot be made as = fast as good intra-router API." May I suggest to authors to work on this perception? Otherwise I am afr= aid there again will be total misunderstanding and disinterest. Anton On 07/07/2011 12:52 PM, Andr=E1s Cs=E1sz=E1r wrote: > Dear All, > > As a recap, the basic idea was to explore how one could approximate 1.=20 > near instantaneous notification of failures to neighbour and remote=20 > nodes 2. near instantaneous update of the FIB > > 1 is approximated by a completely dataplane-based fast notification (FN) = framework. > 2 is approximated by pre-calculating and pre-downloading backup routes fo= r RELEVANT failures and doing the FIB update from within the linecard. > > Since last IETF, based on the comments we received, we have been working = on (and prototyping) a method where FNs are propagated on the shortest path= and each hop performs SHA256 authentication in the dataplane before forwar= ding the packet. > > Important highlights proving feasibility: > > - In a 1000-node area with a diameter of 20 hops and 500k external routes= , the backup FIB even in a very bad case is not bigger than 30MB with very = diverse ECMP (10 ECMP alternatives for each destination). The download of t= his backup FIB size should be no problem. > > - A naive serial FIB update procedure after a failure in the above networ= k takes less than 15ms within a dataplane card (assuming 5MT/sec memory per= formance and 1 memory controller). But there may be more intelligent approa= ches, such as a lazy (on-demand) FIB update. > > - In reality, our calculations show that typically only nodes between=20 > 1 and 3 hops away need to prepare for a failure, i.e. failures only=20 > 1-2-3 hops away are RELEVANT (the above calculation assumes that for=20 > each destination needs to prepare for all failures of the 20-hop=20 > diameter) > > - Very important: the FN packet always proceeds AHEAD OF normal data=20 > packets, so re-routed data packets typically find nodes on their way=20 > which have finished or almost finished reconfiguring. (In this way=20 > long links do not cause problems as both FN and normal data packets=20 > are delayed the same.) > > - Pre-calculation complexity is in the same order of magnitude as with No= t-Via, and it's done "offline" > > > Conclusions of our na=EFve implementation are the following: > > - The solution can be implemented on a current platform, and we don't=20 > seem to use any operation that would make it less useful on other=20 > platforms including e.g. EZChip NP-4 > > - A FN packet can be originated in less than 200us (micro-sec) after=20 > failure detection > > - An FN packet can be forwarded at each hop in ca. 180us (this already=20 > includes SHA256 verification and duplicate check!) > > > Andr=E1s > > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On=20 >> Behalf Of Alia Atlas >> Sent: 2011. j=FAlius 6. 22:57 >> To: rtgwg@ietf.org >> Subject: discussion on fast notification work >> >> The last 2 IETFs, we have had discussions about the idea of fast=20 >> notification, as described in draft-lu-fast-notification-framework,=20 >> draft-lu-fn-transport-00, and draft-csaszar-ipfrr-fn-00. >> >> Since then, I have not seen substantial discussion or interest on the=20 >> mailing list. If you are interested in this work, have questions=20 >> about it, or would like to see RTGWG continue to discuss it, please=20 >> send email to this mailing list. I'd like to see this conversation=20 >> happening here before IETF. >> >> Thanks, >> Alia >> _______________________________________________ >> 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 From akatlas@gmail.com Fri Jul 8 06:42:42 2011 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 068A221F8648 for ; Fri, 8 Jul 2011 06:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 iQ+8qNhyBrVU for ; Fri, 8 Jul 2011 06:42:41 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2A6721F8551 for ; Fri, 8 Jul 2011 06:42:02 -0700 (PDT) Received: by pwj5 with SMTP id 5so513337pwj.31 for ; Fri, 08 Jul 2011 06:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iFnMbz4Qjz0dXqQV387tx3qu5uuG5h7hU2FyuZY09pY=; b=v6WOlzZN0rWDCX7hpis2V+41hJknO/dnQwjSiMv34piawMi3KBA3cETx1IIsrn/cE5 YKnAEzy8WRN5ZNq80YUgFXLDJjZp09QlmDdfNqZEedFWNwLYVCJZDWqJJwdsUWoqd2/R 5Vlsm+olSd6/MMs00M6XvUgLSPCwheK5tC6aU= MIME-Version: 1.0 Received: by 10.68.68.73 with SMTP id u9mr1430948pbt.305.1310132520362; Fri, 08 Jul 2011 06:42:00 -0700 (PDT) Received: by 10.68.64.195 with HTTP; Fri, 8 Jul 2011 06:42:00 -0700 (PDT) In-Reply-To: <8DCD771BDA4A394E9BCBA8932E8392973216EA640A@ESESSCMS0363.eemea.ericsson.se> References: <8DCD771BDA4A394E9BCBA8932E8392973216EA6154@ESESSCMS0363.eemea.ericsson.se> <4E159E72.1000400@cisco.com> <8DCD771BDA4A394E9BCBA8932E8392973216EA640A@ESESSCMS0363.eemea.ericsson.se> Date: Fri, 8 Jul 2011 09:42:00 -0400 Message-ID: Subject: Re: discussion on fast notification work From: Alia Atlas To: =?ISO-8859-1?B?QW5kcuFzIENz4XN64XI=?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 08 Jul 2011 13:42:42 -0000 Andras, 2011/7/8 Andr=E1s Cs=E1sz=E1r : > And yes, it may be not exactly as fast as local repair but: > - It is still fast enough and can deliver sub-50ms repair The basic concern about non-local repair is the speed of light delay. If one is looking at an intercontinental network, these delays add up so that sub-50ms is not physically possible. I think your argument is that the notification arrives with/before the traf= fic, but that reasoning isn't very convincing to me... Perhaps you can explain it better here? Alia From akatlas@gmail.com Fri Jul 8 06:53:02 2011 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 C260821F87A5 for ; Fri, 8 Jul 2011 06:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 x1Ikn9vk8Iom for ; Fri, 8 Jul 2011 06:53:02 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B99D21F8799 for ; Fri, 8 Jul 2011 06:53:02 -0700 (PDT) Received: by pwj5 with SMTP id 5so522255pwj.31 for ; Fri, 08 Jul 2011 06:53:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9kShC0ofrk9cuyo2UdR+BHl/RP+tKd1Em1LeJnq3tsU=; b=SqIdrkMKVJh560PozpJCiHPNqTM2kZLz0PZpYQXYPowD1x2Mfx+LVR6PlyRZA2FAh6 qgWG+tZWobjRPbJNjZ8Y+DHG+K3INDNYpvzhmIaOWPyHJCtwTsZJCKDTLdyvx3Kzuauc BxEhpJj8xe9ozGT3j92uRkyxE2mHTf5aQIpG4= MIME-Version: 1.0 Received: by 10.68.14.195 with SMTP id r3mr3148545pbc.171.1310133181925; Fri, 08 Jul 2011 06:53:01 -0700 (PDT) Received: by 10.68.64.195 with HTTP; Fri, 8 Jul 2011 06:53:01 -0700 (PDT) In-Reply-To: References: <4E159E72.1000400@cisco.com> <201107072343.p67NhcIJ035360@harbor.orleans.occnc.com> Date: Fri, 8 Jul 2011 09:53:01 -0400 Message-ID: Subject: Re: discussion on fast notification work From: Alia Atlas To: =?ISO-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 08 Jul 2011 13:53:02 -0000 Hi Gabor, 2011/7/8 G=E1bor S=E1ndor Enyedi : >Therefore we were thinking that: "OK, everybody wants to do local protecti= on for IP, but why? They want to avoid the latency of propagating an inform= ation packet, but that is not an issue for 99% of the areas! We have 50ms, = in the very worst case 10-15ms is enough to get through most of the areas..= . So some not local but still protection technique may fit to the requireme= nts." [Alia] I think that the idea of this 10-15ms is problematic for intercontinental networks. If, according to wikipedia, the delay through optical fiber is about 1000km/5ms - then that means to go from Boston to San Francisco, takes approximately 21.6ms. Now, you may be saying that there are a large number of networks with significantly more constrained distances where this could apply... > Recall, that we are speaking about a protection mechanism, not some OSPF/= IS-IS hack. So this draft describes a mechanism, where alternatives are pre= downloaded, and failure reaction is done without involving the control plan= e. This means that we need time for: > > 1. detecting the failure - T1 > 2. propagating the notification - T2 > 3. doing the failover - T3 > > The third one is now needed at all the routers, but it is done parallel, = so the network is fully recovered when the last node is reconfigured, T1+T2= +T3 time after the failure. And with a "local" protection? We would need T1= +T3 time. We are saying that we can afford spending that extra T2 time in m= ost of the networks to get the previous advantages. [Alia] I do think an advantage of this approach is the lack of concern about micro-forwarding loops during convergence. Of course, those can still be an issue with just cost changes, so I don't think it changes the need for such technology. Alia From gabor.sandor.enyedi@ericsson.com Fri Jul 8 08:08:34 2011 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 0B3B421F8B0E for ; Fri, 8 Jul 2011 08:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.746 X-Spam-Level: X-Spam-Status: No, score=-3.746 tagged_above=-999 required=5 tests=[AWL=-2.447, BAYES_00=-2.599, GB_SUMOF=5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mqTn--tH6uI for ; Fri, 8 Jul 2011 08:08:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 546C521F8AFE for ; Fri, 8 Jul 2011 08:08:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-95-4e171d6e8f38 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 82.DB.09774.E6D171E4; Fri, 8 Jul 2011 17:08:31 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.227]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 8 Jul 2011 17:08:30 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: Alia Atlas , =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= Date: Fri, 8 Jul 2011 17:08:29 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw9dPd7lfdKDcstTa2i5dUXqE9LawAAzI6g Message-ID: References: <8DCD771BDA4A394E9BCBA8932E8392973216EA6154@ESESSCMS0363.eemea.ericsson.se> <4E159E72.1000400@cisco.com> <8DCD771BDA4A394E9BCBA8932E8392973216EA640A@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 08 Jul 2011 15:08:34 -0000 Hi Alia, Andras already went home, so I try to answer your question. Actually, this = is the first good reason against FN today... So, when I was saying in my previous mail that we think we can live with th= at "T2" time, I was not completely precise. I still believe, that in most c= ases T2 must not be more than 10-15ms, but your right, there are huge links= with serious delay. Let's see such an example, and check whether local pro= tection is better or not.=20 | A--H | | =20 B G | | =20 C F | | D--E | If there is problem with the figure, I just wanted to draw a cycle with 6 n= odes, where packets enter to the network at node D and leave it at node A. = Suppose that the two parts of the network are at the other side of the Atla= ntic ocean, say A, B, G, H are in America and C, D, E, F are in Europe. In = this way both link B-C and F-G have huge delay (say 40ms). Suppose that all= the link costs are uniform (so the shortest path is D-C-B-A) and link B-C = goes down, so we need to do something. Since there is no other possibility,= the failed link cannot be bypassed in America, we need to "ask" for help f= rom nodes in Europe in order to use the "other" transatlantic link. Observe= how unrealistic this case is; after the failure, the shortest path from B = to A crosses the ocean TWICE! What will happen, if we apply FN here? Suppose that we are right, and we ca= n forward FN packets extremely rapidly (as it is the case), so the speed of= an FN packet is (almost) equal to a normal packet's speed. In order to mak= e the example simple, now suppose that processing FN packets takes no time = (it is not 0, but it will not make any difference, if you want, I can later= explain why). So when B detects the failure, it will send out the notifica= tion (A will send it out as well, but there is a bigger latency along that = path, so it is not important). You are right, the packet will not make it i= n time, and more than 50ms is needed to get to node D after the failure (th= ere is the detection time). But none of the packets will be lost, packets r= eceived by B will be sent back to C. Since those packets will get exactly t= he same delay thanks to link B-C, when they arrive to C, C is already recon= figured (since the FN packet was there before), and they will be sent to D.= The situation is the same with D. So when will node A get the first packet= after the failure? We can say that this time is the sum of the delays of l= ink B-C, C-D, D-E, E-F, F-G, G-H, H-A. And yes, there can be some reorderin= g, but currently the hosts can deal with it (see e.g. RTP hosts). What is the situation if we have some local repair? If we have some local r= epair at node B, it will send the packets back to C as well. So after the f= ailure the packets will follow path D-C-B-C-D-E-F-G-H-A. When will node A g= et the first packet after the failure? We get it again, we need to sum the = delays of link B-C, C-D, D-E, E-F, F-G, G-H, H-A. OK, now we do not have re= ordering... Actually, you may say that if we need to forward the FN packets too far (I = mean too many hops away, here physical distance is not an issue), we may ca= use congestion. You are right, but first, we found that usually we need to = reroute quite locally, i.e. we do not need to get farther then 2-3 hops. Se= cond, you cannot avoid this problem if you use some local rerouting; sooner= or later the IGP will converge, and you will need to change the routing of= C, and at that point, C needs to send both packets in link B-C and C-D bac= k to D, which may cause a congestion. OK, this example may not cover all the possible situations, but I think bas= ed on this you may found out all the remaining ones. No doubt, this solutio= n is not perfect, I am just saying that this is the best I know for IP netw= orks. For plain IP it is better even than using maximally redundant trees, = since it can deal with SRLG-s, and MRT-s cannot. Moreover, it is as simple = as it is possible, which is not the case with redundant trees, as you saw y= esterday. :) BR, Gabor P.S.: We are just modifying the draft to use flooding instead of redundant = trees and SHA-256 authentication. Even with this, in our prototype the forw= arding time of an FN packet was almost equal to the forwarding time of a bi= g (1500 byte) data packet. =20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of A= lia Atlas Sent: Friday, July 08, 2011 3:42 PM To: Andr=E1s Cs=E1sz=E1r Cc: rtgwg@ietf.org Subject: Re: discussion on fast notification work Andras, 2011/7/8 Andr=E1s Cs=E1sz=E1r : > And yes, it may be not exactly as fast as local repair but: > - It is still fast enough and can deliver sub-50ms repair The basic concern about non-local repair is the speed of light delay. If one is looking at an intercontinental network, these delays add up so th= at sub-50ms is not physically possible. I think your argument is that the notification arrives with/before the traf= fic, but that reasoning isn't very convincing to me... Perhaps you can exp= lain it better here? Alia _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From lucy.yong@huawei.com Fri Jul 8 08:46:19 2011 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 E3DDA21F8AFD for ; Fri, 8 Jul 2011 08:46:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwb0KBaomTF5 for ; Fri, 8 Jul 2011 08:46:18 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id BAA6B21F8AF9 for ; Fri, 8 Jul 2011 08:46:18 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO0000TTUH42B@usaga02-in.huawei.com> for rtgwg@ietf.org; Fri, 08 Jul 2011 10:46:17 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO0003XQUH4YR@usaga02-in.huawei.com> for rtgwg@ietf.org; Fri, 08 Jul 2011 10:46:16 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 08 Jul 2011 08:46:18 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.159]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 08 Jul 2011 08:46:16 -0700 Date: Fri, 08 Jul 2011 15:45:55 +0000 From: Lucy yong Subject: RE: Requesting adoption as WG draft In-reply-to: <201107072354.p67Nsw5N035482@harbor.orleans.occnc.com> X-Originating-IP: [10.47.140.91] To: "curtis@occnc.com" Message-id: <2691CE0099834E4A9C5044EEC662BB9D0498B862@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: Requesting adoption as WG draft Thread-index: AQHMPQFNYkTM4AHj90idML1rQaO0QpTijXew X-MS-Has-Attach: X-MS-TNEF-Correlator: References: "Your message of Thu, 07 Jul 2011 19:22:59 -0000." <2691CE0099834E4A9C5044EEC662BB9D0498B16C@dfweml503-mbx.china.huawei.com> <201107072354.p67Nsw5N035482@harbor.orleans.occnc.com> 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, 08 Jul 2011 15:46:20 -0000 Curtis, The draft has pointed out where routing and signaling protocol extensions are needed. The detail protocol design should be in separated drafts and WG can work on them together. This is my understanding how IETF works. As one of co-authors, you are certainly in help to make it clearer. Since the requirement draft is already in IESG processing, we like to move forward this work faster. IETF81 and MEFQ3 meetings are the same week (can't believe it). I am unable to be in Quebec for the meeting. Please gather other co-authors for the discussion. Regards, Lucy > -----Original Message----- > From: curtis@occnc.com [mailto:curtis@occnc.com] > Sent: Thursday, July 07, 2011 6:55 PM > To: Lucy yong > Cc: Alia Atlas; So, Ning; rtgwg@ietf.org > Subject: Re: Requesting adoption as WG draft > > > > Lucy, > > I think the point is that a framework document is supposed to provide > a description of what exists and provide a description of the approach > that will be taken to extend protocols to accomplish the requirements > that are not met. > > After the framework document is completed we should have a clear > picture of what protocol extensions are going to be needed. We are > not there yet. > > That said, I still owe you contributed text in that area but have been > busy. My time should be freed up quite a bit after this next IETF. I > will try to get rough text together that we can discuss at the IETF at > least among authors. > > Curtis > > > In message <2691CE0099834E4A9C5044EEC662BB9D0498B16C@dfweml503- > mbx.china.huawei.com> > Lucy yong writes: > > Hi Alia, > > I support the draft to become WG draft as co-author. > > If you think that "for futhre study" cause a confusion here, we can change > to "will be addressed in other drafts". > > In the requirment draft, Apeendix A and B already describes today's > practics and protocol usage for mutliple paths; it gives some new > requirements on the compositel ink. IMHO, we don't need to respin it in > this draft. > > Regards, > Lucy > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Alia Atlas > Sent: Wednesday, July 06, 2011 4:30 PM > To: So, Ning > Cc: rtgwg@ietf.org > Subject: Re: Requesting adoption as WG draft > > Ning, > > I have read draft-so-yong-rtgwg-cl-framework-04 and was happy to see that > there is more content about what is available in existing protocols and > what is not. I do think this is an improvement. > > I would still prefer to see discussion of the trade-offs between different > approaches in the framework draft. An example is around what is > advertised for heterogeneous component links and the impact of > crankback versus additional data to advertise. Tony Li gave a nice > discussion of this a couple IETFs ago and the pros/cons would be good to > capture. > > I understand that the protocol extensions are not yet defined; I tend to > think of "for future study" as placing work out of scope rather than > implying that it will be coming in companion solution documents. > What would be useful is to provide criteria by which different solutions > could be judged. I still don't see any such discussion in the draft. > > Alia > > On Tue, Jun 21, 2011 at 2:10 PM, Alia Atlas wrote: > > I will read carefully the new version in the next week. > > Any acceptance as a WG draft would be after querying the list, of course. > > > > That said, please read this updated draft and comment here. $BS[(Bt would > > be good to get this done and a decision made before the next IETF. > > > > Alia > > > > > > On Tue, Jun 21, 2011 at 1:28 PM, So, Ning > wrote: > >> Dear WG chairs, > >> > >> > >> > >> Have you had a chance to look at the updated Composite Link Framework > >> draft (draft-so-yong-rtgwg-cl-framework-04)??Alia made the comment > >> in last IETF meeting that this draft is likely to be adopted as WG > >> draft, because the Composite Link Requirement has already passed WG > >> last call.?Just want to check and see when will you have some time to > make the announcement. > >> $B`0(BThanks a lot. > >> > >> > >> > >> > >> > >> Best regards, > >> > >> > >> > >> Ning So > >> > >> Network Evolution Planning > >> > >> Verizon, Inc. > >> > >> (office) 972-729-7905 > >> > >> (Cell) 972-955-0914 > >> > >> > >> > >> _______________________________________________ > >> 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 > From curtis@occnc.com Fri Jul 8 11:57:37 2011 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 885F921F8A94 for ; Fri, 8 Jul 2011 11:57:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eG6gnwfOgBbe for ; Fri, 8 Jul 2011 11:57:36 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6C46021F8679 for ; Fri, 8 Jul 2011 11:56:56 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p68IurVZ053955; Fri, 8 Jul 2011 14:56:53 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107081856.p68IurVZ053955@harbor.orleans.occnc.com> To: rtgwg@ietf.org Subject: draft-so-yong-rtgwg-cl-framework-04.txt From: Curtis Villamizar Date: Fri, 08 Jul 2011 14:56:53 -0400 Sender: curtis@occnc.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 18:57:37 -0000 The is regarding draft-so-yong-rtgwg-cl-framework-04.txt As a co-author I am partly to blame for not speaking up before the latest draft got published. I appologize to other co-authors for neglecting to provide comments in a timely manner. #include "std.excuses" // you've heard it all before Some brief comments are below. These are comments on the text that is provided. That said, I think the biggest problem with this draft is the ommission of any mechanisms (not protocols specifics) that would normally be expected of an architecture document, including both mechanisms supported by existing protocols, and mechanisms that will require protocol extensions. I will send a separate email on details of that sort that could be added. Curtis Old: Single link and LAG based link bundle have been widely used in today's MPLS networks. New: In today's MPLS networks, single links are used, Ethernet Link Aggregation is used [IEEE 802.1AX-2010] and Link Bundling is used [RFC4201]. Old: Specific protocol solutions are outside the scope of this document. Please delete prior one sentence paragraph. Note that solutions are what architecture docoments are all about. The protocol specifics are omiteed but the types of mechanisms are outlined. Old: Component Link: A point-to-point physical or logical link that - preserves ordering in the steady state. A component link may have transient out of order events, but such events must not exceed the network's specific NPO. Examples of a physical link are: Lambda, Ethernet PHY, and OTN. Examples of a logical link are: MPLS LSP, Ethernet VLAN, and MPLS-TP LSP. New: Component Link: A point-to-point physical or logical link that + preserves ordering among flows in the steady state. + A component link may have transient out of order events, but such events must not exceed the network's specific NPO. Examples of a physical link are: Lambda, Ethernet PHY, and OTN. Examples of a logical link are: MPLS LSP, Ethernet VLAN, and MPLS-TP LSP. Note that a component link preserves orders among flows, not order among packets received. A composite link may be a component link and the server layer composite link (which is acting as a component link) may not preserve order among LSP that don't need to have order preserved. Old: Flow identification: The label stack and other information that uniquely identifies a flow. Other information in flow identification may include an IP header, PW control word, Ethernet MAC address, etc. Note that an LSP may contain one or more Flows or an LSP may be equivalent to a Flow. Flow identification is used to locally select a component link, or a path through the network toward the destination. New: Flow identification: A microflow is defined in RFC 2475 within the context of the Internet Protocol. MPLS supports non_IP protocols as well as IP. In many networks non-IP protocols are encapsulated within pseudowires using a pseudowire control word. In such cases the flow identification may include a potential IP header [RFC4928]. The MPLS label stack may also be used to identify flows. Old: Network Performance Objective (NPO): Numerical values for performance measures, principally availability, latency, and delay variation. See Appendix A for more details. Note: there is no Appendix A. There are no appendices at all. Note: IGP-TE should be defined in the terminology section. Some new text could be: IGP-TE: OSPF and ISIS are both link state routing protocols used in the role traditionally known as an interior gateway protocol (IGP). Both OSPF and ISIS have extensions for traffic engineering which are known as OSPF-TE and ISIS-TE. For cases where either OSPF-TE or ISIS-TE could be used, the abbreviation IGP-TE is used. Old: In IGP-TE, a composite link is advertised as a single TE link between two connected routers. This is similar to a link bundle [RFC4201]. Link bundle applies to a set of homogenous component links. Composite link allows homogenous and non-homogenous component links. In order for route computing engine to calculate a proper path for a LSP, it is necessary for composite link to advertise the summarized available BW as well as the maximum BW for single LSP. If a composite link contains some non-homogeneous component links, the composite link also need to advertise the summarized BW and the maximum BW for single LSP per each homogeneous component link group. The protocol extension for composite link advertisement will be described in the separated draft. Note: Since framework documents never specify protocol extensions, the last sentence can be dropped. These few sentences need to be modified: Old (excerpt from above): In order for route computing engine to calculate a proper path for a LSP, it is necessary for composite link to advertise the summarized available BW as well as the maximum BW for single LSP. If a composite link contains some non-homogeneous component links, the composite link also need to advertise the summarized BW and the maximum BW for single LSP per each homogeneous component link group. New: To support route computation with homogenous component links, bandwidth charterizations such as Available Bandwidth and Maximum LSP Bandwidth [RFC4201] are advertised for a link bundle. To support route computation with non-homogenous component links, it is necessary to advertise provide bandwidth charterizations for each group of homogeneous component links. Note: The terminology section should defined homogeneous component links and non-homogeneous component links. I think heterogeneous might be a good replacement for non-homogeneous. [Any english majors want to weigh in on this?] Old sentence: Signaling protocol does not allow signaling an aggregated LSP where its BW may be larger than the capacity of any component links. [ENTROPY] Note: [ENTROPY] does not address the issue in link bundling that the Maximum LSP bandwidth can be set only to the reflect the component link with the most available bandwidth, or by stretching the spec a bit beyond what has been defined, if the "all ones" compoent is always used, then set the Maximum LSP bandwidth to the same value as the "available bandwidth" for the entire link bundle. In that sense, [ENTROPY] does not address the issue mentioned in the sentence where it is cited. Old sentence: If two unidirectional LSPs are used to construct a component link, they MUST be co-routed. New sentence: Co-routed bidirectional LSP must be supported. LSP may be unidirectional, associated bidirectional (two unidirectional LSP, or corouted bidirectional. There is no such thing as corouted unidirectional LSP. There is no way to coordinate the make-before-break reroute of two unidirectional LSP. There is also no reason to constrain the LSPs on a composite link to be corouted. It is certainly an option that some providers will be interested in, but not an architectural requirement. Old sentences: The protocol extension for singling component link parameter is for further study. This capability is not supported in current protocol because a link bundle contains a set of homogenous links. These can be dropped. Old sentences: In an often case, a component link is configured to carry traffic under normal operation; under some situation, operator may want to configure a component link as a link for local recovery purpose, in which the composite link should not count the component link TE parameters into the composite link TE parameters for the advertisement. However, the composite link may send the traffic over the component link when a component link failure occurs. This needs to be reworded. It should also be at least a separate paragraph. It might be useful to create a separate subsection to discuss protection scenarios and their applicability. For example, in a WDM system, if the entire CL fails all at once, it doesn't make much sense to have a spare component (which also fails). If a composite link makes use of many components on two fibers, then some resilence exists, but a single spare component would have little value. This is also a new requirement. New requirements are not supposed to be introduced in the framework document. There are existing techniques which handle this very well. For example, if capacity is reduced, then the lowest priority LSPs (holding priority as defined in RFC3209) are preempted. A more friendly approach is to use soft preemption and make use of diffserv based QoS during any interim congestion that may occur. Old: When a component link is supported by lower layer network (third component link in figure 2), the control plane that the composite link resides is able to interoperate with the GMPLS or MPLS-TP control plane that lower layer network uses for component link addition and deletion.[CL-REQ] Is this meaningless? If the control plane in both cases *are* MPLS based, then they should interoperate fine. Is this yet another requirement in the framework? In any case, the meaning of the above paragraph is unclear. Old: It is possible for operator to configure one or multiple interface (s) over a composite link. Again, please explain. What is this supposed to mean? When a bi-directional LSP request is signaled over a composite link, if the request indicates that the LSP must be placed on the same component link, the routers of the composite link MUST place the LSP traffic in both directions on a same component link. This constraint can be enforced only for a bidirectional co-routed LSP set up using the non-all-ones component link in a link bundle. Old: Individual component link may fail independently. Upon component link failure, a composite link needs to perform local recovery, i.e. use some available capacity in other component link to carry impacted traffic. Composite link may use LDP or RSVP-TE signaling protocol to facilitate the recovery process between two routers that composite resides. To avoid looped crankback, during the local recovery process, the composite link should advertise its available BW as zero; after finishing the local recovery, it should update its proper available BW in IGP. There is actually no need for this. Components of link bundles have failed for a decade now. As I mentioned above, preemption is used if the link bundle does not have adequate capacity to carry what it used to be carrying. If the available bandwidth truly is zero, then preemption is needed. If not, then details in the RRO change in subsequent RESV messages. Changing contents of the RESV is a normal part of RSVP refresh. For bidrectional LSP, the RRO in both the PATH and RESV change. For LSP using the all-ones component, no signaling change is needed. Old: A component link in a composite link may fail independently. The routers at a composite link MUST maintain each component link status. Two routers may use the control plane to sync up a component link state. When a component link fails, the routers of a composite link MUST re-assign impacted flows to other active component links in minimal disruptive manner. This is local function and do not incorporate with LSP head-end routers. When a composite link is not able to transport all flows, it preempts some flows based upon local management configuration and informs the control plane on these preempted flows. The composite link MUST support soft preemption [RFC5712]. This action ensures the remaining traffic is transported properly. Note: as mentioned in section 4, in order to prevent lopped crankback symptom, when composite link performs local recovery process, it should advertise its available BW as zero; when the local process completes, the composite link should update its link state with the proper available BW. This paragraph is in the data plane section. It specifies control plane functionality which is described somewhat differently in the control plance section. Maybe a new section is needed to describe protection mechanisms. This for the most part is describing the existing behavior for link bundles. Old: Operator may want to perform an optimization function such as load balance or energy saving over a composite link, which may conduct some traffic moving from one component link to another. Are these energy savings optimizations in any way related to the MPLampS architecture [RFC3251]? If not, then please explain. From ning.so@verizonbusiness.com Fri Jul 8 12:11:46 2011 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 B363021F8C9E for ; Fri, 8 Jul 2011 12:11:46 -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=[AWL=0.000, BAYES_00=-2.599, 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 EV7f87oayJPK for ; Fri, 8 Jul 2011 12:11:45 -0700 (PDT) Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by ietfa.amsl.com (Postfix) with ESMTP id 24F4521F8C8A for ; Fri, 8 Jul 2011 12:11:45 -0700 (PDT) Received: from pdcismtp01.vzbi.com ([unknown] [166.40.77.67]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LO100JZ03YLJM80@firewall.verizonbusiness.com> for rtgwg@ietf.org; Fri, 08 Jul 2011 19:11:09 +0000 (GMT) Received: from pdcismtp01.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LO100B7J3YLOL00@pdcismtp01.vzbi.com> for rtgwg@ietf.org; Fri, 08 Jul 2011 19:11:09 +0000 (GMT) Received: from ASHSRV141.mcilink.com ([unknown] [153.39.68.167]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LO100BGY3YKND00@pdcismtp01.vzbi.com> for rtgwg@ietf.org; Fri, 08 Jul 2011 19:11:09 +0000 (GMT) Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV141.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 08 Jul 2011 19:11:08 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Subject: RE: draft-so-yong-rtgwg-cl-framework-04.txt Date: Fri, 08 Jul 2011 19:11:03 +0000 Message-id: <14584D6EE26B314187A4F68BA206060007CA80C0@ASHEVS008.mcilink.com> In-reply-to: <201107081856.p68IurVZ053955@harbor.orleans.occnc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: draft-so-yong-rtgwg-cl-framework-04.txt Thread-index: Acw9oPWWM/uuBZj+Q7i54GR6RlCvsgAAVjjA References: <201107081856.p68IurVZ053955@harbor.orleans.occnc.com> From: "So, Ning" To: curtis@occnc.com, rtgwg@ietf.org X-OriginalArrivalTime: 08 Jul 2011 19:11:08.0616 (UTC) FILETIME=[CAF82C80:01CC3DA2] 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, 08 Jul 2011 19:11:46 -0000 Curtis, Glad to see they unlock you from the desk chain and let you do some "fun" work once in a while :) We will try to update the draft with your input. If we can get your other e-mail this weekend, we might be able to beat the Monday deadline. =20 =20 Best regards, =20 Ning So Network Evolution Planning Verizon, Inc. (office) 972-729-7905 (Cell) 972-955-0914 =20 -----Original Message----- From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Curtis Villamizar Sent: Friday, July 08, 2011 1:57 PM To: rtgwg@ietf.org Subject: draft-so-yong-rtgwg-cl-framework-04.txt The is regarding draft-so-yong-rtgwg-cl-framework-04.txt As a co-author I am partly to blame for not speaking up before the latest draft got published. I appologize to other co-authors for neglecting to provide comments in a timely manner. #include "std.excuses" // you've heard it all before Some brief comments are below. These are comments on the text that is provided. That said, I think the biggest problem with this draft is the ommission of any mechanisms (not protocols specifics) that would normally be expected of an architecture document, including both mechanisms supported by existing protocols, and mechanisms that will require protocol extensions. I will send a separate email on details of that sort that could be added. Curtis Old: Single link and LAG based link bundle have been widely used in today's MPLS networks. New: In today's MPLS networks, single links are used, Ethernet Link Aggregation is used [IEEE 802.1AX-2010] and Link Bundling is used [RFC4201]. Old: Specific protocol solutions are outside the scope of this document. Please delete prior one sentence paragraph. Note that solutions are what architecture docoments are all about. The protocol specifics are omiteed but the types of mechanisms are outlined. Old: Component Link: A point-to-point physical or logical link that - preserves ordering in the steady state. A component link may have transient out of order events, but such events must not exceed the network's specific NPO. Examples of a physical link are: Lambda, Ethernet PHY, and OTN. Examples of a logical link are: MPLS LSP, Ethernet VLAN, and MPLS-TP LSP. New: Component Link: A point-to-point physical or logical link that + preserves ordering among flows in the steady state. + A component link may have transient out of order events, but such events must not exceed the network's specific NPO. Examples of a physical link are: Lambda, Ethernet PHY, and OTN. Examples of a logical link are: MPLS LSP, Ethernet VLAN, and MPLS-TP LSP. Note that a component link preserves orders among flows, not order among packets received. A composite link may be a component link and the server layer composite link (which is acting as a component link) may not preserve order among LSP that don't need to have order preserved. Old: Flow identification: The label stack and other information that uniquely identifies a flow. Other information in flow identification may include an IP header, PW control word, Ethernet MAC address, etc. Note that an LSP may contain one or more Flows or an LSP may be equivalent to a Flow. Flow identification is used to locally select a component link, or a path through the network toward the destination. New: Flow identification: A microflow is defined in RFC 2475 within the context of the Internet Protocol. MPLS supports non_IP protocols as well as IP. In many networks non-IP protocols are encapsulated within pseudowires using a pseudowire control word. In such cases the flow identification may include a potential IP header [RFC4928]. The MPLS label stack may also be used to identify flows. Old: Network Performance Objective (NPO): Numerical values for performance measures, principally availability, latency, and delay variation. See Appendix A for more details. Note: there is no Appendix A. There are no appendices at all. Note: IGP-TE should be defined in the terminology section. Some new text could be: IGP-TE: OSPF and ISIS are both link state routing protocols used in the role traditionally known as an interior gateway protocol (IGP). Both OSPF and ISIS have extensions for traffic engineering which are known as OSPF-TE and ISIS-TE. For cases where either OSPF-TE or ISIS-TE could be used, the abbreviation IGP-TE is used. Old: In IGP-TE, a composite link is advertised as a single TE link between two connected routers. This is similar to a link bundle [RFC4201]. Link bundle applies to a set of homogenous component links. Composite link allows homogenous and non-homogenous component links. In order for route computing engine to calculate a proper path for a LSP, it is necessary for composite link to advertise the summarized available BW as well as the maximum BW for single LSP. If a composite link contains some non-homogeneous component links, the composite link also need to advertise the summarized BW and the maximum BW for single LSP per each homogeneous component link group. The protocol extension for composite link advertisement will be described in the separated draft. Note: Since framework documents never specify protocol extensions, the last sentence can be dropped. These few sentences need to be modified: Old (excerpt from above): In order for route computing engine to calculate a proper path for a LSP, it is necessary for composite link to advertise the summarized available BW as well as the maximum BW for single LSP. If a composite link contains some non-homogeneous component links, the composite link also need to advertise the summarized BW and the maximum BW for single LSP per each homogeneous component link group. New: To support route computation with homogenous component links, bandwidth charterizations such as Available Bandwidth and Maximum LSP Bandwidth [RFC4201] are advertised for a link bundle. To support route computation with non-homogenous component links, it is necessary to advertise provide bandwidth charterizations for each group of homogeneous component links. Note: The terminology section should defined homogeneous component links and non-homogeneous component links. I think heterogeneous might be a good replacement for non-homogeneous. [Any english majors want to weigh in on this?] Old sentence: Signaling protocol does not allow signaling an aggregated LSP where its BW may be larger than the capacity of any component links. [ENTROPY] Note: [ENTROPY] does not address the issue in link bundling that the Maximum LSP bandwidth can be set only to the reflect the component link with the most available bandwidth, or by stretching the spec a bit beyond what has been defined, if the "all ones" compoent is always used, then set the Maximum LSP bandwidth to the same value as the "available bandwidth" for the entire link bundle. In that sense, [ENTROPY] does not address the issue mentioned in the sentence where it is cited. Old sentence: If two unidirectional LSPs are used to construct a component link, they MUST be co-routed. New sentence: Co-routed bidirectional LSP must be supported. LSP may be unidirectional, associated bidirectional (two unidirectional LSP, or corouted bidirectional. There is no such thing as corouted unidirectional LSP. There is no way to coordinate the make-before-break reroute of two unidirectional LSP. There is also no reason to constrain the LSPs on a composite link to be corouted. It is certainly an option that some providers will be interested in, but not an architectural requirement. Old sentences: The protocol extension for singling component link parameter is for further study. This capability is not supported in current protocol because a link bundle contains a set of homogenous links. These can be dropped. Old sentences: In an often case, a component link is configured to carry traffic under normal operation; under some situation, operator may want to configure a component link as a link for local recovery purpose, in which the composite link should not count the component link TE parameters into the composite link TE parameters for the advertisement. However, the composite link may send the traffic over the component link when a component link failure occurs. This needs to be reworded. It should also be at least a separate paragraph. It might be useful to create a separate subsection to discuss protection scenarios and their applicability. For example, in a WDM system, if the entire CL fails all at once, it doesn't make much sense to have a spare component (which also fails). If a composite link makes use of many components on two fibers, then some resilence exists, but a single spare component would have little value. This is also a new requirement. New requirements are not supposed to be introduced in the framework document. There are existing techniques which handle this very well. For example, if capacity is reduced, then the lowest priority LSPs (holding priority as defined in RFC3209) are preempted. A more friendly approach is to use soft preemption and make use of diffserv based QoS during any interim congestion that may occur. Old: When a component link is supported by lower layer network (third component link in figure 2), the control plane that the composite link resides is able to interoperate with the GMPLS or MPLS-TP control plane that lower layer network uses for component link addition and deletion.[CL-REQ] Is this meaningless? If the control plane in both cases *are* MPLS based, then they should interoperate fine. Is this yet another requirement in the framework? In any case, the meaning of the above paragraph is unclear. Old: It is possible for operator to configure one or multiple interface (s) over a composite link. Again, please explain. What is this supposed to mean? When a bi-directional LSP request is signaled over a composite link, if the request indicates that the LSP must be placed on the same component link, the routers of the composite link MUST place the LSP traffic in both directions on a same component link. This constraint can be enforced only for a bidirectional co-routed LSP set up using the non-all-ones component link in a link bundle. Old: Individual component link may fail independently. Upon component link failure, a composite link needs to perform local recovery, i.e. use some available capacity in other component link to carry impacted traffic. Composite link may use LDP or RSVP-TE signaling protocol to facilitate the recovery process between two routers that composite resides. To avoid looped crankback, during the local recovery process, the composite link should advertise its available BW as zero; after finishing the local recovery, it should update its proper available BW in IGP. There is actually no need for this. Components of link bundles have failed for a decade now. As I mentioned above, preemption is used if the link bundle does not have adequate capacity to carry what it used to be carrying. If the available bandwidth truly is zero, then preemption is needed. If not, then details in the RRO change in subsequent RESV messages. Changing contents of the RESV is a normal part of RSVP refresh. For bidrectional LSP, the RRO in both the PATH and RESV change. For LSP using the all-ones component, no signaling change is needed. Old: A component link in a composite link may fail independently. The routers at a composite link MUST maintain each component link status. Two routers may use the control plane to sync up a component link state. When a component link fails, the routers of a composite link MUST re-assign impacted flows to other active component links in minimal disruptive manner. This is local function and do not incorporate with LSP head-end routers. When a composite link is not able to transport all flows, it preempts some flows based upon local management configuration and informs the control plane on these preempted flows. The composite link MUST support soft preemption [RFC5712]. This action ensures the remaining traffic is transported properly. Note: as mentioned in section 4, in order to prevent lopped crankback symptom, when composite link performs local recovery process, it should advertise its available BW as zero; when the local process completes, the composite link should update its link state with the proper available BW. This paragraph is in the data plane section. It specifies control plane functionality which is described somewhat differently in the control plance section. Maybe a new section is needed to describe protection mechanisms. This for the most part is describing the existing behavior for link bundles. Old: Operator may want to perform an optimization function such as load balance or energy saving over a composite link, which may conduct some traffic moving from one component link to another. Are these energy savings optimizations in any way related to the MPLampS architecture [RFC3251]? If not, then please explain. _______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg From akatlas@gmail.com Fri Jul 8 12:32:23 2011 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 06A9121F8D00 for ; Fri, 8 Jul 2011 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 zEIpgZ40pKNa for ; Fri, 8 Jul 2011 12:32:22 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC3121F8C6B for ; Fri, 8 Jul 2011 12:32:22 -0700 (PDT) Received: by ewy19 with SMTP id 19so885625ewy.31 for ; Fri, 08 Jul 2011 12:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Qz71hUVj0yQsgV5je+mmpHoGeF2mpbWVfdYzWQv0Thg=; b=iG0tegN22sQfoILXVy/zZzdpqPpE5at+8SpmIptQoqbjZXjg/LaXnh3dNrncOGR+nk RiuO575mcVJqap43T2BWhu9D3MAjMqcE5sACZG3H4/KW9fCoEs9ScXZxYwWZc+lhz9lg ZRp0rj4ZK9pNTR5dWG4Cj7UHpt/TF5T4uRLBI= MIME-Version: 1.0 Received: by 10.14.15.20 with SMTP id e20mr686349eee.53.1310153541219; Fri, 08 Jul 2011 12:32:21 -0700 (PDT) Received: by 10.14.185.135 with HTTP; Fri, 8 Jul 2011 12:32:21 -0700 (PDT) In-Reply-To: <201107081856.p68IurVZ053955@harbor.orleans.occnc.com> References: <201107081856.p68IurVZ053955@harbor.orleans.occnc.com> Date: Fri, 8 Jul 2011 15:32:21 -0400 Message-ID: Subject: Re: draft-so-yong-rtgwg-cl-framework-04.txt From: Alia Atlas To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 08 Jul 2011 19:32:23 -0000 Curtis, Yes, my problem with the draft is that it still doesn't propose any mechanisms for implementing the requirements. This version has more content - but not as much as I'd like to see, particularly considering how long work on composite-links has been happening. I look forward to a new version. Alia On Fri, Jul 8, 2011 at 2:56 PM, Curtis Villamizar wrote: > > The is regarding draft-so-yong-rtgwg-cl-framework-04.txt > Some brief comments are below. =A0These are comments on the text that is > provided. =A0That said, I think the biggest problem with this draft is > the ommission of any mechanisms (not protocols specifics) that would > normally be expected of an architecture document, including both > mechanisms supported by existing protocols, and mechanisms that will > require protocol extensions. =A0I will send a separate email on details > of that sort that could be added. > From lucy.yong@huawei.com Fri Jul 8 13:01:38 2011 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 C51EF21F8C6C for ; Fri, 8 Jul 2011 13:01:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKJiK0puPXdf for ; Fri, 8 Jul 2011 13:01:35 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id C688921F8C1C for ; Fri, 8 Jul 2011 13:01:35 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO1001U16AMYD@usaga02-in.huawei.com> for rtgwg@ietf.org; Fri, 08 Jul 2011 15:01:35 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO100E376AMVV@usaga02-in.huawei.com> for rtgwg@ietf.org; Fri, 08 Jul 2011 15:01:34 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 08 Jul 2011 13:01:36 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.159]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 08 Jul 2011 13:01:34 -0700 Date: Fri, 08 Jul 2011 20:01:12 +0000 From: Lucy yong Subject: RE: draft-so-yong-rtgwg-cl-framework-04.txt In-reply-to: X-Originating-IP: [10.47.140.91] To: Alia Atlas , "curtis@occnc.com" Message-id: <2691CE0099834E4A9C5044EEC662BB9D0498BA8C@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: draft-so-yong-rtgwg-cl-framework-04.txt Thread-index: AQHMPaXBLDusZvn6tEOmGndz9iC+gpTi1q5g X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <201107081856.p68IurVZ053955@harbor.orleans.occnc.com> 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, 08 Jul 2011 20:01:38 -0000 Alia and Curtis, This is indeed a long work. In very early work, some mechanisms were propos= ed and were considered as local implementation that should not be standardi= zed. With this encourage now, I am fine to include some mechanisms. Regards, Lucy > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Alia Atlas > Sent: Friday, July 08, 2011 2:32 PM > To: curtis@occnc.com > Cc: rtgwg@ietf.org > Subject: Re: draft-so-yong-rtgwg-cl-framework-04.txt >=20 > Curtis, >=20 > Yes, my problem with the draft is that it still doesn't propose any > mechanisms for implementing the requirements. This version has more > content - but not as much as I'd like to see, particularly considering > how long work on composite-links has been happening. >=20 > I look forward to a new version. >=20 > Alia >=20 > On Fri, Jul 8, 2011 at 2:56 PM, Curtis Villamizar wrot= e: > > > > The is regarding draft-so-yong-rtgwg-cl-framework-04.txt >=20 > > Some brief comments are below. =A0These are comments on the text that i= s > > provided. =A0That said, I think the biggest problem with this draft is > > the ommission of any mechanisms (not protocols specifics) that would > > normally be expected of an architecture document, including both > > mechanisms supported by existing protocols, and mechanisms that will > > require protocol extensions. =A0I will send a separate email on details > > of that sort that could be added. > > > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From curtis@occnc.com Fri Jul 8 19:22:04 2011 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 DBDA021F8685 for ; Fri, 8 Jul 2011 19:22:04 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E1 hex): To: G\341bor S\341ndor Enye[...] X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 WJYWchwaHRaG for ; Fri, 8 Jul 2011 19:22:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7F51A21F8681 for ; Fri, 8 Jul 2011 19:22:03 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p692LvgF059590; Fri, 8 Jul 2011 22:21:57 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107090221.p692LvgF059590@harbor.orleans.occnc.com> To: Gábor Sándor Enyedi From: Curtis Villamizar Subject: Re: discussion on fast notification work In-reply-to: Your message of "Fri, 08 Jul 2011 12:35:03 +0200." Date: Fri, 08 Jul 2011 22:21:57 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 02:22:05 -0000 Regardless as to whether the discussion mixed aspects of the various drafts, the original observation from Alia was: >> Since then, I have not seen substantial discussion or interest on the >> mailing list. If you are interested in this work, have questions >> about it, or would like to see RTGWG continue to discuss it, please >> send email to this mailing list. I'd like to see this conversation >> happening here before IETF. >> >> Thanks, >> Alia I have to agree that there has not been interest in this work. Curtis In message Gábor Sándor Enyedi writes: > > Hi Curtis, > > At this point I feel, that there was a terrible mistake, and drafts > were mixed. I try to make clear what the situation is. > > Draft 1. - draft-kini-ospf-fast-notification-01: This draft is trying > to increase the speed of LSA/LSP propagation. This problem can be > easily challenged, since currently the bottleneck of convergence time > is not the propagation. Later this may change, but currently you are > right, this draft may have no attention. > > Draft 2. - draft-csaszar-ipfrr-fn-00 This is a full-fledged protection > technique for IP (and LDP) networks, exactly like e.g. LFA, and trying > to address the same problems. I know, that several people think that > protection MUST be local, but it is not true. The difference between > protection and restoration is that while restoration does all the work > AFTER the failure, protection is proactive, and only some minor > reaction is needed when the failure occurs (e.g. switching to the > precomputed detours). Therefore we were thinking that: "OK, everybody > wants to do local protection for IP, but why? They want to avoid the > latency of propagating an information packet, but that is not an issue > for 99% of the areas! We have 50ms, in the very worst case 10-15ms is > enough to get through most of the areas... So some not local but still > protection technique may fit to the requirements." So we thought that > we can try to do some non-local PROTECTION for IP, and see what we get > for the price of being say 10ms slower than the LFA, NotVia, or any > other regular IPFRR. We got that we can protect 100% of single link, > node and single SRLG failures, we get to the shortest paths after the > failure immediately (so no second convergence is needed after the new > topology was explored), we do not need any extra protection address or > even tunneling. Recall, that we are speaking about a protection > mechanism, not some OSPF/IS-IS hack. So this draft describes a > mechanism, where alternatives are predownloaded, and failure reaction > is done without involving the control plane. This means that we need > time for: > > 1. detecting the failure - T1 > 2. propagating the notification - T2 > 3. doing the failover - T3 > > The third one is now needed at all the routers, but it is done > parallel, so the network is fully recovered when the last node is > reconfigured, T1+T2+T3 time after the failure. And with a "local" > protection? We would need T1+T3 time. We are saying that we can afford > spending that extra T2 time in most of the networks to get the > previous advantages. > > Please do not mix the two drafts! > BR, > > Gabor > > P.S.: We are currently modifying draft-csaszar-ipfrr-fn-00, and > address its most important problems (e.g. authentication). If you can > wait till Monday, it may worth to read the new version. > > > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Curtis Villamizar > Sent: Friday, July 08, 2011 1:44 AM > To: Anton Smirnov > Cc: rtgwg@ietf.org > Subject: Re: discussion on fast notification work > > > Anton, > > A key point made below is. > > Protection at the PLR is always faster than inter-node protection. > > That said, if someone wants fast protection with full coverage, run MPLS with RSVP-TE and enable FRR and join the rest of the world that has already figured that out. Then there is complete (single failure) protection at every PLR. If multiple failures occur, then precomputed protection is impractical, notification schemes don't work, and flooding needs to work well and SPF and/or CSPF and installation of new FIB needs to be fast. > > Of course, those that think the idea of running MPLS is way too scary or think that reinventing the wheel is great fun can continue this conversation as long as they like. After all if people didn't think MPLS was scary we wouldn't even have IPFRR in the first place. > > Curtis > > > In message <4E159E72.1000400@cisco.com> > Anton Smirnov writes: > > Hi András, > > > 2. near instantaneous update of the FIB > > > I am no specialist in FIB implementations but it would appear to me that implementations and their requirements vary so much that intention itself of improving them all is incorrect and bound to fail. > > > > 1. near instantaneous notification of failures to neighbour and remote nodes > > Here is my vision of the problem: > My logic says that good inter-router notification cannot be made as fast as good intra-router API notification. So all good local repair techniques are intrinsically superior to [even good] inter-router notification approach. Superior first of all in speed of restoration but obviously things like deployment ease add attractiveness. > That is, remote notification technique's niche is squeezed; it can be applied as an aid to local repair techniques in those cases where network topology provides redundancy but local repair techniques can't use it. Since more elaborate local repair techniques are being developed which expand their coverage, niche for remote notification technique is contracting to the point when people don't want to bother with it (not even care to criticize it :-) ) > > I am guessing that authors of the proposal don't agree with this > part: "My logic says that good inter-router notification cannot be made as fast as good intra-router API." > May I suggest to authors to work on this perception? Otherwise I am afraid there again will be total misunderstanding and disinterest. > > Anton > > > On 07/07/2011 12:52 PM, András Császár wrote: > > Dear All, > > > > As a recap, the basic idea was to explore how one could approximate 1. > > near instantaneous notification of failures to neighbour and remote > > nodes 2. near instantaneous update of the FIB > > > > 1 is approximated by a completely dataplane-based fast notification (FN) framework. > > 2 is approximated by pre-calculating and pre-downloading backup routes for RELEVANT failures and doing the FIB update from within the linecard. > > > > Since last IETF, based on the comments we received, we have been working on (and prototyping) a method where FNs are propagated on the shortest path and each hop performs SHA256 authentication in the dataplane before forwarding the packet. > > > > Important highlights proving feasibility: > > > > - In a 1000-node area with a diameter of 20 hops and 500k external routes, the backup FIB even in a very bad case is not bigger than 30MB with very diverse ECMP (10 ECMP alternatives for each destination). The download of this backup FIB size should be no problem. > > > > - A naive serial FIB update procedure after a failure in the above network takes less than 15ms within a dataplane card (assuming 5MT/sec memory performance and 1 memory controller). But there may be more intelligent approaches, such as a lazy (on-demand) FIB update. > > > > - In reality, our calculations show that typically only nodes between > > 1 and 3 hops away need to prepare for a failure, i.e. failures only > > 1-2-3 hops away are RELEVANT (the above calculation assumes that for > > each destination needs to prepare for all failures of the 20-hop > > diameter) > > > > - Very important: the FN packet always proceeds AHEAD OF normal data > > packets, so re-routed data packets typically find nodes on their way > > which have finished or almost finished reconfiguring. (In this way > > long links do not cause problems as both FN and normal data packets > > are delayed the same.) > > > > - Pre-calculation complexity is in the same order of magnitude as with Not-Via, and it's done "offline" > > > > > > Conclusions of our naďve implementation are the following: > > > > - The solution can be implemented on a current platform, and we don't > > seem to use any operation that would make it less useful on other > > platforms including e.g. EZChip NP-4 > > > > - A FN packet can be originated in less than 200us (micro-sec) after > > failure detection > > > > - An FN packet can be forwarded at each hop in ca. 180us (this already > > includes SHA256 verification and duplicate check!) > > > > > > András > > > > > >> -----Original Message----- > >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On > >> Behalf Of Alia Atlas > >> Sent: 2011. július 6. 22:57 > >> To: rtgwg@ietf.org > >> Subject: discussion on fast notification work > >> > >> The last 2 IETFs, we have had discussions about the idea of fast > >> notification, as described in draft-lu-fast-notification-framework, > >> draft-lu-fn-transport-00, and draft-csaszar-ipfrr-fn-00. > >> > >> Since then, I have not seen substantial discussion or interest on the > >> mailing list. If you are interested in this work, have questions > >> about it, or would like to see RTGWG continue to discuss it, please > >> send email to this mailing list. I'd like to see this conversation > >> happening here before IETF. > >> > >> Thanks, > >> Alia From curtis@occnc.com Fri Jul 8 19:35:24 2011 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 0730621F8B48 for ; Fri, 8 Jul 2011 19:35:24 -0700 (PDT) X-Quarantine-ID: <7+UFQ86skV3H> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E1 hex): cc: G\341bor S\341ndor Enye[...] X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+UFQ86skV3H for ; Fri, 8 Jul 2011 19:35:23 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4685321F8B3B for ; Fri, 8 Jul 2011 19:35:23 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p692ZGLo059791; Fri, 8 Jul 2011 22:35:16 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107090235.p692ZGLo059791@harbor.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: discussion on fast notification work In-reply-to: Your message of "Fri, 08 Jul 2011 09:53:01 EDT." Date: Fri, 08 Jul 2011 22:35:16 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 02:35:24 -0000 In message Alia Atlas writes: > > > [Alia] I think that the idea of this 10-15ms is problematic for > intercontinental networks. > If, according to wikipedia, the delay through optical fiber is about > 1000km/5ms - then that means to go from Boston to San Francisco, takes > approximately 21.6ms. Closer to 34 msec measured. This is due to the fiber not being laid in a straight line. Not that it alters your point any. This is also why detection time is usually taken to be a nominally order 10 msec. If a break in a 20 msec fiber occurs in the middle, then it will be 10 msec before either end sees any signal degregation (lights out in this case) and knows about the fault. There is usually a small hold up time before declaring the link down (a few msec). At that point The fastest possible protection is when both sides independently make a local repair. Lets also not go down the "who cares" rathole wrt the 50 msec number. > [Alia] I do think an advantage of this approach is the lack of concern > about micro-forwarding loops during convergence. Of course, those can > still be an issue with just cost changes, so I don't think it changes > the need for such technology. Microforwarding loops are always a concern in hop by hop forwarding. Like it or not, RSVP-TE has the advantage that the path either works or it doesn't. Either the traffic arrives somehow, maybe not optimally during a protection transient, or it gets blackholed. Again, lets not go too far down the "who cares" rathole. Curtis From curtis@occnc.com Fri Jul 8 20:12:56 2011 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 67BA221F8BB0 for ; Fri, 8 Jul 2011 20:12:56 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E1 hex): cc: Andr\341s Cs\341sz\341r ; Fri, 8 Jul 2011 20:12:55 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id A343521F8BA5 for ; Fri, 8 Jul 2011 20:12:55 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p693Cqkh060283; Fri, 8 Jul 2011 23:12:52 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107090312.p693Cqkh060283@harbor.orleans.occnc.com> To: Alia Atlas From: Curtis Villamizar Subject: Re: discussion on fast notification work In-reply-to: Your message of "Fri, 08 Jul 2011 09:42:00 EDT." Date: Fri, 08 Jul 2011 23:12:52 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 03:12:56 -0000 In message Alia Atlas writes: > > Andras, > > 2011/7/8 András Császár : > > > And yes, it may be not exactly as fast as local repair but: > > - It is still fast enough and can deliver sub-50ms repair > > The basic concern about non-local repair is the speed of light delay. > If one is looking at an intercontinental network, these delays add up > so that sub-50ms is not physically possible. > > I think your argument is that the notification arrives with/before the > traffic, but that reasoning isn't very convincing to me... Perhaps > you can explain it better here? > > Alia Its that faster-light again. Fixes just about anything! :-) Curtis btw - Typical optical reach with latest transmission equipment and good clean fiber is on the order of 2,000 km today (a bit more). Therefore links are rarely over 10 msec, except across oceans which can be much longer. Network diameters can be a few 100 msec. Unless they use satellites in which case the delays can be absurdly long (1/4-1/2 sec RTT for one hop to a LEO satellite). From curtis@occnc.com Fri Jul 8 20:31:06 2011 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 E64CB21F8B93 for ; Fri, 8 Jul 2011 20:31:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E1 hex): To: G\341bor S\341ndor Enye[...] X-Spam-Flag: NO X-Spam-Score: 0.072 X-Spam-Level: X-Spam-Status: No, score=0.072 tagged_above=-999 required=5 tests=[AWL=-2.629, BAYES_00=-2.599, GB_SUMOF=5, MIME_8BIT_HEADER=0.3] 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 Jz-dxgZ2CaOC for ; Fri, 8 Jul 2011 20:31:06 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id E186421F8BB5 for ; Fri, 8 Jul 2011 20:31:05 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p693V16t060427; Fri, 8 Jul 2011 23:31:01 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107090331.p693V16t060427@harbor.orleans.occnc.com> To: Gábor Sándor Enyedi From: Curtis Villamizar Subject: Re: discussion on fast notification work In-reply-to: Your message of "Fri, 08 Jul 2011 17:08:29 +0200." Date: Fri, 08 Jul 2011 23:31:01 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 03:31:07 -0000 If there is a failure of the link B-C, then traffic can't go B-C-B. Assume that the failure is in roughly the middle of the ocean and the fiber is broken in both directions. At each end, a local repair is done. With MPLS FRR (or IPFRR), the path is D-C-D-E-F-G-H-A (the merge point can be closer to the egress than the other end of the failed link. The case that would be more interesting is if A-B failed. MPLS FRR works fine for this case, but IPFRR is a bit more problematic with the two hops to get to the alternate route (ie: D-C-B-C-D-E...). For such a case, where two links cross an ocean, you would think that the provider might be smart enough to put a link between B-G and C-F if B-C and F-G are the cross Atlantic links. That way neither working or protection traffic never crosses the ocean more than once. Given that cross Atlantic links are really expensive that would seem like a reasonable thing to do. Curtis In message Gábor Sándor Enyedi writes: > > Hi Alia, > > Andras already went home, so I try to answer your question. Actually, this is the first good reason against FN today... > > So, when I was saying in my previous mail that we think we can live with that "T2" time, I was not completely precise. I still believe, that in most cases T2 must not be more than 10-15ms, but your right, there are huge links with serious delay. Let's see such an example, and check whether local protection is better or not. > > | > A--H > | | > B G > | | > C F > | | > D--E > | > > If there is problem with the figure, I just wanted to draw a cycle with 6 nodes, where packets enter to the network at node D and leave it at node A. Suppose that the two parts of the network are at the other side of the Atlantic ocean, say A, B, G, H are in America and C, D, E, F are in Europe. In this way both link B-C and F-G have huge delay (say 40ms). Suppose that all the link costs are uniform (so the shortest path is D-C-B-A) and link B-C goes down, so we need to do something. Since there is no other possibility, the failed link cannot be bypassed in America, we need to "ask" for help from nodes in Europe in order to use the "other" transatlantic link. Observe how unrealistic this case is; after the failure, the shortest path from B to A crosses the ocean TWICE! > > What will happen, if we apply FN here? Suppose that we are right, and we can forward FN packets extremely rapidly (as it is the case), so the speed of an FN packet is (almost) equal to a normal packet's speed. In order to make the example simple, now suppose that processing FN packets takes no time (it is not 0, but it will not make any difference, if you want, I can later explain why). So when B detects the failure, it will send out the notification (A will send it out as well, but there is a bigger latency along that path, so it is not important). You are right, the packet will not make it in time, and more than 50ms is needed to get to node D after the failure (there is the detection time). But none of the packets will be lost, packets received by B will be sent back to C. Since those packets will get exactly the same delay thanks to link B-C, when they arrive to C, C is already reconfigured (since the FN packet was there before), and they will be sent to D. The situati! on is the same with D. So when will node A get the first packet after the failure? We can say that this time is the sum of the delays of link B-C, C-D, D-E, E-F, F-G, G-H, H-A. And yes, there can be some reordering, but currently the hosts can deal with it (see e.g. RTP hosts). > > What is the situation if we have some local repair? If we have some local repair at node B, it will send the packets back to C as well. So after the failure the packets will follow path D-C-B-C-D-E-F-G-H-A. When will node A get the first packet after the failure? We get it again, we need to sum the delays of link B-C, C-D, D-E, E-F, F-G, G-H, H-A. OK, now we do not have reordering... > > Actually, you may say that if we need to forward the FN packets too far (I mean too many hops away, here physical distance is not an issue), we may cause congestion. You are right, but first, we found that usually we need to reroute quite locally, i.e. we do not need to get farther then 2-3 hops. Second, you cannot avoid this problem if you use some local rerouting; sooner or later the IGP will converge, and you will need to change the routing of C, and at that point, C needs to send both packets in link B-C and C-D back to D, which may cause a congestion. > > OK, this example may not cover all the possible situations, but I think based on this you may found out all the remaining ones. No doubt, this solution is not perfect, I am just saying that this is the best I know for IP networks. For plain IP it is better even than using maximally redundant trees, since it can deal with SRLG-s, and MRT-s cannot. Moreover, it is as simple as it is possible, which is not the case with redundant trees, as you saw yesterday. :) > BR, > > Gabor > > P.S.: We are just modifying the draft to use flooding instead of redundant trees and SHA-256 authentication. Even with this, in our prototype the forwarding time of an FN packet was almost equal to the forwarding time of a big (1500 byte) data packet. > > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Friday, July 08, 2011 3:42 PM > To: András Császár > Cc: rtgwg@ietf.org > Subject: Re: discussion on fast notification work > > Andras, > > 2011/7/8 András Császár : > > > And yes, it may be not exactly as fast as local repair but: > > - It is still fast enough and can deliver sub-50ms repair > > The basic concern about non-local repair is the speed of light delay. > If one is looking at an intercontinental network, these delays add up so that sub-50ms is not physically possible. > > I think your argument is that the notification arrives with/before the traffic, but that reasoning isn't very convincing to me... Perhaps you can explain it better here? > > Alia From gabor.sandor.enyedi@ericsson.com Sat Jul 9 00:24:15 2011 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 5277C21F866C for ; Sat, 9 Jul 2011 00:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=-2.039, BAYES_00=-2.599, GB_SUMOF=5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYtGksLPAUT9 for ; Sat, 9 Jul 2011 00:24:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 24DD921F8547 for ; Sat, 9 Jul 2011 00:24:13 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-5d-4e18021bc9e2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D4.45.20773.B12081E4; Sat, 9 Jul 2011 09:24:12 +0200 (CEST) Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.227]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 9 Jul 2011 09:24:11 +0200 From: =?iso-8859-1?Q?G=E1bor_S=E1ndor_Enyedi?= To: "curtis@occnc.com" Date: Sat, 9 Jul 2011 09:24:11 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw96KFvD/CaM2gZTSS23R73M8KY1wAHrdB/ Message-ID: References: Your message of "Fri, 08 Jul 2011 17:08:29 +0200." ,<201107090331.p693V16t060427@harbor.orleans.occnc.com> In-Reply-To: <201107090331.p693V16t060427@harbor.orleans.occnc.com> Accept-Language: hu-HU, en-US Content-Language: hu-HU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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: Sat, 09 Jul 2011 07:24:15 -0000 Curtis, Forgive me, I made a mistake. Initially, there were only 6 nodes in the cyc= le, then I modified it, but not consequently. Naturally, this is an example= for the failure of link A-B. Please consider the example as I would wrote = there " link A-B goes down". Sorry for confusing you or anyone else. After reconsidering the example, do you still think that this idea does not= worth even to speak about it? Gabor ________________________________________ Felad=F3: curtis@occnc.com [curtis@occnc.com] K=FCldve: 2011. j=FAlius 9. 5:31 C=EDmzett: G=E1bor S=E1ndor Enyedi M=E1solatot kap: Alia Atlas; Andr=E1s Cs=E1sz=E1r; rtgwg@ietf.org T=E1rgy: Re: discussion on fast notification work If there is a failure of the link B-C, then traffic can't go B-C-B. Assume that the failure is in roughly the middle of the ocean and the fiber is broken in both directions. At each end, a local repair is done. With MPLS FRR (or IPFRR), the path is D-C-D-E-F-G-H-A (the merge point can be closer to the egress than the other end of the failed link. The case that would be more interesting is if A-B failed. MPLS FRR works fine for this case, but IPFRR is a bit more problematic with the two hops to get to the alternate route (ie: D-C-B-C-D-E...). For such a case, where two links cross an ocean, you would think that the provider might be smart enough to put a link between B-G and C-F if B-C and F-G are the cross Atlantic links. That way neither working or protection traffic never crosses the ocean more than once. Given that cross Atlantic links are really expensive that would seem like a reasonable thing to do. Curtis In message G=E1bor S=E1ndor Enyedi writes: > > Hi Alia, > > Andras already went home, so I try to answer your question. Actually, thi= s is the first good reason against FN today... > > So, when I was saying in my previous mail that we think we can live with = that "T2" time, I was not completely precise. I still believe, that in most= cases T2 must not be more than 10-15ms, but your right, there are huge lin= ks with serious delay. Let's see such an example, and check whether local p= rotection is better or not. > > | > A--H > | | > B G > | | > C F > | | > D--E > | > > If there is problem with the figure, I just wanted to draw a cycle with 6= nodes, where packets enter to the network at node D and leave it at node A= . Suppose that the two parts of the network are at the other side of the At= lantic ocean, say A, B, G, H are in America and C, D, E, F are in Europe. I= n this way both link B-C and F-G have huge delay (say 40ms). Suppose that a= ll the link costs are uniform (so the shortest path is D-C-B-A) and link B-= C goes down, so we need to do something. Since there is no other possibilit= y, the failed link cannot be bypassed in America, we need to "ask" for help= from nodes in Europe in order to use the "other" transatlantic link. Obser= ve how unrealistic this case is; after the failure, the shortest path from = B to A crosses the ocean TWICE! > > What will happen, if we apply FN here? Suppose that we are right, and we = can forward FN packets extremely rapidly (as it is the case), so the speed = of an FN packet is (almost) equal to a normal packet's speed. In order to m= ake the example simple, now suppose that processing FN packets takes no tim= e (it is not 0, but it will not make any difference, if you want, I can lat= er explain why). So when B detects the failure, it will send out the notifi= cation (A will send it out as well, but there is a bigger latency along tha= t path, so it is not important). You are right, the packet will not make it= in time, and more than 50ms is needed to get to node D after the failure (= there is the detection time). But none of the packets will be lost, packets= received by B will be sent back to C. Since those packets will get exactly= the same delay thanks to link B-C, when they arrive to C, C is already rec= onfigured (since the FN packet was there before), and they will be sent to = D. The situati! on is the same with D. So when will node A get the first packet after the = failure? We can say that this time is the sum of the delays of link B-C, C-= D, D-E, E-F, F-G, G-H, H-A. And yes, there can be some reordering, but curr= ently the hosts can deal with it (see e.g. RTP hosts). > > What is the situation if we have some local repair? If we have some local= repair at node B, it will send the packets back to C as well. So after the= failure the packets will follow path D-C-B-C-D-E-F-G-H-A. When will node A= get the first packet after the failure? We get it again, we need to sum th= e delays of link B-C, C-D, D-E, E-F, F-G, G-H, H-A. OK, now we do not have = reordering... > > Actually, you may say that if we need to forward the FN packets too far (= I mean too many hops away, here physical distance is not an issue), we may = cause congestion. You are right, but first, we found that usually we need t= o reroute quite locally, i.e. we do not need to get farther then 2-3 hops. = Second, you cannot avoid this problem if you use some local rerouting; soon= er or later the IGP will converge, and you will need to change the routing = of C, and at that point, C needs to send both packets in link B-C and C-D b= ack to D, which may cause a congestion. > > OK, this example may not cover all the possible situations, but I think b= ased on this you may found out all the remaining ones. No doubt, this solut= ion is not perfect, I am just saying that this is the best I know for IP ne= tworks. For plain IP it is better even than using maximally redundant trees= , since it can deal with SRLG-s, and MRT-s cannot. Moreover, it is as simpl= e as it is possible, which is not the case with redundant trees, as you saw= yesterday. :) > BR, > > Gabor > > P.S.: We are just modifying the draft to use flooding instead of redundan= t trees and SHA-256 authentication. Even with this, in our prototype the fo= rwarding time of an FN packet was almost equal to the forwarding time of a = big (1500 byte) data packet. > > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of= Alia Atlas > Sent: Friday, July 08, 2011 3:42 PM > To: Andr=E1s Cs=E1sz=E1r > Cc: rtgwg@ietf.org > Subject: Re: discussion on fast notification work > > Andras, > > 2011/7/8 Andr=E1s Cs=E1sz=E1r : > > > And yes, it may be not exactly as fast as local repair but: > > - It is still fast enough and can deliver sub-50ms repair > > The basic concern about non-local repair is the speed of light delay. > If one is looking at an intercontinental network, these delays add up so = that sub-50ms is not physically possible. > > I think your argument is that the notification arrives with/before the tr= affic, but that reasoning isn't very convincing to me... Perhaps you can e= xplain it better here? > > Alia From curtis@occnc.com Sat Jul 9 11:26:18 2011 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 59AB221F88D6 for ; Sat, 9 Jul 2011 11:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, 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 giKMxQ7Cqfnt for ; Sat, 9 Jul 2011 11:26:18 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id B9E7521F88AC for ; Sat, 9 Jul 2011 11:26:17 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p69IN5gY072133; Sat, 9 Jul 2011 14:23:05 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107091823.p69IN5gY072133@harbor.orleans.occnc.com> To: Lucy yong From: Curtis Villamizar Subject: Re: draft-so-yong-rtgwg-cl-framework-04.txt In-reply-to: Your message of "Fri, 08 Jul 2011 20:01:12 -0000." <2691CE0099834E4A9C5044EEC662BB9D0498BA8C@dfweml503-mbx.china.huawei.com> Date: Sat, 09 Jul 2011 14:23:05 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jul 2011 18:26:18 -0000 In message <2691CE0099834E4A9C5044EEC662BB9D0498BA8C@dfweml503-mbx.china.huawei.com> Lucy yong writes: > > Alia and Curtis, > > This is indeed a long work. In very early work, some mechanisms were > proposed and were considered as local implementation that should not > be standardized. > > With this encourage now, I am fine to include some mechanisms. > > Regards, > Lucy Lucy, Just to be clear about this. What was proposed in the distant past was protocol extensions with no clear requirements and inadequately stated semantics. It was not clear what those extensions were trying to accomplish and it was not clear what mechanisms were being proposed. We definitely don't want a repeat of that. A framework document should propose general mechanisms for accommodating the requirements outlined in a requirements document. Where there is consensus on a single mechanism, the framework document can list only one mechanism or list mechanisms that were considered and rejected as well as the mechanism chosen. For brevity, were there was no controversy, it is best to provide only the mechansim selected. In rare cases where it proves exceedingly difficult to acheive concensus on a single mechanism, it is OK to list more than one with the selection deferred until the insights of more implementation or deployment experience is available. This should be avoided if at all possible. A framework document should not propose protocol extensions. It may however indicate protocols on which extension will be built, and indicate the general nature of the extensions and which requirements will be addressed by specific types of extensions. Note that consensus as alway means working group and IETF consensus. It is up to the work group chairs to determine if lack of comment indicates lack of objection and implies consensus or if lack of comment indicates a lack of interest among vendors and providers. Curtis From kireeti@juniper.net Sat Jul 9 13:43:15 2011 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 B324021F8A08 for ; Sat, 9 Jul 2011 13:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mPRSy3xtKsG for ; Sat, 9 Jul 2011 13:43:15 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 26F3B21F89EB for ; Sat, 9 Jul 2011 13:43:13 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKThi9X7l954bRock39mBLORe2ZUGKVeOF@postini.com; Sat, 09 Jul 2011 13:43:14 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Sat, 9 Jul 2011 13:39:26 -0700 From: Kireeti Kompella To: =?utf-8?B?R8OhYm9yIFPDoW5kb3IgRW55ZWRp?= Date: Sat, 9 Jul 2011 13:39:19 -0700 Subject: Re: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw+eEtRTfoQOLUdScuhHPLV/rYW0w== Message-ID: <36105F23-A248-4027-BAD0-2124180D338C@juniper.net> References: <201107090331.p693V16t060427@harbor.orleans.occnc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: Sat, 09 Jul 2011 20:43:15 -0000 T24gSnVsIDksIDIwMTEsIGF0IDA6MjQsICJHw6Fib3IgU8OhbmRvciBFbnllZGkiIDxnYWJvci5z YW5kb3IuZW55ZWRpQGVyaWNzc29uLmNvbTxtYWlsdG86Z2Fib3Iuc2FuZG9yLmVueWVkaUBlcmlj c3Nvbi5jb20+PiB3cm90ZToNCg0KQWZ0ZXIgcmVjb25zaWRlcmluZyB0aGUgZXhhbXBsZSwgZG8g eW91IHN0aWxsIHRoaW5rIHRoYXQgdGhpcyBpZGVhIGRvZXMgbm90IHdvcnRoIGV2ZW4gdG8gc3Bl YWsgYWJvdXQgaXQ/DQoNCiJZb3UgY2FuIHNwZWFrIHlvdXIgbWluZA0KQnV0IG5vdCBvbiBteSB0 aW1lIiAtLSBCLiBKb2VsDQoNCktpcmVldGkNCg== From curtis@occnc.com Sat Jul 9 18:51:40 2011 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 0559921F8A19 for ; Sat, 9 Jul 2011 18:51:40 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E1 hex): To: G\341bor S\341ndor Enye[...] X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[AWL=-2.339, BAYES_00=-2.599, GB_SUMOF=5, MIME_8BIT_HEADER=0.3] 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 TPVtfoIUpP6F for ; Sat, 9 Jul 2011 18:51:39 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id E483121F89EB for ; Sat, 9 Jul 2011 18:51:38 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6A1pXG5077918; Sat, 9 Jul 2011 21:51:33 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107100151.p6A1pXG5077918@harbor.orleans.occnc.com> To: Gábor Sándor Enyedi From: Curtis Villamizar Subject: Re: discussion on fast notification work In-reply-to: Your message of "Sat, 09 Jul 2011 09:24:11 +0200." Date: Sat, 09 Jul 2011 21:51:33 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 01:51:40 -0000 Gabor, Work that are worth continuing is work that service providers would like to deploy or that has some compelling value. I haven't seen any provider interest or a compelling value. By the example you are implying that the value is pushing the protection back to a prior node. That was rejected in MPLS FRR becuase 1) FRR is fastest at the PLR, 2) protection is deployed for the benefit of a minority of traffic with strict requirements (who are paying a lot more for service) and diffserv takes case of any interim congestion for that high priority traffic and 3) protection is temporary and the ultimate solution is to reroute the working path and get it protected again. Moving the repair to a prior node increases the period during which loss occurs but reduces the delay once protection occurs. This is a tradeoff that was discussed a decade ago when MPLS FRR was discussed and the decision was made to favor the faster repair. I don't see why that hasn't served the industry well and don't see why it needs to be different for IPFRR. So I see that technical advantage but don't see the demand for this. Curtis In message Gábor Sándor Enyedi writes: Curtis, Forgive me, I made a mistake. Initially, there were only 6 nodes in the cycle, then I modified it, but not consequently. Naturally, this is an example for the failure of link A-B. Please consider the example as I would wrote there " link A-B goes down". Sorry for confusing you or anyone else. After reconsidering the example, do you still think that this idea does not worth even to speak about it? Gabor ________________________________________ Feladó: curtis@occnc.com [curtis@occnc.com] Küldve: 2011. július 9. 5:31 Címzett: Gábor Sándor Enyedi Másolatot kap: Alia Atlas; András Császár; rtgwg@ietf.org Tárgy: Re: discussion on fast notification work If there is a failure of the link B-C, then traffic can't go B-C-B. Assume that the failure is in roughly the middle of the ocean and the fiber is broken in both directions. At each end, a local repair is done. With MPLS FRR (or IPFRR), the path is D-C-D-E-F-G-H-A (the merge point can be closer to the egress than the other end of the failed link. The case that would be more interesting is if A-B failed. MPLS FRR works fine for this case, but IPFRR is a bit more problematic with the two hops to get to the alternate route (ie: D-C-B-C-D-E...). For such a case, where two links cross an ocean, you would think that the provider might be smart enough to put a link between B-G and C-F if B-C and F-G are the cross Atlantic links. That way neither working or protection traffic never crosses the ocean more than once. Given that cross Atlantic links are really expensive that would seem like a reasonable thing to do. Curtis In message Gábor Sándor Enyedi writes: > > Hi Alia, > > Andras already went home, so I try to answer your question. Actually, this is the first good reason against FN today... > > So, when I was saying in my previous mail that we think we can live with that "T2" time, I was not completely precise. I still believe, that in most cases T2 must not be more than 10-15ms, but your right, there are huge links with serious delay. Let's see such an example, and check whether local protection is better or not. > > | > A--H > | | > B G > | | > C F > | | > D--E > | > > If there is problem with the figure, I just wanted to draw a cycle with 6 nodes, where packets enter to the network at node D and leave it at node A. Suppose that the two parts of the network are at the other side of the Atlantic ocean, say A, B, G, H are in America and C, D, E, F are in Europe. In this way both link B-C and F-G have huge delay (say 40ms). Suppose that all the link costs are uniform (so the shortest path is D-C-B-A) and link B-C goes down, so we need to do something. Since there is no other possibility, the failed link cannot be bypassed in America, we need to "ask" for help from nodes in Europe in order to use the "other" transatlantic link. Observe how unrealistic this case is; after the failure, the shortest path from B to A crosses the ocean TWICE! > > What will happen, if we apply FN here? Suppose that we are right, and we can forward FN packets extremely rapidly (as it is the case), so the speed of an FN packet is (almost) equal to a normal packet's speed. In order to make the example simple, now suppose that processing FN packets takes no time (it is not 0, but it will not make any difference, if you want, I can later explain why). So when B detects the failure, it will send out the notification (A will send it out as well, but there is a bigger latency along that path, so it is not important). You are right, the packet will not make it in time, and more than 50ms is needed to get to node D after the failure (there is the detection time). But none of the packets will be lost, packets received by B will be sent back to C. Since those packets will get exactly the same delay thanks to link B-C, when they arrive to C, C is already reconfigured (since the FN packet was there before), and they will be sent to D. The situati! on is the same with D. So when will node A get the first packet after the failure? We can say that this time is the sum of the delays of link B-C, C-D, D-E, E-F, F-G, G-H, H-A. And yes, there can be some reordering, but currently the hosts can deal with it (see e.g. RTP hosts). > > What is the situation if we have some local repair? If we have some local repair at node B, it will send the packets back to C as well. So after the failure the packets will follow path D-C-B-C-D-E-F-G-H-A. When will node A get the first packet after the failure? We get it again, we need to sum the delays of link B-C, C-D, D-E, E-F, F-G, G-H, H-A. OK, now we do not have reordering... > > Actually, you may say that if we need to forward the FN packets too far (I mean too many hops away, here physical distance is not an issue), we may cause congestion. You are right, but first, we found that usually we need to reroute quite locally, i.e. we do not need to get farther then 2-3 hops. Second, you cannot avoid this problem if you use some local rerouting; sooner or later the IGP will converge, and you will need to change the routing of C, and at that point, C needs to send both packets in link B-C and C-D back to D, which may cause a congestion. > > OK, this example may not cover all the possible situations, but I think based on this you may found out all the remaining ones. No doubt, this solution is not perfect, I am just saying that this is the best I know for IP networks. For plain IP it is better even than using maximally redundant trees, since it can deal with SRLG-s, and MRT-s cannot. Moreover, it is as simple as it is possible, which is not the case with redundant trees, as you saw yesterday. :) > BR, > > Gabor > > P.S.: We are just modifying the draft to use flooding instead of redundant trees and SHA-256 authentication. Even with this, in our prototype the forwarding time of an FN packet was almost equal to the forwarding time of a big (1500 byte) data packet. > > > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: Friday, July 08, 2011 3:42 PM > To: András Császár > Cc: rtgwg@ietf.org > Subject: Re: discussion on fast notification work > > Andras, > > 2011/7/8 András Császár : > > > And yes, it may be not exactly as fast as local repair but: > > - It is still fast enough and can deliver sub-50ms repair > > The basic concern about non-local repair is the speed of light delay. > If one is looking at an intercontinental network, these delays add up so that sub-50ms is not physically possible. > > I think your argument is that the notification arrives with/before the traffic, but that reasoning isn't very convincing to me... Perhaps you can explain it better here? > > Alia From curtis@occnc.com Sat Jul 9 18:56:09 2011 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 2F1FD21F8A1E for ; Sat, 9 Jul 2011 18:56:09 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char C3 hex): cc: G\303\241bor S\303\241ndor En[...] X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.545, 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 xSm5HoB8Jly1 for ; Sat, 9 Jul 2011 18:56:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 89FB321F8A1D for ; Sat, 9 Jul 2011 18:56:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6A1u5BL078019; Sat, 9 Jul 2011 21:56:05 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107100156.p6A1u5BL078019@harbor.orleans.occnc.com> To: Kireeti Kompella From: Curtis Villamizar Subject: Re: discussion on fast notification work In-reply-to: Your message of "Sat, 09 Jul 2011 13:39:19 PDT." <36105F23-A248-4027-BAD0-2124180D338C@juniper.net> Date: Sat, 09 Jul 2011 21:56:05 -0400 Sender: curtis@occnc.com Cc: "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 01:56:09 -0000 In message <36105F23-A248-4027-BAD0-2124180D338C@juniper.net> Kireeti Kompella writes: On Jul 9, 2011, at 0:24, "GĂĄbor SĂĄndor Enyedi" > wrote: > > After reconsidering the example, do you still think that this idea > does not worth even to speak about it? > > "You can speak your mind > But not on my time" -- B. Joel > > Kireeti That seemed a bit harsh. I prefer the "I see the technical advantage but ..." summary. Maybe I need to lighten up. :-) Curtis From Andras.Csaszar@ericsson.com Mon Jul 11 02:00:46 2011 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 B410121F8893 for ; Mon, 11 Jul 2011 02:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.393 X-Spam-Level: X-Spam-Status: No, score=-5.393 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] 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 sq7mnI8M1xWu for ; Mon, 11 Jul 2011 02:00:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CAB0221F8684 for ; Mon, 11 Jul 2011 02:00:45 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-dd-4e1abbbca554 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 08.CB.20773.CBBBA1E4; Mon, 11 Jul 2011 11:00:44 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.174]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 11 Jul 2011 11:00:43 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: Alia Atlas Date: Mon, 11 Jul 2011 11:00:43 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: Acw9dNB5YFmdDFAnQO27OJwCeohIkACLOR1g Message-ID: <8DCD771BDA4A394E9BCBA8932E8392973216EA6884@ESESSCMS0363.eemea.ericsson.se> References: <8DCD771BDA4A394E9BCBA8932E8392973216EA6154@ESESSCMS0363.eemea.ericsson.se> <4E159E72.1000400@cisco.com> <8DCD771BDA4A394E9BCBA8932E8392973216EA640A@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 11 Jul 2011 09:00:46 -0000 Hi Alia, A node, in FN-flooding mode, multicasts the received FN message to ALL OSPF= neighbours in the same area. To facilitate this, the IGP in each node pre-= installs a multicast route entry for the multicast group address of the FN = service and adds a link to each of its neighbour to the if list of the mult= icast route. The multicast route is flagged as a bidirectional multicast, i= .e. the incoming packet is replicated to each i/f in the list except the in= coming i/f. Since this is kind of dataplane based flooding, the linecards need to check= for duplicate FN (i.e. flooding may cause the FN message to loop back) bef= ore forwarding. (On our not too recent HW platform, an FN packet spends 180= micro-sec in the linecard including this duplicate check AND SHA256 authen= tication before a replica appears on the oifs.) A key point: in order to facilitate sub-50ms fail-over, a node remote to th= e failure does NOT need to have changed its FIB within 50ms, but it needs t= o have changed its FIB by the time re-routed packets reach it. Non-re-route= d packets just keep going on the old path until meeting up a node which is = already re-configured. During fail-over, a node may be in two states when considering a given dest= ination: - Old next-hop - New NH (activated backup) In case of the PLR, the old NH is dead, leading to packet loss. Any other n= ode with old NHs keep forwarding traffic towards the PLR. A PLR after detecting the failure: - originates and sends an FN packet (200 micro-sec) - starts FIB update within the linecard (just like in any other IPFRR, e.g.= LFA) So, connectivity is interrupted as long as the PLR performed the FIB update= (T3). Then packets go to a new NH, i.e. reaching it after T3+T2 time, i.e.= T2 is the propagation time to re-use Gabor's notation. The FN packet reaches 1-hop radius nodes in T2+200us, then the one-hop radi= us nodes perform FIB update, and they are ready by T2+200us+T3.=20 So, if the nodes perform FIB update roughly in the same time, then the 1-ho= p node has an old route for 200usec after receiving the first re-routed pac= ket.=20 So, in the end, traffic finds not-yet-ready nodes altogether for T3 + k x 2= 00us time in the worst case, i.e. T3 FIB update in the PLR then in each hop= 200 micro-sec. In an extreme case, it may happen that the PLR needs to change the route an= d then only a remote node k hops away makes another repairing route change. In this case:=20 FN reaches the remote node in: 200us + k x (T2 + 200us). Remote node is ready with FIB by 200us + k x (T2 + 200us) + T3 First re-routed packet reaches remote node by T3 (PLR FIB update) + k x T2. I.e. remote node keeps forwarding packets on old route for maximally (k+1) = x 200us. With any reasonable network diameter, this is lower than 4-5ms. Andr=E1s > -----Original Message----- > From: Alia Atlas [mailto:akatlas@gmail.com]=20 > Sent: 2011. j=FAlius 8. 15:42 > To: Andr=E1s Cs=E1sz=E1r > Cc: Anton Smirnov; rtgwg@ietf.org > Subject: Re: discussion on fast notification work >=20 > Andras, >=20 > 2011/7/8 Andr=E1s Cs=E1sz=E1r : >=20 > > And yes, it may be not exactly as fast as local repair but: > > - It is still fast enough and can deliver sub-50ms repair >=20 > The basic concern about non-local repair is the speed of light delay. > If one is looking at an intercontinental network, these delays add up > so that sub-50ms is not physically possible. >=20 > I think your argument is that the notification arrives=20 > with/before the traffic, > but that reasoning isn't very convincing to me... Perhaps=20 > you can explain > it better here? >=20 > Alia > = From kireeti@juniper.net Mon Jul 11 14:04:31 2011 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 CECB811E8201 for ; Mon, 11 Jul 2011 14:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DepWPdfJurdo for ; Mon, 11 Jul 2011 14:04:31 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 3694011E816B for ; Mon, 11 Jul 2011 14:04:31 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKThtlXcph5+TkI0NzIouHGDlrUJxK82SR@postini.com; Mon, 11 Jul 2011 14:04:31 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 11 Jul 2011 14:02:10 -0700 From: Kireeti Kompella To: "curtis@occnc.com" Date: Mon, 11 Jul 2011 14:02:09 -0700 Subject: Re: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: AcxADcz58WxrnY7jQImmcoyIQWSnUQ== Message-ID: References: <201107100156.p6A1u5BL078019@harbor.orleans.occnc.com> In-Reply-To: <201107100156.p6A1u5BL078019@harbor.orleans.occnc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US 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: Mon, 11 Jul 2011 21:04:31 -0000 On Jul 9, 2011, at 18:56 , Curtis Villamizar wrote: >> "You can speak your mind >> But not on my time" -- B. Joel >=20 > That seemed a bit harsh. Wasn't intended that way. The harsh reality is the limited time and limited processing capacity I hav= e [where is Eldon Tyrell when you need him???] Another way of looking at the quote is, don't throttle the sender -- but do= allow receivers to filter. That's not harsh, is it? I spent considerable time working out the transatlantic example -- what dat= a path is being considered, what link is assumed to fail. I got there even= tually, but a simple "Consider the path D->A, and suppose link BA [not CB] = fails" would have saved me time. Beyond that, I fail to see the benefit of this approach, and several things= about it make me uneasy, if not queasy. I'm not sure the "technical advan= tage" of this outweighs the concerns ... and am not willing to put in the t= ime to work it out. Kireeti. From Andras.Csaszar@ericsson.com Mon Jul 11 23:37:53 2011 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 5A8D921F9150 for ; Mon, 11 Jul 2011 23:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iY1hCFUCh4Qh for ; Mon, 11 Jul 2011 23:37:52 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8264621F9154 for ; Mon, 11 Jul 2011 23:37:52 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-4e-4e1bebbed938 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FC.26.09774.EBBEB1E4; Tue, 12 Jul 2011 08:37:50 +0200 (CEST) Received: from ESESSCMS0363.eemea.ericsson.se ([169.254.1.174]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 12 Jul 2011 08:37:50 +0200 From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r?= To: Kireeti Kompella Date: Tue, 12 Jul 2011 08:37:49 +0200 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: AcxADcz58WxrnY7jQImmcoyIQWSnUQAT99ug Message-ID: <8DCD771BDA4A394E9BCBA8932E8392973216F240E0@ESESSCMS0363.eemea.ericsson.se> References: <201107100156.p6A1u5BL078019@harbor.orleans.occnc.com> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: hu-HU, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== 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, 12 Jul 2011 06:37:53 -0000 Hi Kireeti, > Beyond that, I fail to see the benefit of this approach, and=20 > several things about it make me uneasy, if not queasy. I'm=20 > not sure the "technical advantage" of this outweighs the=20 > concerns ... and am not willing to put in the time to work it out. I understand you don't have time to work out any details of some else's pro= posal but given a little time could you share your concerns at least: we'd = try to answer those if possible. Thanks, Andr=E1s= From mshand@cisco.com Tue Jul 12 05:52:36 2011 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 1A4CD21F906C for ; Tue, 12 Jul 2011 05:52:36 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYZh+Nje+6BF for ; Tue, 12 Jul 2011 05:52:35 -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 5385021F9069 for ; Tue, 12 Jul 2011 05:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mshand@cisco.com; l=1530; q=dns/txt; s=iport; t=1310475155; x=1311684755; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Z+dx/LifrKduUwaIdYBg/VRMOB5OYvymE0p7ywQbdxs=; b=SEUHs2mqJaHP/To3hg2Xrw8+Xc3XQwNv/FHbC0aDKASvMBSpiQkD6sXO KHPXnHC89EJaPfT9aQJo6WR68Twej8AGnSgc1A3ZXmNMSOnNPQ6P9sjrj jKdFBQu2GC8kGUU2XSELymJ29ihEvo71GeZiIosbYbDBf2z/d3vVl2obt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcGAF5CHE6Q/khR/2dsb2JhbABTmDWOenetJp4YhjoEklyEf4tN X-IronPort-AV: E=Sophos;i="4.65,521,1304294400"; d="scan'208";a="42294042" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 12 Jul 2011 12:52:33 +0000 Received: from [64.103.65.122] (dhcp-gpk02-vlan300-64-103-65-122.cisco.com [64.103.65.122]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6CCqX2q031036 for ; Tue, 12 Jul 2011 12:52:33 GMT Message-ID: <4E1C4390.6000907@cisco.com> Date: Tue, 12 Jul 2011 13:52:32 +0100 From: mike shand User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: rtgwg@ietf.org Subject: Re: discussion on fast notification work References: <201107100156.p6A1u5BL078019@harbor.orleans.occnc.com> <8DCD771BDA4A394E9BCBA8932E8392973216F240E0@ESESSCMS0363.eemea.ericsson.se> In-Reply-To: <8DCD771BDA4A394E9BCBA8932E8392973216F240E0@ESESSCMS0363.eemea.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 List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 12:52:36 -0000 There seem to be two issues here, of which the first is perhaps the most pertinent :- 1) Is there any interest in adding significant complexity in order to provide 100% protection coverage? The evidence seems to be that there is not. There have been a number of such solutions (mine included) proposed both here and in the academic literature, and so far none of them have received overwhelming support. Those wanting 100% protection seem quite happy to invoke MPLS FRR. 2) Is non-local repair a viable option? The arguments against this seem to be:- a) However fast the propagation is made, it is still limited by "speed of light". It has been argued that the data packets are also so limited, so it doesn't matter, but I still have to be convinced that this is always true. b) The pre-computation of remote repairs significantly increases both the computational complexity and the size of FIB information required. It is not clear how this scales in large real world SP topologies. c) It is asserted that "re-route points" are typically only 2 or 3 hops away. This is true, but there are significant counter examples. This seems to lead to a choice between less than 100% repair coverage or even more complex remote repair scenarios. My feeling is that to change from a local repair to a remote repair paradigm requires the demonstration of very significant benefits, and I haven't seen that. Indeed, quite the opposite. Mike From curtis@occnc.com Tue Jul 12 08:13:14 2011 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 6D46B21F8EE6 for ; Tue, 12 Jul 2011 08:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[AWL=-0.249, BAYES_05=-1.11] 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 G9w0p6nbGEdA for ; Tue, 12 Jul 2011 08:13:14 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9D49E21F8EE3 for ; Tue, 12 Jul 2011 08:13:13 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6CFDC4K060103 for ; Tue, 12 Jul 2011 11:13:12 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107121513.p6CFDC4K060103@harbor.orleans.occnc.com> To: rtgwg@ietf.org Subject: meeting overlap with CCAMP From: Curtis Villamizar Date: Tue, 12 Jul 2011 11:13:12 -0400 Sender: curtis@occnc.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 15:13:14 -0000 The meeting seems to overlap with CCAMP and they are not listed as being in the same room. Can the meeting time be moved to avoid the conflict? Friday is wide open as far as conflicts with routing area. Curtis From tony.li@tony.li Tue Jul 12 08:28:22 2011 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 09B5021F8D1C for ; Tue, 12 Jul 2011 08:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwOClYblJbre for ; Tue, 12 Jul 2011 08:28:21 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by ietfa.amsl.com (Postfix) with ESMTP id D4C1721F8C40 for ; Tue, 12 Jul 2011 08:28:20 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta05.emeryville.ca.mail.comcast.net with comcast id 73RH1h0010b6N64A53UJWA; Tue, 12 Jul 2011 15:28:18 +0000 Received: from sjc-vpn7-1948.cisco.com ([128.107.239.233]) by omta03.emeryville.ca.mail.comcast.net with comcast id 73Ts1h03352qHCY8P3Tyfg; Tue, 12 Jul 2011 15:28:14 +0000 Subject: Re: discussion on fast notification work Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tony Li In-Reply-To: <4E1C4390.6000907@cisco.com> Date: Tue, 12 Jul 2011 08:27:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201107100156.p6A1u5BL078019@harbor.orleans.occnc.com> <8DCD771BDA4A394E9BCBA8932E8392973216F240E0@ESESSCMS0363.eemea.ericsson.se> <4E1C4390.6000907@cisco.com> To: mike shand X-Mailer: Apple Mail (2.1084) 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, 12 Jul 2011 15:28:22 -0000 On Jul 12, 2011, at 5:52 AM, mike shand wrote: > Is there any interest in adding significant complexity in order to = provide 100% protection coverage? I believe that there is interest and benefit from providing 100% = protection coverage without resorting to MPLS. However, adding significant complexity is NOT the intent. ;-) =46rom a strategic point of view, it would be very beneficial for a pure = packet switching network to provide similar functionality to the = connection oriented overlay hybrid approach that MPLS represents. This = would allow networks to have the benefits of faster protection without = the maintenance overhead of MPLS. The alternative is to admit that IP is inferior to MPLS. Regards, Tony From alvaro.retana@hp.com Tue Jul 12 09:17:54 2011 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 19D1F21F8CF3 for ; Tue, 12 Jul 2011 09:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 X4beRC3+s6rU for ; Tue, 12 Jul 2011 09:17:53 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0361E21F8CF1 for ; Tue, 12 Jul 2011 09:17:52 -0700 (PDT) Received: from G1W0400.americas.hpqcorp.net (g1w0400.americas.hpqcorp.net [16.236.31.10]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0006.atlanta.hp.com (Postfix) with ESMTPS id 84B81C324; Tue, 12 Jul 2011 16:17:52 +0000 (UTC) Received: from G1W0396.americas.hpqcorp.net (16.236.31.9) by G1W0400.americas.hpqcorp.net (16.236.31.10) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 12 Jul 2011 16:17:05 +0000 Received: from GVW1338EXA.americas.hpqcorp.net ([16.236.29.11]) by G1W0396.americas.hpqcorp.net ([16.236.31.9]) with mapi; Tue, 12 Jul 2011 17:17:05 +0100 From: "Retana, Alvaro" To: "rtgwg@ietf.org" Date: Tue, 12 Jul 2011 17:17:03 +0100 Subject: WGLC:draft-ietf-rtgwg-lfa-applicability Thread-Topic: WGLC:draft-ietf-rtgwg-lfa-applicability Thread-Index: AcxAryLsK3gY4tzoQE2zFkxEHWc5vw== Message-ID: <24646CE17826CF4A8DF71F9856C7E6565927F837CB@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_24646CE17826CF4A8DF71F9856C7E6565927F837CBGVW1338EXAame_" MIME-Version: 1.0 Cc: "draft-ietf-rtgwg-lfa-applicability@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, 12 Jul 2011 16:17:54 -0000 --_000_24646CE17826CF4A8DF71F9856C7E6565927F837CBGVW1338EXAame_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! This message is to start a Working Group Last Call for 'LFA applicability i= n SP networks' (http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-applicabili= ty-02). To give everyone enough time, this Last Call will end on August 1, 2011. The intent is to publish this document as an Informational RFC. Please send any comments to the WG list. Thanks! Alvaro. --_000_24646CE17826CF4A8DF71F9856C7E6565927F837CBGVW1338EXAame_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

This m= essage is to start a Working Group Last Call for ‘LFA applicability = in SP networks’ (http://tools.ietf= .org/html/draft-ietf-rtgwg-lfa-applicability-02).

 

To giv= e everyone enough time, this Last Call will end on August 1, 2011.

 

= The intent is to publish this document as an Informational RFC.<= /span>

 

Ple= ase send any comments to the WG list.

 

Thanks!

=

 

Alvaro. =

 

= --_000_24646CE17826CF4A8DF71F9856C7E6565927F837CBGVW1338EXAame_-- From curtis@occnc.com Tue Jul 12 09:20:47 2011 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 97A8821F8D00 for ; Tue, 12 Jul 2011 09:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.516, 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 bo+u0k7oPtuj for ; Tue, 12 Jul 2011 09:20:44 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id A18AD21F8CFF for ; Tue, 12 Jul 2011 09:20:42 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6CGKePY061926; Tue, 12 Jul 2011 12:20:40 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107121620.p6CGKePY061926@harbor.orleans.occnc.com> To: Tony Li From: Curtis Villamizar Subject: Re: discussion on fast notification work In-reply-to: Your message of "Tue, 12 Jul 2011 08:27:52 PDT." Date: Tue, 12 Jul 2011 12:20:40 -0400 Sender: curtis@occnc.com Cc: rtgwg@ietf.org, mike shand X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 16:20:47 -0000 In message Tony Li writes: > > > On Jul 12, 2011, at 5:52 AM, mike shand wrote: > > > Is there any interest in adding significant complexity in order to > > provide 100% protection coverage? > > > I believe that there is interest and benefit from providing 100% > protection coverage without resorting to MPLS. > > However, adding significant complexity is NOT the intent. ;-) > > > From a strategic point of view, it would be very beneficial for a pure > > packet switching network to provide similar functionality to the > > connection oriented overlay hybrid approach that MPLS represents. > > This would allow networks to have the benefits of faster protection > > without the maintenance overhead of MPLS. > > The alternative is to admit that IP is inferior to MPLS. We can always count on you for a content free slogan. > Regards, > Tony Tony, IP and MPLS (RSVP-TE) do different things. IP is massively scalable. MPLS is not as scalable and by itself does nothing (which some transport guys are a long way from figuring out). MPLS has TE capability and has better support for protection. IP over MPLS is a powerful combination. IP alone within a provider domain is a little more simple, but not by much. IPFRR is inferior to MPLS FRR. The latter can never form transient microloops in the post protection transition and has other drawbacks. Get used to it. The whole point of IPFRR (if there is a point to IPFRR at all) is to provide a simple solution to improve on IP convergence. If a more complex solution is needed, trying to retrofit full coverage protection onto IP is a losing proposition. MPLS is not all that complicated and with MPLS mesh groups and zero bandwidth reservation can be trivial to configure for FRR benefits only. Curtis From curtis@occnc.com Tue Jul 12 11:12:55 2011 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 607C821F8E47 for ; Tue, 12 Jul 2011 11:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.523 X-Spam-Level: X-Spam-Status: No, score=-1.523 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_51=0.6] 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 4y-OJQl2lYh0 for ; Tue, 12 Jul 2011 11:12:50 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 41A3821F8D6B for ; Tue, 12 Jul 2011 11:12:49 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6CICft7063180; Tue, 12 Jul 2011 14:12:41 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107121812.p6CICft7063180@harbor.orleans.occnc.com> To: rtgwg@ietf.org Subject: suggestion additions to cl-framework From: Curtis Villamizar Date: Tue, 12 Jul 2011 14:12:41 -0400 Sender: curtis@occnc.com X-Mailman-Approved-At: Tue, 12 Jul 2011 11:50:47 -0700 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 18:12:55 -0000 The CL-framework document is draft-so-yong-rtgwg-cl-framework-04 . The remainder of this email is suggested additions to the CL framework. It looks a lot like an internet-draft, but it isn't. It was easier to validate the xml2rfc by making this self contained. There has been a discussion of this among the co-author of draft-so-yong-rtgwg-cl-framework-04 with Ning and Lucy agreeing to merge this with the existing work (three if you count me) and the rest (three) not weighing in yet. Lucy has provided general comments and wants to read through the proposed additions again and provide further more detailed comments. The discussion at the upcoming IETF meeting should still focus on draft-so-yong-rtgwg-cl-framework-04 first and foremost. This email is just to let the WG to get a general idea of what we are planning to merge in. I'm entirely OK if the WG or WG chairs decides that it is premature to discuss these additions at all at the meeting. Any merge would have to occur after the IETF meeting, though a merged draft is likely to have been exchanged among the co-authors prior to the meeting. The screwup on this is entirely my fault for taking way too long to get around to writing this. Curtis RTGWG C. Villamizar, Ed. Internet-Draft Infinera Corporation Intended status: Informational July 10, 2011 Expires: January 11, 2012 Composite Link Framework Additions draft-villamizar-cl-framework-additions-XX Abstract This document provides some suggested additions to the existing Composite Link Framework document. This is not a real internet-draft in that it is not submitted as it missed the deadline for IETF-81 (though it looks convincing enough). It exists for discussion purposes only. It is hoped that ideas herein will be incorporated into the Composite Link Framework internet-draft after IETF-81. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 11, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as Villamizar Expires January 11, 2012 [Page 1] Internet-Draft CL Framework Additions July 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Architecture Summary . . . . . . . . . . . . . . . . . . . 3 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture Tradeoffs . . . . . . . . . . . . . . . . . . . . 4 2.1. Scalability Motivations . . . . . . . . . . . . . . . . . 4 2.2. Reducing Routing Information and Exchange . . . . . . . . 4 2.3. Reducing Signaling Load . . . . . . . . . . . . . . . . . 5 2.4. Reducing Forwarding State . . . . . . . . . . . . . . . . 6 2.5. Avoiding Route Oscillation . . . . . . . . . . . . . . . . 6 3. New Challenges . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Control Plane Challenges . . . . . . . . . . . . . . . . . 7 3.1.1. Delay and Jitter Sensitive Routing . . . . . . . . . . 7 3.1.2. Local Control of Traffic Distribution . . . . . . . . 8 3.1.3. Path Symetry Requirements . . . . . . . . . . . . . . 8 3.1.4. Requirements for Contained LSP . . . . . . . . . . . . 9 3.1.5. Retaining Backwards Compatibility . . . . . . . . . . 9 3.2. Data Plane Challenges . . . . . . . . . . . . . . . . . . 10 3.2.1. Very Large LSP . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Very Large Microflows . . . . . . . . . . . . . . . . 11 3.2.3. Traffic Ordering Constraints . . . . . . . . . . . . . 11 4. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 11 4.1. Link Bundling . . . . . . . . . . . . . . . . . . . . . . 11 5. Mechanisms Proposed in Other Documents . . . . . . . . . . . . 12 5.1. Loss and Delay Measurement . . . . . . . . . . . . . . . . 13 5.2. Link Bundle Extensions . . . . . . . . . . . . . . . . . . 13 5.3. Fat PW and Entorpy Labels . . . . . . . . . . . . . . . . 13 5.4. Multipath Extensions . . . . . . . . . . . . . . . . . . . 14 6. Required Protocol Extensions and Mechanisms . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Villamizar Expires January 11, 2012 [Page 2] Internet-Draft CL Framework Additions July 2011 1. Introduction This document provides additional detail intended to be merged with the composite link framework document. The focus is on existing protocol mechanisms and extensions that will be required to accommodate functionality that is called for in the composite links requirements document but unsupported or inadequately supported by existing protocols [I-D.ietf-rtgwg-cl-requirement]. 1.1. Architecture Summary Networks aggregate information, both in the control plane and in the data plane, as a means to acheive scalability. A tradeoff exists between the needs of scalability and the needs to identify differing path and link characteristics and differeing requirements among flows contained within further aggregated traffic flows. These tradeoffs are discussed in detail in Section 2. Some aspects of Composite Link requirements present challenges for which multiple solutions may exist. In Section 3 various challenges and potential approaches are discussed. A subset of the functionality called for in [I-D.ietf-rtgwg-cl-requirement] is available through MPLS Link Bundling [RFC4201]. Link bundling and other existing standards applicable to Composite Link are covered in Section 4. The most straightforward means of supporting Composite Link requirements is to extend MPLS and in particular to extend link bundling. Extensions which have already been proposed in other documents which are applicable to Composite Link are discussed in Section 5. Goals of most new protocol work within IETF is to reuse existing protocol encapsulations and mechanisms where they meet requirements and extend existing mechanisms such that additional complexity is minimized while meeting requirements and such that backwards compatibility is preserved to the extent it is practical to do so. These goals are considered in proposing a framework for further protocol extensions and mechanisms in Section 6. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Villamizar Expires January 11, 2012 [Page 3] Internet-Draft CL Framework Additions July 2011 1.3. Definitions [ ... to be completed ... ] 2. Architecture Tradeoffs Scalability and stability are critical considerations in protocol design where protocols may be used in large network. Composite Link is applicable to large networks, and therefore scalability must be a major consideration. Some of the requirements of Composite Link require additional information to be carried in situations where component links differ in some significant way. 2.1. Scalability Motivations In the interest of scalability information is aggregated in situations where information about a large amount of network capacity or a large amount of network demand provides is adequate to meet requirements. Routing information is aggregated to reduce the amount of information exchange related to routing and to simplify route computation. Reducing the amount of information allows the exchange of information during a large routing change to be accomplished more quickly, and simplifying route computation improves convergence time after very significant network faults which cannot be handled by preprovisioned or precomputed protection mechanisms. Neglecting scaling issues can result in performance issues, such as slow convergence. Neglecting scaling in some cases can result in netowrks which perform so poorly as to become unstable. 2.2. Reducing Routing Information and Exchange Link bundling at the very least provides a means of aggregating control plane information. Even where the all-ones component link supported by link bundling is not used, the amount of control information is reduced by the average number of component links in a bundle. Fully deaggregating link bundle information would negate this benefit. If there is a need to deagregate, such as to distinguish between groups of links within specified ranges of delay, then no more deaggregation than is necessary should be done. For example, in supporting the requirement for heterogeneious component links, it makes little sense to fully deagregate link bundles when adding support for groups of component links with common attributes within a link bundle can maintain most of the benefit of Villamizar Expires January 11, 2012 [Page 4] Internet-Draft CL Framework Additions July 2011 aggregation while adequately supporting the requirement to support heterogeneious component links. Routing information exchange is also reduced by making sensible choices regarding the amount of change to link parameters that require link readvertisement. For example, if delay measurements include queuing delay, then a much more course granularity of delay measurement would be called for than if the delay does not include queuing and is dominated by geographic delay (speed of light delay). 2.3. Reducing Signaling Load Aggregating traffic into very large hierarchical LSP in the core very substantially reduces the number of LSP that need to be signaled and the number of path computations any given LSR will be required to perform when a major network fault occurs. In the extreme, applying MPLS to a very large network without hierarchy could exceed the 20 bit label space. For example, in a network with 4,000 nodes, with 2,000 on either side of a cutset, would have 4,000,000 LSP crossing the cutset. Even in a degree four cutset, an uneven distribution of LSP across the cutset, or the loss of one link would result in a need to exceed the size of the label space. Among provider networks, 4,000 access nodes is not at all large. In less extreme cases, having each node terminate hundreds of LSP to acheive a full mesh creates a very large computational load. The time complexity of one CSPF computation is order(N log N), where L is proportional to N, and N and L are the number of nodes and number of links, respectively. If each node must perform order(N) computations when a fault occurs, then the computational load increases as order(N^2 log N) as the number of nodes increases. In practice at the time of writing, this imposes a limit of a few hundred nodes in a full mesh of MPLS LSP before the computational load is sufficient to result in unacceptable convergence times. When the number of nodes grows too large, the solution is to use the MPLS PSC hierarchy [RFC4206]. A core within the hierarchy can divide the topology into M regions of on average N/M nodes. Within a region the computational load is reduced by more than M^2. Within the core, the computational load generally becomes quite small since M is usually a fairly small number (a few tens of regions) and each region is generally attached to the core in typically only two or three places on average. Using hierarchy improves scaling but has two consequences. First, hierarchy effectively forces the use of platform label space. When a Villamizar Expires January 11, 2012 [Page 5] Internet-Draft CL Framework Additions July 2011 containing LSP is rerouted, the labels assigned to the contained LSP cannot be changed but may arrive on a different interface. Second, hierarchy results in much larger LSP. These LSP today are larger than any single component link and therefore force the use of the all-ones component in link bundles. 2.4. Reducing Forwarding State MPLS hierarchy has the benefit of reducing the amount of forwarding state. Using the example from the previous section, the worst case generally occurs at borders with the core. For example, consider a network with approximately 1,000 nodes divided into 10 regions. At the edges, each node requires 1,000 LSP to other edge nodes. The edge nodes also require 100 intra-region LSP. Within the core, if the core has only 3 attachments to each region the core LSR have less than 100 intra-core LSP. At the border cutset between the core and a given region, in this example there are 100 edge nodes with inter-region LSP crossing that cutset, destined to 900 other edge nodes. That yields forwarding state for on the order of 90,000 LSP at the border cutset. These same routers need only reroute well under 200 LSP when a multiple fault occurs, as long as only links are affected and a border LSR does not go down. In the core, the forwarding state is greatly reduced. If inter- region LSP have different characteristics, it makes sense to make use of aggregates with different characteristics. Rather than exchange information about every inter-region LSP within the intra-core LSP it makes more sense to use multiple intra-core LSP between pairs of core nodes, each aggregating sets of inter-region LSP with common characteristics or common requirements. 2.5. Avoiding Route Oscillation Networks can become unstable when a feedback loop exists such that moving traffic to a link causes a metric such as delay to increase, which then causes traffic to move elsewhere. For example, the original ARPAnet routing used a delay based cost metric and proved prone to route oscillations [DBP]. Delay may be used as a constraint in routing for high priority traffic, where the movement of traffic cannot impact the delay. The safest way to measure delay is to make measurements based on traffic which is prioritized such that it is queued ahead of the traffic which will be affected. This is a reasonable measure of delay for high priority traffic for which constraints have been set which allow this type of traffic to consume only a fraction of link capacities with the remaining capacity available to lower priority traffic. Villamizar Expires January 11, 2012 [Page 6] Internet-Draft CL Framework Additions July 2011 Any measurement of jitter (delay variation) that is used in route decision is likely to cause oscillation. Jitter that is caused by queuing effects and cannot be measured using a very high priority measurement traffic flow. It may be possible to find links with contrained queuing delay or jitter using a theoretical maximum or a probability based bound on queuing delay or jitter at a given priority based on the types and amounts of traffic accepted and combining that theoretical limit with a measured delay at very high priority. 3. New Challenges New technical challenges are posed by [I-D.ietf-rtgwg-cl-requirement] in both the control plane and data plane. Among the more difficult challenges are maintaining new requirements such as the requirements related delay or jitter for contained LSP. Backwards compatibility poses numerous challenges. Advertising groups of component links with similar characteristics is in itself not difficult, but doing so in a highly backwards compatible manner poses problems. The combination of ingress control over LSP placement and retaining an ability to move traffic as demands dictate can pose challenges and such requirements can even be conflicting. 3.1. Control Plane Challenges Some of the control plane requirements are particularly challenging when considering handling flows with aggregated flows and the requirements to minimize impact on scalability. Potentially conflicting are requirements for jitter and requirements for stability. Potentially conflicting are the requirements for ingress control of a large number of parameters, and the requirements for local control needed to achieve traffic balance across a composite link. These challenges and potential solutions are discussed in the following sections. 3.1.1. Delay and Jitter Sensitive Routing Delay and jitter sensitive routing are called for in [I-D.ietf-rtgwg-cl-requirement] in requirements FR#2, FR#7, FR#8, FR#9, FR#15, FR#16, FR#17, FR#18. Requirement FR#17 is particularly probelmatic, calling for constraints on jitter. Villamizar Expires January 11, 2012 [Page 7] Internet-Draft CL Framework Additions July 2011 A tradeoff exists between scaling benefits of aggergating information, and potential benefits of using a finer granularity in delay reporting. To maintain the scaling benefit, measured link delay for any given composite link SHOULD be aggregated into a small number of delay ranges. IGP-TE extensions MUST be provided which advertise the available capacities for each of the selected ranges. For path selection of delay sensitive LSP, the ingress SHOULD bias link metrics based on available capacity and select a low cost path which meets LSP total path delay criteria. To communicate the requirements of an LSP, the ERO MUST be extended to indicate the per link constraints. To communicate the type of resource used, the RRO SHOULD be extended to carry an identification of the group that is used to carry the LSP at each link bundle hop. 3.1.2. Local Control of Traffic Distribution Many requirements in [I-D.ietf-rtgwg-cl-requirement] suggest that a node immediately adjacent to a component link should have a high degree of control over how traffic is distributed, as long as network performance objectives are met. Particularly relevant are FR#18 and FR#19. The requirements to allow local control are potentially in conflict with requirement FR#21 which gives full control of component link select to the LSP ingress. While supporting this capability is manditory, use of this feature is optional per LSP. 3.1.3. Path Symetry Requirements Requirement FR#21 in [I-D.ietf-rtgwg-cl-requirement] includes a provision to bind both directions of a bidirectional LSP to the same component. This is easily achieved if the LSP is directly signaled across a composite link. This is not as easily achieved if a set of LSP with this requirement are signaled over a large hierarchical LSP which is in turn carried over a composite link. The basis for load distribution in such as case is the label stack. The labels in either direction are completely independent. This could be accomodated if the ingress, egress, and all midpoints of the hierarchical LSP make use of an entropy label in the distribution, and use only that entropy label. A solution for this problem may add complexity with very little benefit. There is little or no true benefit of using symetrical paths rather than component links of identical characteristics. Villamizar Expires January 11, 2012 [Page 8] Internet-Draft CL Framework Additions July 2011 3.1.4. Requirements for Contained LSP [I-D.ietf-rtgwg-cl-requirement] calls for new LSP contraints. These constraints include frequency of load balancing rearrangement, delay and jitter, packet ordering contraints, and path symetry. When LSP are contained within hierarchical LSP, there is no signaling available at midpoint LSR which identifies the contained LSP let alone providing the set of requirements uniqe to each contained LSP. Defining extensions to provide this information would severely implact scalability and defeat the purpose of aggregating control information and forwarding information into hierarchical LSP. For the same scalability reasons, not aggregating at all is not a vialble option. As pointed out in Section 3.1.3, the benefits of supporting symetric paths among LSP contained within hierarchical LSP may not be sufficient to justify the complexity of supporting this capability. For other LSP requirements, the most scalable solution is to provide multiple hierarchical LSP, each aggregating LSP with common requirements, and stating those same requirements for the hierarchical LSP. This is a network design technique rather than a protocol extension. This technique can accommodate delay and jitter requirements, frequency of load balancing rearrangement, packet ordering constraints. Section 5.4 provides additional mechanisms for addressing packet ordering constraints. 3.1.5. Retaining Backwards Compatibility Backwards compatibility and support for incremental deployment requries considering the impact of legacy LSR in the role of LSP ingress, and considering the impact of legacy LSR advertising ordinary links, Ethernet LAG as ordinary links, and link bundles. Legacy LSR in the role of LSP ingress cannot signal requirements which are not supported by their control plane software. The addition of additional capabilities has not impact on these LSR. These LSR however, being unaware of extensions, may try to make use of scarse resources which support specific requirements such as low delay. To a limited extent it may be possible to avoid this issue using existing mechanisms such as link administrative attributes and attribute affinities [RFC3209]. Legacy LSR advertsing ordinary links will not advertise attributes needed by some LSP. For example, there is no way to determine the delay or jitter characteristics of such a link. Legacy LSR advertsing Ethernet LAG pose additional problems. There is no way to Villamizar Expires January 11, 2012 [Page 9] Internet-Draft CL Framework Additions July 2011 determine that packet ordering constraints would be violated for LSP with strict packet ordering constraints, or that frequency of load balancing rearrangement constraints might be violated. Legacy LSR advertsing link bundles have no way to advertise the configured default behavior of the link bundle. Some link bundles may be configured to place each LSP on a single component link and therefore may not be able to accommodate an LSP which requires bandwidth in excess of the size of a component link. Some link bundles may be configured to spread all LSP over the all-ones component. For LSR using the all-ones component link, there is no documented procedure for correctly setting the "Maximum LSP Bandwidth". There is currently no way to indicate the largest microflow that could be supported by a link bundle using the all-ones component link. Having received the RRO, it is possible for an ingress to look for the all-ones component to identify such link bundles after having signaled at least one LSP. Whether any LSR collects this information on legacy LSR and makes use of it to set defaults, is an implementation choice. 3.2. Data Plane Challenges In order to maintain scalability, data plane forwarding retains state associated with the top label only. Data plane forwarding makes use of the top label to select a composite link, or a group of components within a composite link or for an LSP associated with a specific component selects a specific component link. For those LSP for which the LSP selects only the composite link or a group of a group of components within a composite link, the load balancing may make use of the entire label stack and in some cases may make use of information in the payload, though no state on specific contained LSP is retained. Load balancing makes use of techniques which allow large sets of flows to be moved to rearrange traffic. These large sets of flows may be at a finer granularity than contained LSP. Requirements to limit frequency of load balancing rearrangement can be adhered to by constraining the frequency at which these large sets of flows are moved. 3.2.1. Very Large LSP Very large LSP may exceed the capacity of any single component of a composite link. In some cases contained LSP may exceed the capacity of any single component. These LSP require the use of the equivalent of the all-ones component of a link bundle. Villamizar Expires January 11, 2012 [Page 10] Internet-Draft CL Framework Additions July 2011 3.2.2. Very Large Microflows Within a very large LSP there may be very large microflows, or very large flows which cannot be further subdivided for other reasons. Flows which cannot be subdivided must be no larger that the capacity of any single component. Current signaling provides no way to specify the largest microflow that a can be supported on a given link bundle in routing advertisements. Extensions which address this are discussed in Section 5.4. Absent extensions of this type, traffic containing microflows that are too large for a given composite link may be present. There is no data plane solution for this problem that would not require reordering traffic at the composite link egress. Some techniques are suseptible to statistical collisions where an algorithm to distribute traffic is unable to disambiguate traffic among two or more very large microflow where their sum is in excess of the capacity of any single component. Hash based algorithms which use too small a hash space are particularly suseptible and require a change in hash seed in the event that this were to occur. A change in hash seed is highly disruptive, causing traffic reordering among all traffic flows over which the hash function is applied. 3.2.3. Traffic Ordering Constraints Some LSP have strict traffic ordering constraints. Most notable among these are MPLS-TP LSP. In the absense of aggregation into hierarchical LSP, those LSP with strict traffic ordering constraints can be placed on individual component links if there is a means of identifying which LSP have such a constraint. If LSP with strict traffic ordering constraints are aggregated in hierarchical LSP, the hierarchical LSP capacity may exceed the capacity of any single component link. In such a case the load balancing for the containing may be constrained to look only at the top label and the first contained label. This and related issues are discussed further in Section 5.4. 4. Existing Mechanisms In MPLS the one mechanisms which support explicit signaling of multiple parallel links is Link Bundling [RFC4201]. 4.1. Link Bundling Link bundling supports advertisement of a set of homogenous links as a single route advertisement. Link bundling supports placement of an Villamizar Expires January 11, 2012 [Page 11] Internet-Draft CL Framework Additions July 2011 LSP on any single component link, or supports placement of an LSP on the all-ones component link. Not all link bundling implementations support the all-ones component link and there is no way to tell which support this feature and which do not. Based on [RFC4201] it is unclear how to advertise a link bundle for which the all-ones component link is available and used by default. Common practice is to violate the specification and set the Maximum LSP Bandwidth to the Available Bandwidth. [RFC6107] extends the procedures for hierarchical LSP but also extends link bundles. An LSP can be explicitly signaled to indicate that it is an LSP to be used as a component of a link bundle. While link bundling can be the basis for composite links, a significant number of small extension need to be added. 1. To support link bundles of heterogeneous links, a means of advertising the capacity available within a group of homogeneous needs to be provided. 2. Attributes need to be defined to support the following parameters for the link bundle or for a group of homogeneous links. A. delay range B. jitter (delay variation) range C. group metric D. all-ones component capable E. capable of dynamically balancing load F. largest supportable microflow G. abilities to support strict packet ordering requirements within contained LSP 5. Mechanisms Proposed in Other Documents A number of documents which at the time of writing are works in progress address parts of the requirements of Composite Link, or assist in making some of the goals acheivable. Villamizar Expires January 11, 2012 [Page 12] Internet-Draft CL Framework Additions July 2011 5.1. Loss and Delay Measurement Procedures for measuring loss and delay are provided in [I-D.ietf-mpls-loss-delay]. These are OAM based measurements. This work could be the basis of delay measurements and delay variation measurement used for metrics called for in [I-D.ietf-rtgwg-cl-requirement]. 5.2. Link Bundle Extensions A set of link bundling extensions are defined in [I-D.ietf-mpls-explicit-resource-control-bundle]. This document provides extensions to the ERO and RRO to explicitly control the labels and resources within a bundle used by an LSP. The extensions in this document could be further extended to support indicating a group of component links in the ERO or RRO, where the group is given an interface identification like the bundle itself. The extensions could also be further extended to support specification of the all-ones component link in the ERO or RRO. This document does not provide a means to advertise the link bundle components. 5.3. Fat PW and Entorpy Labels Two documents provide a means to add entropy for the purpose of improving load balance. MPLS encapsulation can bury information that is needed to identify microflows. These two documents allow a pseudowire ingress and LSP ingress respectively to add a label solely for the purpose of providing a finer granularity of microflow groups. [I-D.ietf-pwe3-fat-pw] allows pseudowires which carry a large volume of traffic, where microflows can be identified to be load balanced across multiple members of an Ethernet LAG or an MPLS link bundle. This is accomplished by adding a flow label below the pseudowire label in the MPLS label stack. For this to be effective the link bundle load balance must make use of the label stack up to and including this flow label. [I-D.kompella-mpls-entropy-label] provides a means for a LER to put an additional label known as an entropy label on the MPLS label stack. As defined, only the LER can add the entropy label and this label must be at the bottom of stack. If this restriction on entropy labels were to be relaxed, then core LSR could add entropy labels based on deep packet inspection and place the entropy label just below the label being acted on. This Villamizar Expires January 11, 2012 [Page 13] Internet-Draft CL Framework Additions July 2011 would be helpful in situations where the label stack depth to which load distribution can operate is limited by implementation or is limited for other reasons such as carrying both MPLS-TP and MPLS with entropy labels within the same hierarchical LSP. 5.4. Multipath Extensions The multipath extensions drafts address one aspect of Composite Link. These drafts deal with the issue of accommodating LSP which have strict packet ordering constraints in a network containing multipath. MPLS-TP has become the one important instance of LSP with strict packet ordering constraints nad has driven this work. [I-D.villamizar-mpls-tp-multipath] outlines requirements and gives a number of options for dealing with the apparent incompatibility of MPLS-TP and multipath. A preferred option is described. [I-D.villamizar-mpls-tp-multipath-te-extn] provides protocol extensions needed to implement the preferred option described in [I-D.villamizar-mpls-tp-multipath]. Other issues pertaining to multipath are also addressed. Means to advertise the largest microflow supportable are defined. Means to indicate the larges expected microflow within an LSP are defined. Issues related to hierarchy are addressed. 6. Required Protocol Extensions and Mechanisms The primary areas where additional protocol mechanisms are required include the following. 1. An extension to link bundling is needed to specify a group of components with common attributes. This can be a TLV defined within the link bundle that carries the same encapsulations as the link bundle. Two interface indices would be needed for each group. A. An index is needed that if included in an ERO would indicate the need to place the LSP on any one component within the group. B. A second index is needed that if included in an ERO would indicate the need to balance flows within the LSP across all components of the group. This is equivalent to the "all- ones" component for the entire bundle. Villamizar Expires January 11, 2012 [Page 14] Internet-Draft CL Framework Additions July 2011 2. A parameter is needed in the IGP-TE advertisement of delay and delay variation for links, link bundles, and forwarding adjacencies. Whatever mechanism is described must take precautions that insure that route oscillations cannot occur. 3. If a group is allowed to support all of the parameters of a link bundle, then a group TE metric would be accommodated. [ ... to be completed ... ] Note to co-authors: The following topics in the requirements document are not addressed. Since they are explicitly mentioned in the requirements document some mention of how they are supported is needed, even if to say nother needed to be done. If we conclude any particular topic is irrelevant, maybe the topic should be removed from the requirement document. At that point we could add the management requirements that have come up and were missed. 1. L3VPN RFC 4364, RFC 4797,L2VPN RFC 4664, VPWS, VPLS RFC 4761, RFC 4762 and VPMS VPMS Framework (draft-ietf-l2vpn-vpms-frmwk-requirements). 2. IP and LDP. This may be a matter of measuring, filtering the measurement, and deducting from the available bandwidth. 3. Migration may not be adequately covered in the backwards compatibility section. Comments on this? 4. Do we need more on load sharing oscillation? 5. Lower layer to upper layer communication (FR#7, FR#20) is addressed in mpls-tp-multipath where layers are MPLS, but not elsewhere. 6. IGP-TE extensions are not defined for delay and jitter, and frequency of load balancing rearrangement (FR#13, FR#15-FR#17). Constraints are not defined in RSVP-TE, but could be modeled after adminstrative attribute affinities in RFC3209 and elsewhere. 7. RSVP-TE preemption and soft-preemption need to be called out as solutions for FR#10. 8. FR#11 explicitly calls for adaptive multipath. This is assumed in the text so far but should be explicitly stated. More on hash methods might be needed pointing out that adaptive multipath as described in cl-requirements appendix does the job. Villamizar Expires January 11, 2012 [Page 15] Internet-Draft CL Framework Additions July 2011 9. The behavior of hash methods needs to be described in terms of FR#12 (minimally disruptive). Reseeding the hash violates FR#12. Using modulo operations if a link comes or goes violates FR#12 (as pointed out in RFC2991 and RFC2992). 10. Extending LDP is called for in DR#2. 11. DR#5 is not addressed (composite link spans multiple network topologies). May need to discuss this. 12. We may need a performance section to address #DR6, #DR7, though we do already have scalability discussion. The performance section would have to say "no worse than before, except were there was no alternative to make it very slightly worse" (in a bit more detail than that). 7. Security Considerations [ ... to be completed ... ] The security section provides job security for the Security Area Directors. The security considerations for MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [I-D.ietf-mpls-tp-security-framework]. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [DBP] Bertsekas, D., "Dynamic Behavior of Shortest Path Routing Algorithms for Communication Networks", IEEE Trans. Auto. Control 1982. [I-D.ietf-mpls-explicit-resource-control-bundle] Zamfir, A., Ali, Z., and P. Dimitri, "Component Link Recording and Resource Control for TE Links", draft-ietf-mpls-explicit-resource-control-bundle-10 (work in progress), April 2011. [I-D.ietf-mpls-loss-delay] Villamizar Expires January 11, 2012 [Page 16] Internet-Draft CL Framework Additions July 2011 Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", draft-ietf-mpls-loss-delay-03 (work in progress), June 2011. [I-D.ietf-mpls-tp-security-framework] Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP Security Framework", draft-ietf-mpls-tp-security-framework-01 (work in progress), May 2011. [I-D.ietf-pwe3-fat-pw] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow Aware Transport of Pseudowires over an MPLS Packet Switched Network", draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. [I-D.ietf-rtgwg-cl-requirement] Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. Yong, "Requirements for MPLS Over a Composite Link", draft-ietf-rtgwg-cl-requirement-04 (work in progress), March 2011. [I-D.kompella-mpls-entropy-label] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", draft-kompella-mpls-entropy-label-02 (work in progress), March 2011. [I-D.villamizar-mpls-tp-multipath] Villamizar, C., "Use of Multipath with MPLS-TP and MPLS", draft-villamizar-mpls-tp-multipath-01 (work in progress), March 2011. [I-D.villamizar-mpls-tp-multipath-te-extn] Villamizar, C., "Multipath Extensions for MPLS Traffic Engineering", draft-villamizar-mpls-tp-multipath-te-extn-00 (work in progress), July 2011. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Villamizar Expires January 11, 2012 [Page 17] Internet-Draft CL Framework Additions July 2011 Networks", RFC 5920, July 2010. [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011. Author's Address Curtis Villamizar (editor) Infinera Corporation 169 W. Java Drive Sunnyvale, CA 94089 Email: curtis@occnc.com Villamizar Expires January 11, 2012 [Page 18] From albert.e.manfredi@boeing.com Tue Jul 12 13:49:25 2011 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 1D34521F8C1F for ; Tue, 12 Jul 2011 13:49:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEaPHFxzdV8u for ; Tue, 12 Jul 2011 13:49:24 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA9521F8C15 for ; Tue, 12 Jul 2011 13:49:24 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p6CKnMA8027963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2011 13:49:23 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p6CKnLGd022229; Tue, 12 Jul 2011 13:49:21 -0700 (PDT) Received: from XCH-MWHT-01.mw.nos.boeing.com (xch-mwht-01.mw.nos.boeing.com [134.57.113.35]) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p6CKnAdk021964 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Tue, 12 Jul 2011 13:49:20 -0700 (PDT) Received: from XCH-MW-08V.mw.nos.boeing.com ([134.57.119.191]) by XCH-MWHT-01.mw.nos.boeing.com ([134.57.113.35]) with mapi; Tue, 12 Jul 2011 15:49:10 -0500 From: "Manfredi, Albert E" To: Tony Li , mike shand Date: Tue, 12 Jul 2011 15:49:07 -0500 Subject: RE: discussion on fast notification work Thread-Topic: discussion on fast notification work Thread-Index: AcxAqFeAGaFhPECQTQK4hXrVwRN1CgALIMcg Message-ID: References: <201107100156.p6A1u5BL078019@harbor.orleans.occnc.com> <8DCD771BDA4A394E9BCBA8932E8392973216F240E0@ESESSCMS0363.eemea.ericsson.se> <4E1C4390.6000907@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US 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: Tue, 12 Jul 2011 20:49:25 -0000 Tony Li wrote: > The alternative is to admit that IP is inferior to MPLS. Heh! Since MPLS sort of spun off from IP over ATM, I guess we'd be back to = those debates of the 1990s! Bert From jeff.tantsura@ericsson.com Tue Jul 12 15:44:08 2011 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 DD14D11E8088 for ; Tue, 12 Jul 2011 15:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNB0K1NPOJOX for ; Tue, 12 Jul 2011 15:44:08 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id E521511E809C for ; Tue, 12 Jul 2011 15:44:07 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p6CMi238005230; Tue, 12 Jul 2011 17:44:07 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.59]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 12 Jul 2011 18:44:02 -0400 From: Jeff Tantsura To: "Retana, Alvaro" , "rtgwg@ietf.org" Date: Tue, 12 Jul 2011 18:44:00 -0400 Subject: RE: WGLC:draft-ietf-rtgwg-lfa-applicability Thread-Topic: WGLC:draft-ietf-rtgwg-lfa-applicability Thread-Index: AcxAryLsK3gY4tzoQE2zFkxEHWc5vwANgEsA Message-ID: <0ED867EB33AB2B45AAB470D5A64CDBF60CCA0AA7C4@EUSAACMS0701.eamcs.ericsson.se> References: <24646CE17826CF4A8DF71F9856C7E6565927F837CB@GVW1338EXA.americas.hpqcorp.net> In-Reply-To: <24646CE17826CF4A8DF71F9856C7E6565927F837CB@GVW1338EXA.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0ED867EB33AB2B45AAB470D5A64CDBF60CCA0AA7C4EUSAACMS0701e_" MIME-Version: 1.0 Cc: "draft-ietf-rtgwg-lfa-applicability@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, 12 Jul 2011 22:44:09 -0000 --_000_0ED867EB33AB2B45AAB470D5A64CDBF60CCA0AA7C4EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support Regards, Jeff ________________________________ From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of R= etana, Alvaro Sent: Tuesday, July 12, 2011 09:17 To: rtgwg@ietf.org Cc: draft-ietf-rtgwg-lfa-applicability@tools.ietf.org Subject: WGLC:draft-ietf-rtgwg-lfa-applicability Hi! This message is to start a Working Group Last Call for 'LFA applicability i= n SP networks' (http://tools.ietf.org/html/draft-ietf-rtgwg-lfa-applicabili= ty-02). To give everyone enough time, this Last Call will end on August 1, 2011. The intent is to publish this document as an Informational RFC. Please send any comments to the WG list. Thanks! Alvaro. --_000_0ED867EB33AB2B45AAB470D5A64CDBF60CCA0AA7C4EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/support

 

Regards,
Jeff 

From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of Retana, Alvaro
Sent: Tuesday, July 12, 2011= 09:17
To: rtgwg@ietf.org
Cc: draft-ietf-rtgwg-lfa-applicability@tools.ietf.org
Subject: WGLC:draft-ietf-rtgwg-lfa-applicability

 

Hi!

 

This message is to start a Working Group Last Call for ‘LFA applicability in SP networks’ (<= font color=3Dblack>http://tools.ietf.org/html/d= raft-ietf-rtgwg-lfa-applicability-02).

 

To give everyone enough time, this Last Call will end = on August 1, 2011.

 

The intent is to publish this document as an Informati= onal RFC.

 

Please send any comments to the WG list.

 

Thanks!

 

Alvaro.

 

--_000_0ED867EB33AB2B45AAB470D5A64CDBF60CCA0AA7C4EUSAACMS0701e_-- From fu.xihua@zte.com.cn Wed Jul 13 01:01:02 2011 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 0064221F899C for ; Wed, 13 Jul 2011 01:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.189 X-Spam-Level: X-Spam-Status: No, score=-98.189 tagged_above=-999 required=5 tests=[AWL=1.896, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, 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 G5GX8rPOqo0q for ; Wed, 13 Jul 2011 01:01:01 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9525F21F8959 for ; Wed, 13 Jul 2011 01:01:00 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 48641754626705; Wed, 13 Jul 2011 15:56:38 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 94465.7842230421; Wed, 13 Jul 2011 16:00:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p6D80OYo099832; Wed, 13 Jul 2011 16:00:30 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) To: ning.so@verizonbusiness.com, andrew.g.malis@verizon.com, dave.mcdysan@verizon.com, lucyyong@huawei.com, cvillamizar@infinera.com, tony.li@tony.li Subject: Comment on draft-so-yong-rtgwg-cl-framework-04 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Wed, 13 Jul 2011 16:00:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-13 16:00:32, Serialize complete at 2011-07-13 16:00:32 Content-Type: multipart/alternative; boundary="=_alternative 002BFEF0482578CC_=" X-MAIL: mse02.zte.com.cn p6D80OYo099832 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, 13 Jul 2011 08:01:02 -0000 This is a multipart message in MIME format. --=_alternative 002BFEF0482578CC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQXV0aG9ycywNCg0KRmlyc3RseSwgSSBzdXBwb3J0IGl0IGJlIGEgV0cgZHJhZnQuIEkgcmVh ZCB0aHJvdWdoIHRoZSBkcmFmdCBhbmQgaGF2ZSBhIA0KZmV3IGNvbW1lbnRzIGFzIGZvbGxvd3M6 DQoNCjEuIFlvdSB3cm90ZSBpbiBzZWN0aW9uIDMNCg0KICJBbGwgY29tcG9uZW50IGxpbmtzIGlu IGEgY29tcG9zaXRlIGxpbmsgaGF2ZSB0aGUgc2FtZQ0KICAgZm9yd2FyZGluZyBhZGphY2VuY3ku IFRoZSBjb21wb3NpdGUgbGluayBmb3JtcyBvbmUgcm91dGluZyBpbnRlcmZhY2UNCiAgIGF0IHRo ZSBjb21wb3NpdGUgbGluayBlbmQgcG9pbnRzIGZvciBNUExTIGNvbnRyb2wgcGxhbmUuIEluIG90 aGVyDQogICB3b3JkcywgdHdvIHJvdXRlcnMgY29ubmVjdGVkIHZpYSBhIGNvbXBvc2l0ZSBsaW5r IGhhdmUgZm9yd2FyZGluZw0KICAgYWRqYWNlbmN5IGFuZCByb3V0aW5nIGFkamFjZW5jeS4gRWFj aCBjb21wb25lbnQgbGluayBvbmx5IGhhcw0KICAgc2lnbmlmaWNhbmNlIHRvIHRoZSBjb21wb3Np dGUgbGluaywgaS5lLiBpdCBkb2VzIG5vdCBhcHBlYXIgYXMgYQ0KICAgbGluayBpbiB0aGUgY29u dHJvbCBwbGFuZS4iDQoNCkEgRm9yd2FyZGluZyBBZGphY2VuY3kgKEZBKSBpcyBkZWZpbmVkIGlu IFtSRkM0MjA2XSBhcyBhIGRhdGEgbGluayBjcmVhdGVkIA0KZnJvbSBhbiBMU1AgYW5kIGFkdmVy dGlzZWQgaW4gdGhlIHNhbWUgaW5zdGFuY2Ugb2YgdGhlDQpjb250cm9sIHBsYW5lIHRoYXQgYWR2 ZXJ0aXNlcyB0aGUgVEUgbGlua3MgZnJvbSB3aGljaCB0aGUgTFNQIGlzIA0KY29uc3RydWN0ZWQu IEl0IGNvdWxkIG5vdCBhcHBseSB0byBvdmVybGF5ZXIgbW9kZWwuIFBscyByZWZlciB0byByZmM2 MTA3Lg0KSW4gdGhlIGNhc2Ugb2YgaGV0ZXJvZ2VuZW91cyBjb21wb25lbnQgbGlua3MsIGNvbXBv c2l0ZSBsaW5rIGNvdWxkIGJlIG9uZSANCkNQIGluc3RhbmNlIGRpZmZlcmVudCBmcm9tIGNvbXBv bmVudCBsaW5rcy4NCkkgc3VnZ2VzdCB5b3UgY2xhcmlmeSB0aGUgQ1AgaW5zdGFuY2UgYmV0d2Vl biBjb21wb3NpdGUgYW5kIGNvbXBvbmVudCBsaW5rIA0KaW4gdGhpcyBzZWN0aW9uLg0KDQoyLiBZ b3Ugd3JvdGUgaW4gc2VjdGlvbiA0DQoNCiIgYSBjb21wb25lbnQgbGluayBpcyBjb25maWd1cmVk IHRvIGNhcnJ5IHRyYWZmaWMgdW5kZXIgbm9ybWFsDQogICBvcGVyYXRpb247IHVuZGVyIHNvbWUg c2l0dWF0aW9uLCBvcGVyYXRvciBtYXkgd2FudCB0byBjb25maWd1cmUgYQ0KICAgY29tcG9uZW50 IGxpbmsgYXMgYSBsaW5rIGZvciBsb2NhbCByZWNvdmVyeSBwdXJwb3NlLCBpbiB3aGljaCB0aGUN CiAgIGNvbXBvc2l0ZSBsaW5rIHNob3VsZCBub3QgY291bnQgdGhlIGNvbXBvbmVudCBsaW5rIFRF IHBhcmFtZXRlcnMNCiAgIGludG8gdGhlIGNvbXBvc2l0ZSBsaW5rIFRFIHBhcmFtZXRlcnMgZm9y IHRoZSBhZHZlcnRpc2VtZW50LiBIb3dldmVyLA0KICAgdGhlIGNvbXBvc2l0ZSBsaW5rIG1heSBz ZW5kIHRoZSB0cmFmZmljIG92ZXIgdGhlIGNvbXBvbmVudCBsaW5rIHdoZW4NCiAgIGEgY29tcG9u ZW50IGxpbmsgZmFpbHVyZSBvY2N1cnMuIg0KDQpJIGFtIHdvbmRlcmluZyBpZiBjb21wb3NpdGUg bGluayBkb24ndCBjb3VudCB0aGUgcmVjb3ZlcnkgY29tcG9uZW50IGxpbmsgDQphbmQgYWR2ZXJ0 aXNlIHN1bW1hcml6ZWQgQlcgYW5kIG1heGltdW0gQlcgb2YgdGhpcyBjb21wb25lbnQgbGluaywN CmhvdyBjYW4gTVAgb3IgQ1Aga25vdyB0aGVyZSBpcyBhIHJlY292ZXJ5IHJlc291cmNlIHdpdGhp biBjb21wb3NpdGUgbGluayANCmFuZCBob3cgbXVjaCBiYW5kd2lkdGg/DQpEb2VzIGl0IG1lYW4g eW91IGNvbmNlYWwgc29tZSBtb25leSBmcm9tIHlvdXIgd2lmZSBhbmQgdXNlIGl0IGZvciBmdXR1 cmUgDQplbWVyZ2VuY3k/ICA6LSkNCg0KMy5Zb3UgbWVudGlvbiBpbiAiQ29tcG9zaXRlIExpbmsg aW4gQ29udHJvbCBQbGFuZSIgYXMgZm9sbG93aW5nczoNCg0KobBUaGUgcm91dGUgY29tcHV0aW5n IGVuZ2luZSBtYXkgc2VsZWN0IG9uZSBncm91cCBvZiBjb21wb25lbnQgbGlua3MgZm9yIGENCiAg IExTUCwgaXQgaXMgbmVjZXNzYXJ5IGZvciBzaWduYWxpbmcgcHJvdG9jb2wgdG8gYmUgYWJsZSB0 byBpbmRpY2F0ZQ0KICAgd2hpY2ggZ3JvdXAgb2YgY29tcG9uZW50IGxpbmtzIGZvciBzaWduYWxl ZCBMU1AuIKGxDQoNCkkgc3VnZ2VzdCB5b3UgcmVmaW5lIGZvbGxvd2luZyBkZXNjcmlwdGlvbiBp biBzZWN0aW9uIDYgIkNvbXBvc2l0ZSBMaW5rIGluIA0KTWFuYWdlbWVudCBQbGFuZSIuDQogDQoi IE1hbmFnZW1lbnQgUGxhbmUgTVVTVCBiZSBhYmxlIHRvIGNvbmZpZ3VyZSBhIExTUCBvdmVyIGEg Y29tcG9zaXRlDQogICBsaW5rIGFuZCBiZSBhYmxlIHRvIHNlbGVjdCBvbmUgb3IgYSBncm91cCBj b21wb25lbnQgbGlua3MgZm9yIHRoZSBMU1AuDQogICBNYW5hZ2VtZW50IFBsYW5lIE1VU1QgYmUg YWJsZSB0byB0cmFjZSB3aGljaCBjb21wb25lbnQgbGluayBvciBhIGdyb3VwIA0KY29tcG9uZW50 IGxpbmtzICBhIExTUCBpcw0KICAgYXNzaWduZWQgdG8gYW5kIG1vbml0b3IgaW5kaXZpZHVhbCBj b21wb25lbnQgbGluayBhbmQgY29tcG9zaXRlIGxpbmsNCiAgIHBlcmZvcm1hbmNlLiINCg0KTXkg Y29uY2VybiBpcyB0aGUgYWN0aW9uIG9mIE1QIGFuZCBDUCBzaG91bGQgYmUgY29uc2lzdGVudC4N Cg0KQmVzdCBSZWdhcmRzLA0KDQpYaWh1YSBGdQ0KDQo= --=_alternative 002BFEF0482578CC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkhpIEF1dGhvcnMsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5GaXJzdGx5LCBJIHN1cHBvcnQgaXQg YmUgYSBXRyBkcmFmdC4gSQ0KcmVhZCB0aHJvdWdoIHRoZSBkcmFmdCBhbmQgaGF2ZSBhIGZldyBj b21tZW50cyBhcyBmb2xsb3dzOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+MS4gWW91IHdyb3RlIGluIHNlY3Rpb24gMzwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7JnF1b3Q7QWxsIGNvbXBvbmVudCBsaW5rcyBp biBhIGNvbXBvc2l0ZQ0KbGluayBoYXZlIHRoZSBzYW1lPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7Zm9yd2FyZGluZyBhZGphY2VuY3kuIFRoZQ0K Y29tcG9zaXRlIGxpbmsgZm9ybXMgb25lIHJvdXRpbmcgaW50ZXJmYWNlPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7YXQgdGhlIGNvbXBvc2l0ZSBs aW5rIGVuZA0KcG9pbnRzIGZvciBNUExTIGNvbnRyb2wgcGxhbmUuIEluIG90aGVyPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7d29yZHMsIHR3byBy b3V0ZXJzIGNvbm5lY3RlZA0KdmlhIGEgY29tcG9zaXRlIGxpbmsgaGF2ZSBmb3J3YXJkaW5nPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7YWRqYWNl bmN5IGFuZCByb3V0aW5nIGFkamFjZW5jeS4NCkVhY2ggY29tcG9uZW50IGxpbmsgb25seSBoYXM8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtzaWdu aWZpY2FuY2UgdG8gdGhlIGNvbXBvc2l0ZQ0KbGluaywgaS5lLiBpdCBkb2VzIG5vdCBhcHBlYXIg YXMgYTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNw O2xpbmsgaW4gdGhlIGNvbnRyb2wgcGxhbmUuJnF1b3Q7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5BIEZvcndhcmRpbmcgQWRqYWNlbmN5IChGQSkgaXMgZGVm aW5lZA0KaW4gW1JGQzQyMDZdIGFzIGEgZGF0YSBsaW5rIGNyZWF0ZWQgZnJvbSBhbiBMU1AgYW5k IGFkdmVydGlzZWQgaW4gdGhlIDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9IkNh bGlicmkiPnNhbWUNCmluc3RhbmNlPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4g b2YgdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5jb250cm9sIHBs YW5lIHRoYXQgYWR2ZXJ0aXNlcyB0aGUgVEUgbGlua3MNCmZyb20gd2hpY2ggdGhlIExTUCBpcyBj b25zdHJ1Y3RlZC4gSXQgY291bGQgbm90IGFwcGx5IHRvIG92ZXJsYXllciBtb2RlbC4NClBscyBy ZWZlciB0byByZmM2MTA3LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ SW4gdGhlIGNhc2Ugb2YgaGV0ZXJvZ2VuZW91cyBjb21wb25lbnQNCmxpbmtzLCBjb21wb3NpdGUg bGluayBjb3VsZCBiZSBvbmUgQ1AgaW5zdGFuY2UgZGlmZmVyZW50IGZyb20gY29tcG9uZW50DQps aW5rcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkkgc3VnZ2VzdCB5 b3UgY2xhcmlmeSB0aGUgQ1AgaW5zdGFuY2UgYmV0d2Vlbg0KY29tcG9zaXRlIGFuZCBjb21wb25l bnQgbGluayBpbiB0aGlzIHNlY3Rpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj4yLiBZb3Ugd3JvdGUgaW4gc2VjdGlvbiA0PC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mcXVvdDsgYSBjb21wb25lbnQgbGluayBpcyBj b25maWd1cmVkIHRvDQpjYXJyeSB0cmFmZmljIHVuZGVyIG5vcm1hbDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO29wZXJhdGlvbjsgdW5kZXIgc29t ZSBzaXR1YXRpb24sDQpvcGVyYXRvciBtYXkgd2FudCB0byBjb25maWd1cmUgYTwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO2NvbXBvbmVudCBsaW5r IGFzIGEgbGluayBmb3INCmxvY2FsIHJlY292ZXJ5IHB1cnBvc2UsIGluIHdoaWNoIHRoZTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO2NvbXBvc2l0 ZSBsaW5rIHNob3VsZCBub3QNCmNvdW50IHRoZSBjb21wb25lbnQgbGluayBURSBwYXJhbWV0ZXJz PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7aW50 byB0aGUgY29tcG9zaXRlIGxpbmsgVEUNCnBhcmFtZXRlcnMgZm9yIHRoZSBhZHZlcnRpc2VtZW50 LiBIb3dldmVyLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7 ICZuYnNwO3RoZSBjb21wb3NpdGUgbGluayBtYXkgc2VuZA0KdGhlIHRyYWZmaWMgb3ZlciB0aGUg Y29tcG9uZW50IGxpbmsgd2hlbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7ICZuYnNwO2EgY29tcG9uZW50IGxpbmsgZmFpbHVyZSBvY2N1cnMuJnF1b3Q7PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5JIGFtIHdvbmRlcmlu ZyBpZiBjb21wb3NpdGUgbGluayBkb24ndA0KY291bnQgdGhlIHJlY292ZXJ5IGNvbXBvbmVudCBs aW5rIGFuZCBhZHZlcnRpc2Ugc3VtbWFyaXplZCBCVyBhbmQgbWF4aW11bQ0KQlcgb2YgdGhpcyBj b21wb25lbnQgbGluayw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPmhv dyBjYW4gTVAgb3IgQ1Aga25vdyB0aGVyZSBpcyBhIHJlY292ZXJ5DQpyZXNvdXJjZSB3aXRoaW4g Y29tcG9zaXRlIGxpbmsgYW5kIGhvdyBtdWNoIGJhbmR3aWR0aD88L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPkRvZXMgaXQgbWVhbiB5b3UgY29uY2VhbCBzb21lIG1vbmV5 IGZyb20NCnlvdXIgd2lmZSBhbmQgdXNlIGl0IGZvciBmdXR1cmUgZW1lcmdlbmN5PyAmbmJzcDs6 LSk8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjMuWW91IG1l bnRpb24gaW4gJnF1b3Q7Q29tcG9zaXRlIExpbmsgaW4NCkNvbnRyb2wgUGxhbmUmcXVvdDsgYXMg Zm9sbG93aW5nczo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PqGwVGhlIHJvdXRlIGNvbXB1dGluZyBlbmdpbmUgbWF5IHNlbGVjdA0Kb25lIGdyb3VwIG9mIGNv bXBvbmVudCBsaW5rcyBmb3IgYTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+Jm5ic3A7ICZuYnNwO0xTUCwgaXQgaXMgbmVjZXNzYXJ5IGZvciBzaWduYWxpbmcNCnByb3Rv Y29sIHRvIGJlIGFibGUgdG8gaW5kaWNhdGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPiZuYnNwOyAmbmJzcDt3aGljaCBncm91cCBvZiBjb21wb25lbnQgbGlua3MNCmZv ciBzaWduYWxlZCBMU1AuIKGxPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5JIHN1Z2dlc3QgeW91IHJlZmluZSBmb2xsb3dpbmcgZGVzY3JpcHRpb24NCmluIHNl Y3Rpb24gNiAmcXVvdDtDb21wb3NpdGUgTGluayBpbiBNYW5hZ2VtZW50IFBsYW5lJnF1b3Q7Ljwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mcXVvdDsgTWFuYWdlbWVudCBQbGFuZSBNVVNU IGJlIGFibGUgdG8NCmNvbmZpZ3VyZSBhIExTUCBvdmVyIGEgY29tcG9zaXRlPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7bGluayBhbmQgYmUgYWJs ZSB0byBzZWxlY3QNCjwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9IkNhbGlicmki Pm9uZSBvciBhIGdyb3VwPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4NCmNvbXBv bmVudCBsaW5rcyBmb3IgdGhlIExTUC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNh bGlicmkiPiZuYnNwOyAmbmJzcDtNYW5hZ2VtZW50IFBsYW5lIE1VU1QgYmUgYWJsZQ0KdG8gdHJh Y2Ugd2hpY2ggY29tcG9uZW50IGxpbmsgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFj ZT0iQ2FsaWJyaSI+b3INCmEgZ3JvdXAgY29tcG9uZW50IGxpbmtzPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj4gJm5ic3A7YSBMU1ANCmlzPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7YXNzaWduZWQgdG8gYW5kIG1vbml0b3IgaW5k aXZpZHVhbA0KY29tcG9uZW50IGxpbmsgYW5kIGNvbXBvc2l0ZSBsaW5rPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7cGVyZm9ybWFuY2UuJnF1b3Q7 PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5NeSBjb25jZXJu IGlzIHRoZSBhY3Rpb24gb2YgTVAgYW5kIENQIHNob3VsZA0KYmUgY29uc2lzdGVudC48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkJlc3QgUmVnYXJkcyw8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlhpaHVhIEZ1PC9mb250 Pg0KPGJyPg0K --=_alternative 002BFEF0482578CC_=-- From curtis@occnc.com Wed Jul 13 06:16:41 2011 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 8D50011E80B8 for ; Wed, 13 Jul 2011 06:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.485, 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 lWYaJ4unLJcK for ; Wed, 13 Jul 2011 06:16:37 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5C11E807A for ; Wed, 13 Jul 2011 06:16:36 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6DDGZWD061332; Wed, 13 Jul 2011 09:16:35 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107131316.p6DDGZWD061332@harbor.orleans.occnc.com> To: rtgwg@ietf.org Subject: (resend) suggestion additions to cl-framework From: Curtis Villamizar Date: Wed, 13 Jul 2011 09:16:35 -0400 Sender: curtis@occnc.com X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 13:16:41 -0000 Due to the size limit of 40KB on WG email I had to resend a shorter version of this email. See http://www.faster-light.net/rtgwg-email.txt for the full text of the original email. ---------------------------------------- The CL-framework document is draft-so-yong-rtgwg-cl-framework-04 . The remainder of this email is suggested additions to the CL framework. It looks a lot like an internet-draft, but it isn't. It was easier to validate the xml2rfc by making this self contained. There has been a discussion of this among the co-author of draft-so-yong-rtgwg-cl-framework-04 with Ning and Lucy agreeing to merge this with the existing work (three if you count me) and the rest (three) not weighing in yet. Lucy has provided general comments and wants to read through the proposed additions again and provide further more detailed comments. The discussion at the upcoming IETF meeting should still focus on draft-so-yong-rtgwg-cl-framework-04 first and foremost. This email is just to let the WG to get a general idea of what we are planning to merge in. I'm entirely OK if the WG or WG chairs decides that it is premature to discuss these additions at all at the meeting. Any merge would have to occur after the IETF meeting, though a merged draft is likely to have been exchanged among the co-authors prior to the meeting. The screwup on this is entirely my fault for taking way too long to get around to writing this. Curtis ---------------------------------------- [ remainder deleted to fit email size limits ] From akatlas@gmail.com Wed Jul 13 08:03:40 2011 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 DF42E11E808E for ; Wed, 13 Jul 2011 08:03:40 -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=0.075, BAYES_00=-2.599, 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 iFgzv9sXBgib for ; Wed, 13 Jul 2011 08:03:37 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id F080C11E807E for ; Wed, 13 Jul 2011 08:03:36 -0700 (PDT) Received: by pvh18 with SMTP id 18so6800721pvh.31 for ; Wed, 13 Jul 2011 08:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JsZPSndq2eaRI46BTX3P4FV1CXLkAFi8p9I3iE+ZGgc=; b=EIcAz9afRic5eH3MeiBndZJKlRyHqEnhqEolej9Hx7ZSRJ3e6NpFzMC8vMx3ByPgKL SM5tvCCSltqbcJR+7s64ZzhoJxT+n+XqUGgsyuVLRMkEHNpTrIMIfI1lL2X9O6L2qu9u ttSyOULiLXr4xAE8kmbxwLnc7wGv0rnfreXbo= MIME-Version: 1.0 Received: by 10.68.0.39 with SMTP id 7mr1392625pbb.214.1310569416528; Wed, 13 Jul 2011 08:03:36 -0700 (PDT) Received: by 10.68.55.130 with HTTP; Wed, 13 Jul 2011 08:03:36 -0700 (PDT) In-Reply-To: <201107131316.p6DDGZWD061332@harbor.orleans.occnc.com> References: <201107131316.p6DDGZWD061332@harbor.orleans.occnc.com> Date: Wed, 13 Jul 2011 11:03:36 -0400 Message-ID: Subject: Re: (resend) suggestion additions to cl-framework From: Alia Atlas To: curtis@occnc.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 13 Jul 2011 15:03:41 -0000 Given that we are discussing whether to accept the draft, it is the only current draft with that focus, and you've posted the changes 2 weeks before our meeting, I am ok with discussing your additions at the meeting this time. Alia On Wed, Jul 13, 2011 at 9:16 AM, Curtis Villamizar wrote= : > > Due to the size limit of 40KB on WG email I had to resend a shorter > version of this email. > > See http://www.faster-light.net/rtgwg-email.txt > for the full text of the original email. > > ---------------------------------------- > > The CL-framework document is draft-so-yong-rtgwg-cl-framework-04 . > > The remainder of this email is suggested additions to the CL > framework. =A0It looks a lot like an internet-draft, but it isn't. =A0It > was easier to validate the xml2rfc by making this self contained. > > There has been a discussion of this among the co-author of > draft-so-yong-rtgwg-cl-framework-04 with Ning and Lucy agreeing to > merge this with the existing work (three if you count me) and the rest > (three) not weighing in yet. =A0Lucy has provided general comments and > wants to read through the proposed additions again and provide further > more detailed comments. > > The discussion at the upcoming IETF meeting should still focus on > draft-so-yong-rtgwg-cl-framework-04 first and foremost. =A0This email is > just to let the WG to get a general idea of what we are planning to > merge in. =A0I'm entirely OK if the WG or WG chairs decides that it is > premature to discuss these additions at all at the meeting. > > Any merge would have to occur after the IETF meeting, though a merged > draft is likely to have been exchanged among the co-authors prior to > the meeting. > > The screwup on this is entirely my fault for taking way too long to > get around to writing this. > > Curtis > > ---------------------------------------- > > [ remainder deleted to fit email size limits ] > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From curtis@occnc.com Wed Jul 13 08:12:31 2011 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 CAD1C21F8660 for ; Wed, 13 Jul 2011 08:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.453, 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 fkq1L1tJluQr for ; Wed, 13 Jul 2011 08:12:31 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE2C21F8695 for ; Wed, 13 Jul 2011 08:12:30 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6DFCOft091090; Wed, 13 Jul 2011 11:12:24 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107131512.p6DFCOft091090@harbor.orleans.occnc.com> To: fu.xihua@zte.com.cn From: Curtis Villamizar Subject: Re: Comment on draft-so-yong-rtgwg-cl-framework-04 In-reply-to: Your message of "Wed, 13 Jul 2011 16:00:31 +0800." Date: Wed, 13 Jul 2011 11:12:24 -0400 Sender: curtis@occnc.com Cc: cvillamizar@infinera.com, andrew.g.malis@verizon.com, "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 15:12:31 -0000 In message fu.xihua@zte.com.cn writes: > > > Hi Authors, One author here. This is my personal opinion, not necessarily representing concensus of the set of authors. > Firstly, I support it be a WG draft. I read through the draft and have > a few comments as follows: > > 1. You wrote in section 3 > > "All component links in a composite link have the same forwarding > adjacency. The composite link forms one routing interface at the > composite link end points for MPLS control plane. In other words, > two routers connected via a composite link have forwarding > adjacency and routing adjacency. Each component link only has > significance to the composite link, i.e. it does not appear as a > link in the control plane." > > A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link > created from an LSP and advertised in thesame instanceof the control > plane that advertises the TE links from which the LSP is > constructed. It could not apply to overlayer model. Pls refer to > rfc6107. A link bundle as defined in RFC 4201 is a single FA. CL is expected to be link link bundle with some information about groups of components within the bundle. If we add TLVs to RFC 4201 then we retain backwards compatibility, just without the new features in older equipment. There is no implication of an overlay model. Also, the word "overlay" does not appear in rfc6107, so I am not sure why you referenced this RFC unless just for further general information about FA. > In the case of heterogeneous component links, composite link could be > one CP instance different from component links. I suggest you clarify > the CP instance between composite and component link in this section. The paragraph in the draft that you quoted could be better worded. We can take that as an action item. > 2. You wrote in section 4 > > " a component link is configured to carry traffic under normal > operation; under some situation, operator may want to configure a > component link as a link for local recovery purpose, in which the > composite link should not count the component link TE parameters > into the composite link TE parameters for the > advertisement. However, the composite link may send the traffic > over the component link when a component link failure occurs." > > I am wondering if composite link don't count the recovery component > link and advertise summarized BW and maximum BW of this component > link, how can MP or CP know there is a recovery resource within > composite link and how much bandwidth? Does it mean you conceal some > money from your wife and use it for future emergency? :-) That is a good analogy. This is a tactic of very questionable value that is used in Ethernet Link Aggregation. More often, all the component links are used for working traffic, with the amount of high priority traffic limited so that the loss of a component is always immediately recoverable for the high priority traffic. It is also possible to limit BE traffic to always have an effective spare for all traffic. My experience working in the core equipment vendor role is this capability gets requested by never used in the core. It does get used in the edge as a 1:1 protection or even 1+1 where COE is used. > 3.You mention in "Composite Link in Control Plane" as followings: > > The route computing engine may select one group of component links > for a LSP, it is necessary for signaling protocol to be able to > indicate which group of component links for signaled LSP. The above is fine as is. Maybe we can add to it to address your concern but I don't think it is needed. See below. > I suggest you refine following description in section 6 "Composite > Link in Management Plane". > > " Management Plane MUST be able to configure a LSP over a composite > link and be able to selectone or a groupcomponent links for the > LSP. Management Plane MUST be able to trace which component linkor > a group component links a LSP is assigned to and monitor individual > component link and composite link performance." > > My concern is the action of MP and CP should be consistent. New requirements would have to be added to the requirements document. At one point it was suggested that missed management requirements could go into a separate CL management requirements document. In all IETF work it is assumed that anything that can be done by the control plane can also, at least in theory, be done in the management plane. In practice, a lot of MIB implemeentations are read-only in major implementations, even in violation of MIBs that are defined as writable. Since this is a general requirement (all protocols must have MIBs), it should be OK to not state it. IMHO, doing things in the management plane is a bad idea due to much slower response when multiple faults occur. For those that want to duplicate the characteristics of transport networks, including the minutes (to hours) of restoration time when multiple faults occur, this can be supported. The only providers that I know of that have used the management plane for an IP/MPLS network have had a lot of trouble with it since they forego the mature LSR control plane software and provide functionality in a management system that may be home grown or commercial and not as mature or customized. > Best Regards, > > Xihua Fu Thank you for the comments. Best regards, Curtis From akatlas@gmail.com Wed Jul 13 08:34:51 2011 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 E118E11E8113 for ; Wed, 13 Jul 2011 08:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 p6y+uTRYlgen for ; Wed, 13 Jul 2011 08:34:51 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7350011E80F8 for ; Wed, 13 Jul 2011 08:34:51 -0700 (PDT) Received: by pvh18 with SMTP id 18so6834300pvh.31 for ; Wed, 13 Jul 2011 08:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=BLpvvLm41JZrSxlU1EByA85/RgpRiEr8e+RbvqbTj8M=; b=GKH04ONR9N+veV+exqvgReMqqCetninpR+vcrONm+6fgtNq29N73C79vSLmxsnJKYW aS9FBe266QddyKi342ZRgQ8bopRVcyw/vLisyLRgjQnmLowItXWgVfsHw6hS1YQj/hYN +DwJDX2j+hJE+i97NnFSZKKvobl6Bws+wqexs= MIME-Version: 1.0 Received: by 10.68.0.131 with SMTP id 3mr1598193pbe.147.1310571290883; Wed, 13 Jul 2011 08:34:50 -0700 (PDT) Received: by 10.68.55.130 with HTTP; Wed, 13 Jul 2011 08:34:50 -0700 (PDT) Date: Wed, 13 Jul 2011 11:34:50 -0400 Message-ID: Subject: WGLC on draft-ietf-rtgwg-cl-requirement-04 (ending Aug 3) From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 13 Jul 2011 15:34:52 -0000 This is to start a Working Group Last Call on draft-ietf-rtgwg-cl-requirement-04. To allow sufficient time for discussion, given the overlap with IETF, it will conclude on August 3. Please send your detailed comments, any issues, and whether or not you think the draft should proceed. Thanks, Alia From lucy.yong@huawei.com Wed Jul 13 09:18:47 2011 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 B5A5C21F8793 for ; Wed, 13 Jul 2011 09:18:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXndclLLIk2A for ; Wed, 13 Jul 2011 09:18:47 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 358DA21F86DE for ; Wed, 13 Jul 2011 09:18:47 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOA006P65BAUK@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 13 Jul 2011 11:18:46 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOA00LJT5B9YB@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 13 Jul 2011 11:18:46 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 13 Jul 2011 09:18:40 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.159]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 13 Jul 2011 09:18:45 -0700 Date: Wed, 13 Jul 2011 16:18:19 +0000 From: Lucy yong Subject: RE: WGLC on draft-ietf-rtgwg-cl-requirement-04 (ending Aug 3) In-reply-to: X-Originating-IP: [10.47.129.184] To: Alia Atlas Message-id: <2691CE0099834E4A9C5044EEC662BB9D0498D09A@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: WGLC on draft-ietf-rtgwg-cl-requirement-04 (ending Aug 3) Thread-index: AQHMQXJxglN+atDulEWBq363eGGfFpTqbOlg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: 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, 13 Jul 2011 16:18:47 -0000 Alia, I am confused on this action. I thought that WG already did WGLC early this year, didn't it? Lucy > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Alia Atlas > Sent: Wednesday, July 13, 2011 10:35 AM > To: rtgwg@ietf.org > Subject: WGLC on draft-ietf-rtgwg-cl-requirement-04 (ending Aug 3) > > This is to start a Working Group Last Call on > draft-ietf-rtgwg-cl-requirement-04. > To allow sufficient time for discussion, given the overlap with IETF, > it will conclude on August 3. > > Please send your detailed comments, any issues, and whether or not you > think the draft should proceed. > > Thanks, > Alia > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From akatlas@gmail.com Wed Jul 13 09:21:07 2011 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 9B33E11E8126 for ; Wed, 13 Jul 2011 09:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 i0oS1TVbplfK for ; Wed, 13 Jul 2011 09:21:07 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 240EC11E8079 for ; Wed, 13 Jul 2011 09:21:07 -0700 (PDT) Received: by pvh18 with SMTP id 18so6903113pvh.31 for ; Wed, 13 Jul 2011 09:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=7jrl7VJn3kBl4VUrSfgOvXolhhoAu6VTIx89UqYOLJs=; b=WCapZMQLi7KFIjTmPsiRNcNnW/gBZrl4TzJvX9nRb9HrDGzIhpWR8aLGqBqPm+mWWu l3SEo7suifUujNHK57XqJ9h9HPASiY8XxdmijT//YWHxHkq/sFVqBQ+2oHgLu2KYtJ+3 1hl7t6GZ4Lt+yahhuWIdSuoXlxPaqgQk+r3qo= MIME-Version: 1.0 Received: by 10.68.0.131 with SMTP id 3mr1657211pbe.147.1310574066740; Wed, 13 Jul 2011 09:21:06 -0700 (PDT) Received: by 10.68.55.130 with HTTP; Wed, 13 Jul 2011 09:21:06 -0700 (PDT) Date: Wed, 13 Jul 2011 12:21:06 -0400 Message-ID: Subject: Completed in March Re: WGLC on draft-ietf-rtgwg-cl-requirement-04 (ending Aug 3) From: Alia Atlas To: Lucy yong Content-Type: text/plain; charset=ISO-8859-1 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, 13 Jul 2011 16:21:07 -0000 My apologies, yes, we did on version 03 and version 04 has the changes. I will get it written up and forwarded along. Alia On Wed, Jul 13, 2011 at 12:18 PM, Lucy yong wrote: > Alia, > > I am confused on this action. I thought that WG already did WGLC early this year, didn't it? > > Lucy > >> -----Original Message----- >> From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of >> Alia Atlas >> Sent: Wednesday, July 13, 2011 10:35 AM >> To: rtgwg@ietf.org >> Subject: WGLC on draft-ietf-rtgwg-cl-requirement-04 (ending Aug 3) >> >> This is to start a Working Group Last Call on >> draft-ietf-rtgwg-cl-requirement-04. >> To allow sufficient time for discussion, given the overlap with IETF, >> it will conclude on August 3. >> >> Please send your detailed comments, any issues, and whether or not you >> think the draft should proceed. >> >> Thanks, >> Alia >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg > From lucy.yong@huawei.com Wed Jul 13 11:23:07 2011 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 A1D5F21F8C25 for ; Wed, 13 Jul 2011 11:23:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPMdEydcbPlb for ; Wed, 13 Jul 2011 11:23:06 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id C5FF121F8C23 for ; Wed, 13 Jul 2011 11:23:06 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOA00CA6B2HAD@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 13 Jul 2011 13:23:06 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOA00NL6B2G0A@usaga04-in.huawei.com> for rtgwg@ietf.org; Wed, 13 Jul 2011 13:23:05 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 13 Jul 2011 11:23:05 -0700 Received: from DFWEML503-MBX.china.huawei.com ([169.254.3.159]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 13 Jul 2011 11:23:04 -0700 Date: Wed, 13 Jul 2011 18:22:39 +0000 From: Lucy yong Subject: RE: Comment on draft-so-yong-rtgwg-cl-framework-04 In-reply-to: <201107131512.p6DFCOft091090@harbor.orleans.occnc.com> X-Originating-IP: [10.47.129.184] To: "curtis@occnc.com" , "fu.xihua@zte.com.cn" Message-id: <2691CE0099834E4A9C5044EEC662BB9D0498D1EE@dfweml503-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: Comment on draft-so-yong-rtgwg-cl-framework-04 Thread-index: AQHMQW9aflGZRiUxd0mkQCo/O5zXuZTqjQJQ X-MS-Has-Attach: X-MS-TNEF-Correlator: References: "Your message of Wed, 13 Jul 2011 16:00:31 +0800." <201107131512.p6DFCOft091090@harbor.orleans.occnc.com> Cc: "cvillamizar@infinera.com" , "andrew.g.malis@verizon.com" , "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2011 18:23:07 -0000 Xihua, I am fine with Curtis's reply. Regarding the composite link in management plane, it is necessary to allow operator to configure a LSP over a composite link and select a component link that the LSP is over. I agree that, in general, the control plane is responsible to select a component link for a LSP. Lucy > -----Original Message----- > From: rtgwg-bounces@ietf.org [mailto:rtgwg-bounces@ietf.org] On Behalf Of > Curtis Villamizar > Sent: Wednesday, July 13, 2011 10:12 AM > To: fu.xihua@zte.com.cn > Cc: cvillamizar@infinera.com; andrew.g.malis@verizon.com; rtgwg@ietf.org > Subject: Re: Comment on draft-so-yong-rtgwg-cl-framework-04 > > > In message 482578CC.002BFEF3@zte.com.cn> > fu.xihua@zte.com.cn writes: > > > > > > Hi Authors, > > One author here. This is my personal opinion, not necessarily > representing concensus of the set of authors. > > > Firstly, I support it be a WG draft. I read through the draft and have > > a few comments as follows: > > > > 1. You wrote in section 3 > > > > "All component links in a composite link have the same forwarding > > adjacency. The composite link forms one routing interface at the > > composite link end points for MPLS control plane. In other words, > > two routers connected via a composite link have forwarding > > adjacency and routing adjacency. Each component link only has > > significance to the composite link, i.e. it does not appear as a > > link in the control plane." > > > > A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link > > created from an LSP and advertised in thesame instanceof the control > > plane that advertises the TE links from which the LSP is > > constructed. It could not apply to overlayer model. Pls refer to > > rfc6107. > > A link bundle as defined in RFC 4201 is a single FA. CL is expected > to be link link bundle with some information about groups of > components within the bundle. > > If we add TLVs to RFC 4201 then we retain backwards compatibility, > just without the new features in older equipment. > > There is no implication of an overlay model. Also, the word "overlay" > does not appear in rfc6107, so I am not sure why you referenced this > RFC unless just for further general information about FA. > > > In the case of heterogeneous component links, composite link could be > > one CP instance different from component links. I suggest you clarify > > the CP instance between composite and component link in this section. > > The paragraph in the draft that you quoted could be better worded. We > can take that as an action item. > > > 2. You wrote in section 4 > > > > " a component link is configured to carry traffic under normal > > operation; under some situation, operator may want to configure a > > component link as a link for local recovery purpose, in which the > > composite link should not count the component link TE parameters > > into the composite link TE parameters for the > > advertisement. However, the composite link may send the traffic > > over the component link when a component link failure occurs." > > > > I am wondering if composite link don't count the recovery component > > link and advertise summarized BW and maximum BW of this component > > link, how can MP or CP know there is a recovery resource within > > composite link and how much bandwidth? Does it mean you conceal some > > money from your wife and use it for future emergency? :-) > > That is a good analogy. This is a tactic of very questionable value > that is used in Ethernet Link Aggregation. More often, all the > component links are used for working traffic, with the amount of high > priority traffic limited so that the loss of a component is always > immediately recoverable for the high priority traffic. It is also > possible to limit BE traffic to always have an effective spare for all > traffic. My experience working in the core equipment vendor role is > this capability gets requested by never used in the core. It does get > used in the edge as a 1:1 protection or even 1+1 where COE is used. > > > 3.You mention in "Composite Link in Control Plane" as followings: > > > > The route computing engine may select one group of component links > > for a LSP, it is necessary for signaling protocol to be able to > > indicate which group of component links for signaled LSP. > > The above is fine as is. Maybe we can add to it to address your > concern but I don't think it is needed. See below. > > > I suggest you refine following description in section 6 "Composite > > Link in Management Plane". > > > > " Management Plane MUST be able to configure a LSP over a composite > > link and be able to selectone or a groupcomponent links for the > > LSP. Management Plane MUST be able to trace which component linkor > > a group component links a LSP is assigned to and monitor individual > > component link and composite link performance." > > > > My concern is the action of MP and CP should be consistent. > > New requirements would have to be added to the requirements document. > At one point it was suggested that missed management requirements > could go into a separate CL management requirements document. > > In all IETF work it is assumed that anything that can be done by the > control plane can also, at least in theory, be done in the management > plane. In practice, a lot of MIB implemeentations are read-only in > major implementations, even in violation of MIBs that are defined as > writable. Since this is a general requirement (all protocols must > have MIBs), it should be OK to not state it. > > IMHO, doing things in the management plane is a bad idea due to much > slower response when multiple faults occur. For those that want to > duplicate the characteristics of transport networks, including the > minutes (to hours) of restoration time when multiple faults occur, > this can be supported. The only providers that I know of that have > used the management plane for an IP/MPLS network have had a lot of > trouble with it since they forego the mature LSR control plane > software and provide functionality in a management system that may be > home grown or commercial and not as mature or customized. > > > Best Regards, > > > > Xihua Fu > > Thank you for the comments. > > Best regards, > > Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg From fu.xihua@zte.com.cn Thu Jul 14 00:20:53 2011 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 BAEEE21F8AE9 for ; Thu, 14 Jul 2011 00:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.418 X-Spam-Level: X-Spam-Status: No, score=-99.418 tagged_above=-999 required=5 tests=[AWL=2.420, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 NW68d8sN1MT2 for ; Thu, 14 Jul 2011 00:20:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6E121F89FF for ; Thu, 14 Jul 2011 00:20:42 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131321754626705; Thu, 14 Jul 2011 15:14:28 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 70257.8952640608; Thu, 14 Jul 2011 15:20:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p6E7KDAI001298; Thu, 14 Jul 2011 15:20:13 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) In-Reply-To: <201107131512.p6DFCOft091090@harbor.orleans.occnc.com> To: curtis@occnc.com Subject: Re: Comment on draft-so-yong-rtgwg-cl-framework-04 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Thu, 14 Jul 2011 15:20:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-14 15:20:14, Serialize complete at 2011-07-14 15:20:14 Content-Type: multipart/alternative; boundary="=_alternative 00284D93482578CD_=" X-MAIL: mse01.zte.com.cn p6E7KDAI001298 Cc: cvillamizar@infinera.com, andrew.g.malis@verizon.com, "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 07:20:53 -0000 This is a multipart message in MIME format. --=_alternative 00284D93482578CD_= Content-Type: text/plain; charset="US-ASCII" Hi Curtis, Thank you for your clarification. One further comment. > There is no implication of an overlay model. Also, the word "overlay" > does not appear in rfc6107, so I am not sure why you referenced this > RFC unless just for further general information about FA. I am sorry make you confuse. Based on [RFC4206], the LSP is advertised as an FA into the same instance of the IGP as was used to advertise the TE links that the LSP traverses. This is well applied to CP peer model. RFC6107 extends LSP_TUNNEL_INTERFACE_ID to carry the IGP instance where the link formed by the LSP is to be advertised. IMO, this could be used to overlayer model. If one component is from OTN network and CL is in MPLS network, they should be in different CP instance. This is reasonable. Current protocol (e.g., rfc6107) can provide this function. My concern is a framrwork document should allow this happen. Xihua > > In message 002BFEF3@zte.com.cn> > fu.xihua@zte.com.cn writes: > > > > > > Hi Authors, > > One author here. This is my personal opinion, not necessarily > representing concensus of the set of authors. > > > Firstly, I support it be a WG draft. I read through the draft and have > > a few comments as follows: > > > > 1. You wrote in section 3 > > > > "All component links in a composite link have the same forwarding > > adjacency. The composite link forms one routing interface at the > > composite link end points for MPLS control plane. In other words, > > two routers connected via a composite link have forwarding > > adjacency and routing adjacency. Each component link only has > > significance to the composite link, i.e. it does not appear as a > > link in the control plane." > > > > A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link > > created from an LSP and advertised in thesame instanceof the control > > plane that advertises the TE links from which the LSP is > > constructed. It could not apply to overlayer model. Pls refer to > > rfc6107. > > A link bundle as defined in RFC 4201 is a single FA. CL is expected > to be link link bundle with some information about groups of > components within the bundle. > > If we add TLVs to RFC 4201 then we retain backwards compatibility, > just without the new features in older equipment. > > There is no implication of an overlay model. Also, the word "overlay" > does not appear in rfc6107, so I am not sure why you referenced this > RFC unless just for further general information about FA. > > > In the case of heterogeneous component links, composite link could be > > one CP instance different from component links. I suggest you clarify > > the CP instance between composite and component link in this section. > > The paragraph in the draft that you quoted could be better worded. We > can take that as an action item. > > > 2. You wrote in section 4 > > > > " a component link is configured to carry traffic under normal > > operation; under some situation, operator may want to configure a > > component link as a link for local recovery purpose, in which the > > composite link should not count the component link TE parameters > > into the composite link TE parameters for the > > advertisement. However, the composite link may send the traffic > > over the component link when a component link failure occurs." > > > > I am wondering if composite link don't count the recovery component > > link and advertise summarized BW and maximum BW of this component > > link, how can MP or CP know there is a recovery resource within > > composite link and how much bandwidth? Does it mean you conceal some > > money from your wife and use it for future emergency? :-) > > That is a good analogy. This is a tactic of very questionable value > that is used in Ethernet Link Aggregation. More often, all the > component links are used for working traffic, with the amount of high > priority traffic limited so that the loss of a component is always > immediately recoverable for the high priority traffic. It is also > possible to limit BE traffic to always have an effective spare for all > traffic. My experience working in the core equipment vendor role is > this capability gets requested by never used in the core. It does get > used in the edge as a 1:1 protection or even 1+1 where COE is used. > > > 3.You mention in "Composite Link in Control Plane" as followings: > > > > The route computing engine may select one group of component links > > for a LSP, it is necessary for signaling protocol to be able to > > indicate which group of component links for signaled LSP. > > The above is fine as is. Maybe we can add to it to address your > concern but I don't think it is needed. See below. > > > I suggest you refine following description in section 6 "Composite > > Link in Management Plane". > > > > " Management Plane MUST be able to configure a LSP over a composite > > link and be able to selectone or a groupcomponent links for the > > LSP. Management Plane MUST be able to trace which component linkor > > a group component links a LSP is assigned to and monitor individual > > component link and composite link performance." > > > > My concern is the action of MP and CP should be consistent. > > New requirements would have to be added to the requirements document. > At one point it was suggested that missed management requirements > could go into a separate CL management requirements document. > > In all IETF work it is assumed that anything that can be done by the > control plane can also, at least in theory, be done in the management > plane. In practice, a lot of MIB implemeentations are read-only in > major implementations, even in violation of MIBs that are defined as > writable. Since this is a general requirement (all protocols must > have MIBs), it should be OK to not state it. > > IMHO, doing things in the management plane is a bad idea due to much > slower response when multiple faults occur. For those that want to > duplicate the characteristics of transport networks, including the > minutes (to hours) of restoration time when multiple faults occur, > this can be supported. The only providers that I know of that have > used the management plane for an IP/MPLS network have had a lot of > trouble with it since they forego the mature LSR control plane > software and provide functionality in a management system that may be > home grown or commercial and not as mature or customized. > > > Best Regards, > > > > Xihua Fu > > Thank you for the comments. > > Best regards, > > Curtis > --=_alternative 00284D93482578CD_= Content-Type: text/html; charset="US-ASCII"
Hi Curtis,

Thank you for your clarification.

One further comment.

> There is no implication of an overlay model.  Also, the word "overlay"
> does not appear in rfc6107, so I am not sure why you referenced this
> RFC unless just for further general information about FA.

I am sorry make you confuse. Based on [RFC4206], the LSP is advertised as an FA into the same instance of the IGP
as was used to advertise the TE links that the LSP traverses. This is well applied to CP peer model.
RFC6107 extends LSP_TUNNEL_INTERFACE_ID to carry the IGP instance
where  the link formed by the LSP is to be advertised. IMO, this could be used to overlayer model.
If one component is from OTN network and CL is in MPLS network, they should be in different CP instance. This is reasonable.
Current protocol (e.g., rfc6107) can provide this function.
My concern is a framrwork document should allow this happen.

Xihua

>
> In message <OF1C7973FE.0C3291A8-ON482578CC.0027EB2E-482578CC.
> 002BFEF3@zte.com.cn>
> fu.xihua@zte.com.cn writes:
> >  
> >  
> > Hi Authors,
>
> One author here.  This is my personal opinion, not necessarily
> representing concensus of the set of authors.
>
> > Firstly, I support it be a WG draft. I read through the draft and have
> > a few comments as follows:
> >  
> > 1. You wrote in section 3
> >  
> >    "All component links in a composite link have the same forwarding
> >    adjacency. The composite link forms one routing interface at the
> >    composite link end points for MPLS control plane. In other words,
> >    two routers connected via a composite link have forwarding
> >    adjacency and routing adjacency. Each component link only has
> >    significance to the composite link, i.e. it does not appear as a
> >    link in the control plane."
> >  
> > A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link
> > created from an LSP and advertised in thesame instanceof the control
> > plane that advertises the TE links from which the LSP is
> > constructed. It could not apply to overlayer model. Pls refer to
> > rfc6107.
>
> A link bundle as defined in RFC 4201 is a single FA.  CL is expected
> to be link link bundle with some information about groups of
> components within the bundle.
>
> If we add TLVs to RFC 4201 then we retain backwards compatibility,
> just without the new features in older equipment.
>
> There is no implication of an overlay model.  Also, the word "overlay"
> does not appear in rfc6107, so I am not sure why you referenced this
> RFC unless just for further general information about FA.
>
> > In the case of heterogeneous component links, composite link could be
> > one CP instance different from component links.  I suggest you clarify
> > the CP instance between composite and component link in this section.
>
> The paragraph in the draft that you quoted could be better worded.  We
> can take that as an action item.
>
> > 2. You wrote in section 4
> >  
> >    " a component link is configured to carry traffic under normal
> >    operation; under some situation, operator may want to configure a
> >    component link as a link for local recovery purpose, in which the
> >    composite link should not count the component link TE parameters
> >    into the composite link TE parameters for the
> >    advertisement. However, the composite link may send the traffic
> >    over the component link when a component link failure occurs."
> >  
> > I am wondering if composite link don't count the recovery component
> > link and advertise summarized BW and maximum BW of this component
> > link, how can MP or CP know there is a recovery resource within
> > composite link and how much bandwidth?  Does it mean you conceal some
> > money from your wife and use it for future emergency?  :-)
>
> That is a good analogy.  This is a tactic of very questionable value
> that is used in Ethernet Link Aggregation.  More often, all the
> component links are used for working traffic, with the amount of high
> priority traffic limited so that the loss of a component is always
> immediately recoverable for the high priority traffic.  It is also
> possible to limit BE traffic to always have an effective spare for all
> traffic.  My experience working in the core equipment vendor role is
> this capability gets requested by never used in the core.  It does get
> used in the edge as a 1:1 protection or even 1+1 where COE is used.
>
> > 3.You mention in "Composite Link in Control Plane" as followings:
> >  
> >    The route computing engine may select one group of component links
> >    for a LSP, it is necessary for signaling protocol to be able to
> >    indicate which group of component links for signaled LSP.
>
> The above is fine as is.  Maybe we can add to it to address your
> concern but I don't think it is needed.  See below.
>
> > I suggest you refine following description in section 6 "Composite
> > Link in Management Plane".
> >
> >    " Management Plane MUST be able to configure a LSP over a composite
> >    link and be able to selectone or a groupcomponent links for the
> >    LSP.  Management Plane MUST be able to trace which component linkor
> >    a group component links a LSP is assigned to and monitor individual
> >    component link and composite link performance."
> >  
> > My concern is the action of MP and CP should be consistent.
>
> New requirements would have to be added to the requirements document.
> At one point it was suggested that missed management requirements
> could go into a separate CL management requirements document.
>
> In all IETF work it is assumed that anything that can be done by the
> control plane can also, at least in theory, be done in the management
> plane.  In practice, a lot of MIB implemeentations are read-only in
> major implementations, even in violation of MIBs that are defined as
> writable.  Since this is a general requirement (all protocols must
> have MIBs), it should be OK to not state it.
>
> IMHO, doing things in the management plane is a bad idea due to much
> slower response when multiple faults occur.  For those that want to
> duplicate the characteristics of transport networks, including the
> minutes (to hours) of restoration time when multiple faults occur,
> this can be supported.  The only providers that I know of that have
> used the management plane for an IP/MPLS network have had a lot of
> trouble with it since they forego the mature LSR control plane
> software and provide functionality in a management system that may be
> home grown or commercial and not as mature or customized.
>
> > Best Regards,
> >  
> > Xihua Fu
>
> Thank you for the comments.
>
> Best regards,
>
> Curtis
>
--=_alternative 00284D93482578CD_=-- From curtis@occnc.com Thu Jul 14 07:01:25 2011 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 3DD2821F8891 for ; Thu, 14 Jul 2011 07:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, 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 dUcOXetle1o8 for ; Thu, 14 Jul 2011 07:01:24 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by ietfa.amsl.com (Postfix) with ESMTP id A763521F8698 for ; Thu, 14 Jul 2011 07:01:17 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id p6EE19ov057865; Thu, 14 Jul 2011 10:01:09 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201107141401.p6EE19ov057865@harbor.orleans.occnc.com> To: fu.xihua@zte.com.cn From: Curtis Villamizar Subject: Re: Comment on draft-so-yong-rtgwg-cl-framework-04 In-reply-to: Your message of "Thu, 14 Jul 2011 15:20:12 +0800." Date: Thu, 14 Jul 2011 10:01:09 -0400 Sender: curtis@occnc.com Cc: cvillamizar@infinera.com, andrew.g.malis@verizon.com, "rtgwg@ietf.org" X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2011 14:01:25 -0000 In message fu.xihua@zte.com.cn writes: This is a multipart message in MIME format. --=_alternative 00284D93482578CD_= Content-Type: text/plain; charset="US-ASCII" > > Hi Curtis, > > Thank you for your clarification. > > One further comment. > > > There is no implication of an overlay model. Also, the word "overlay" > > does not appear in rfc6107, so I am not sure why you referenced this > > RFC unless just for further general information about FA. > > I am sorry make you confuse. Based on [RFC4206], the LSP is advertised > as an FA into the same instance of the IGP as was used to advertise > the TE links that the LSP traverses. This is well applied to CP peer > model. RFC6107 extends LSP_TUNNEL_INTERFACE_ID to carry the IGP > instance where the link formed by the LSP is to be advertised. IMO, > this could be used to overlayer model. If one component is from OTN > network and CL is in MPLS network, they should be in different CP > instance. This is reasonable. Current protocol (e.g., rfc6107) can > provide this function. My concern is a framrwork document should > allow this happen. > > Xihua Xihua, A multi-layer multi-topology (ML/MT) deployment is not an overlay. In an overlay the underlying layer does not participate in the client layer routing. In ML/MT (or MLN/MLR), the underlying layer acts as a peer in the client routing and signaling but partitions each client into a separate logical topology and keeps a separate topology for the server layer. This is very different from an overlay. A FA advertisement exists within an IGP instance. There may be more than one IGP instance as per OSPF ML/MT extensions [RFC4915] or ISIS ML/MT extensions [RFC5120]. This is extended to GMPLS with RFC5212, RFC5339 and RFC6001 (where it is called MLN/MRN). RFC6107 continues to support the notion of an IGP instance. The purpose of all of this work is to avoid the lack of sufficient functionality that results from building an overlay but also avoid the mixing of multiple client topologies and a server topology that would occur in a pure peer network. As I said earlier, the paragraph that you quoted could stand to be more clear and we will take rewording as an action item. This document needs a bit of general rewording for clarity, and we'll make a point of rewording this paragraph since you have pointed out a lack of clarity. This text was written by Ning or Lucy, but I also have a habit of referring to the FA advertisement and just writing "the FA" when writing about the IGP. It is too easy for a reader to lose context (discussion of the IGP) and read "the FA" to mean the LSP and not the advertisement of the LSP in the IGP. Going through the text and finding references to "FA" that don't specify the LSP or the IGP advertisement is simple enough and might improve clarity. Thank you for the comments. Curtis > > In message > 002BFEF3@zte.com.cn> > > fu.xihua@zte.com.cn writes: > > > > > > > > > Hi Authors, > > > > One author here. This is my personal opinion, not necessarily > > representing concensus of the set of authors. > > > > > Firstly, I support it be a WG draft. I read through the draft and have > > > a few comments as follows: > > > > > > 1. You wrote in section 3 > > > > > > "All component links in a composite link have the same forwarding > > > adjacency. The composite link forms one routing interface at the > > > composite link end points for MPLS control plane. In other words, > > > two routers connected via a composite link have forwarding > > > adjacency and routing adjacency. Each component link only has > > > significance to the composite link, i.e. it does not appear as a > > > link in the control plane." > > > > > > A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link > > > created from an LSP and advertised in thesame instanceof the control > > > plane that advertises the TE links from which the LSP is > > > constructed. It could not apply to overlayer model. Pls refer to > > > rfc6107. > > > > A link bundle as defined in RFC 4201 is a single FA. CL is expected > > to be link link bundle with some information about groups of > > components within the bundle. > > > > If we add TLVs to RFC 4201 then we retain backwards compatibility, > > just without the new features in older equipment. > > > > There is no implication of an overlay model. Also, the word "overlay" > > does not appear in rfc6107, so I am not sure why you referenced this > > RFC unless just for further general information about FA. > > > > > In the case of heterogeneous component links, composite link could be > > > one CP instance different from component links. I suggest you clarify > > > the CP instance between composite and component link in this section. > > > > The paragraph in the draft that you quoted could be better worded. We > > can take that as an action item. > > > > > 2. You wrote in section 4 > > > > > > " a component link is configured to carry traffic under normal > > > operation; under some situation, operator may want to configure a > > > component link as a link for local recovery purpose, in which the > > > composite link should not count the component link TE parameters > > > into the composite link TE parameters for the > > > advertisement. However, the composite link may send the traffic > > > over the component link when a component link failure occurs." > > > > > > I am wondering if composite link don't count the recovery component > > > link and advertise summarized BW and maximum BW of this component > > > link, how can MP or CP know there is a recovery resource within > > > composite link and how much bandwidth? Does it mean you conceal some > > > money from your wife and use it for future emergency? :-) > > > > That is a good analogy. This is a tactic of very questionable value > > that is used in Ethernet Link Aggregation. More often, all the > > component links are used for working traffic, with the amount of high > > priority traffic limited so that the loss of a component is always > > immediately recoverable for the high priority traffic. It is also > > possible to limit BE traffic to always have an effective spare for all > > traffic. My experience working in the core equipment vendor role is > > this capability gets requested by never used in the core. It does get > > used in the edge as a 1:1 protection or even 1+1 where COE is used. > > > > > 3.You mention in "Composite Link in Control Plane" as followings: > > > > > > The route computing engine may select one group of component links > > > for a LSP, it is necessary for signaling protocol to be able to > > > indicate which group of component links for signaled LSP. > > > > The above is fine as is. Maybe we can add to it to address your > > concern but I don't think it is needed. See below. > > > > > I suggest you refine following description in section 6 "Composite > > > Link in Management Plane". > > > > > > " Management Plane MUST be able to configure a LSP over a composite > > > link and be able to selectone or a groupcomponent links for the > > > LSP. Management Plane MUST be able to trace which component linkor > > > a group component links a LSP is assigned to and monitor individual > > > component link and composite link performance." > > > > > > My concern is the action of MP and CP should be consistent. > > > > New requirements would have to be added to the requirements document. > > At one point it was suggested that missed management requirements > > could go into a separate CL management requirements document. > > > > In all IETF work it is assumed that anything that can be done by the > > control plane can also, at least in theory, be done in the management > > plane. In practice, a lot of MIB implemeentations are read-only in > > major implementations, even in violation of MIBs that are defined as > > writable. Since this is a general requirement (all protocols must > > have MIBs), it should be OK to not state it. > > > > IMHO, doing things in the management plane is a bad idea due to much > > slower response when multiple faults occur. For those that want to > > duplicate the characteristics of transport networks, including the > > minutes (to hours) of restoration time when multiple faults occur, > > this can be supported. The only providers that I know of that have > > used the management plane for an IP/MPLS network have had a lot of > > trouble with it since they forego the mature LSR control plane > > software and provide functionality in a management system that may be > > home grown or commercial and not as mature or customized. > > > > > Best Regards, > > > > > > Xihua Fu > > > > Thank you for the comments. > > > > Best regards, > > > > Curtis From akatlas@gmail.com Thu Jul 14 09:30:41 2011 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 A1D9F21F8B72 for ; Thu, 14 Jul 2011 09:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, 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 6HboxUPUOSDv for ; Thu, 14 Jul 2011 09:30:37 -0700 (PDT) Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1C721F8A7E for ; Thu, 14 Jul 2011 09:30:37 -0700 (PDT) Received: by pzd13 with SMTP id 13so584606pzd.39 for ; Thu, 14 Jul 2011 09:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=gsPIymxbsVHWdGdNR0NdZGTfgxk2uEKyHwJc7+H8aDo=; b=n8qW55yF1HXEVBh1JbaLTjp5wk+fKKHnNlWQfpYHjYerorUAFg1cEJ0t10RmubCisZ XLkYVKMoE+oSAVd0HPaiW6KNbxtNT9OJN6GQ5HXO0nSbHT/gJzrRQ/5Bd0qFZ3H8DXO5 iN+Cp7pPlqZ+zCkAGLbwfQ0kOFTYtNZJj7Yk8= MIME-Version: 1.0 Received: by 10.68.32.234 with SMTP id m10mr2881678pbi.13.1310661037320; Thu, 14 Jul 2011 09:30:37 -0700 (PDT) Received: by 10.68.55.130 with HTTP; Thu, 14 Jul 2011 09:30:37 -0700 (PDT) In-Reply-To: <201107121513.p6CFDC4K060103@harbor.orleans.occnc.com> References: <201107121513.p6CFDC4K060103@harbor.orleans.occnc.com> Date: Thu, 14 Jul 2011 12:30:37 -0400 Message-ID: Subject: Re: meeting overlap with CCAMP From: Alia Atlas To: curtis@occnc.com, rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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, 14 Jul 2011 16:30:41 -0000 We are looking at options for moving RTGWG - maybe to Weds Afternoon Sessio= n II. This would give us less time, so we may need to be compress slightly... Any issues with this slot? Also, any requests for agenda time that have not already been sent?? Alia On Tue, Jul 12, 2011 at 11:13 AM, Curtis Villamizar wrot= e: > > The meeting seems to overlap with CCAMP and they are not listed as > being in the same room. =A0Can the meeting time be moved to avoid the > conflict? =A0Friday is wide open as far as conflicts with routing area. > > Curtis > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > From akatlas@gmail.com Mon Jul 18 06:25:57 2011 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 0D9ED21F8BB8 for ; Mon, 18 Jul 2011 06:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.825 X-Spam-Level: X-Spam-Status: No, score=-2.825 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_05=-1.11, 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 m1PHHR-6E7-D for ; Mon, 18 Jul 2011 06:25:56 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F19F21F8BB5 for ; Mon, 18 Jul 2011 06:25:56 -0700 (PDT) Received: by pvh18 with SMTP id 18so4558494pvh.31 for ; Mon, 18 Jul 2011 06:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=V9N4b+/n1roKT0ghUkvXqZb/fN7SDqhwdSKyb7DqCLI=; b=CWcsFaCtTG/drcLgxUZYI1QGIdpTBNj5TopmFFXwkoE7edJrUXr26EUsa3nuEfUGpU qtZBmr3U5HZ/10sZ2JZr6Iwv0iymRykXDX/jzwU6ZIhqFen2Lqx45RUJSJOul/AN3Co2 H1h7R+VhjyTv4P/kuCnmYthv0bOqotNAA9IuQ= MIME-Version: 1.0 Received: by 10.68.6.133 with SMTP id b5mr8439569pba.348.1310995555025; Mon, 18 Jul 2011 06:25:55 -0700 (PDT) Received: by 10.68.42.33 with HTTP; Mon, 18 Jul 2011 06:25:55 -0700 (PDT) Date: Mon, 18 Jul 2011 09:25:55 -0400 Message-ID: Subject: meet Weds afternoon session II From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 18 Jul 2011 13:25:57 -0000 We are about to swap with L2VPN on Weds afternoon. This will give us 1 hour, which the chairs think we can do given the requests for time so far. Does this cause problems for anyone - before we commit and go forward (by end of today)?? Thanks, Alia From akatlas@gmail.com Tue Jul 19 11:59:53 2011 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 B5BE111E8082 for ; Tue, 19 Jul 2011 11:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, 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 tZ1roEgEKkhx for ; Tue, 19 Jul 2011 11:59:49 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6162F11E807A for ; Tue, 19 Jul 2011 11:59:49 -0700 (PDT) Received: by pvh18 with SMTP id 18so6208255pvh.31 for ; Tue, 19 Jul 2011 11:59:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=2HtADdCYTNiUQyVizdHlAwFYn8cb4wB9Kh3GNdr3pEs=; b=swKDO2lbAk12YFtgQtASEgCEfO5j35mSvH8YhHP0yJcc5vypvc49ob5HcMZHJuFG+S CKDDEwC/GBlDu0PIGFPXAucRA6XM7I2Yg6Qyq7mlHkjlkOfLXhjqjSJkYZMb3302gU05 l452hw9+eDh9d2N5OQZEBKB83VG/NN6s92Y0E= MIME-Version: 1.0 Received: by 10.68.0.39 with SMTP id 7mr8968434pbb.214.1311101988702; Tue, 19 Jul 2011 11:59:48 -0700 (PDT) Received: by 10.68.42.33 with HTTP; Tue, 19 Jul 2011 11:59:48 -0700 (PDT) Date: Tue, 19 Jul 2011 14:59:48 -0400 Message-ID: Subject: RTGWG moved to Weds 15:10-16:10 in room 202 From: Alia Atlas To: rtgwg@ietf.org Content-Type: multipart/alternative; boundary=bcaec5215dbf4d09fc04a870b8a1 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, 19 Jul 2011 18:59:53 -0000 --bcaec5215dbf4d09fc04a870b8a1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As requested and not opposed by anyone on the list, we've swapped RTGWG wit= h L2VPN so that we are now meeting on Weds from 15:10-16:10. The agenda is: IETF 81 Routing Area WG Agenda Wednesday, July 27 15:10 =96 16:10 Topic Draft Presenter Time Allotted Agenda Bashing & Current Draft Statuses Alia Atlas 5 mins Composite Link Framework draft-so-yong-rtgwg-cl-framework-04 Ning So 5 mins Composite Link Discussion 5 mins Architecture for IP/LDP Fast-Reroute using Maximally Redundant Trees draft-atlas-rtgwg-mrt-frr-architecture-00 Alia Atlas Gabor Enyedi 25 mins Overlay Transport Virtualization draft-hasmit-otv-03 Dhananjaya Rao 15 mins Please send your presentations in by Tuesday before the plenary so we can get them up and available. Thanks, Alia P.S. We did list ccamp as a primary conflict - I guess there were too many= . --bcaec5215dbf4d09fc04a870b8a1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As requested and not opposed by anyone on the list, we've swapped RTGWG= with L2VPN so that we are now meeting on Weds from 15:10-16:10. =A0The age= nda is:

IETF 81 =A0 Routing Area WG Agenda
Wednesday, July 27 =A0= 15:10 =96 16:10

Topic

Draft

Presenter

Time Allotted

Agenda Bashing & Current Draft Statuses

=A0

Alia Atlas

5 mins

Composite Link Framework

draft-so-yong-rtgwg-cl-framework-04

Ning So<= /p>

5 mins

Composite Link Discussion

=A0

=A0

=A05 mins

Architecture for IP/LDP Fast-Reroute using Maximally Redundant Tr= ees

draft-atlas-rtgwg-mrt-frr-architecture-00

Alia Atlas

Gabor Enyedi

25 mins

Overlay Transport Virtualization

draft-= hasmit-otv-03

Dhananj= aya Rao

15 mins

=A0

=A0

=A0

=A0


Please send your presentatio= ns in by Tuesday before the plenary so we can get them up and available.
Thanks,
Alia

P.S.=A0 We did list ccamp as a primary conflict= - I guess there were too many.
--bcaec5215dbf4d09fc04a870b8a1-- From sriganeshkini@gmail.com Mon Jul 25 14:10:31 2011 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 4404221F8ACA for ; Mon, 25 Jul 2011 14:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMWxWDz7eVpd for ; Mon, 25 Jul 2011 14:10:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4809C21F8997 for ; Mon, 25 Jul 2011 14:10:30 -0700 (PDT) Received: by vxi40 with SMTP id 40so4090599vxi.31 for ; Mon, 25 Jul 2011 14:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=KejtiPxERq9jajgn/D4k068C9FwJkvNOGP3YmZwP8ss=; b=ddZmknLMv2P86dS39dIbhLBN4mkIMpaz6PnjhUSTvrxsXL3/rggtYJe7nQcXlZfL+3 PPq/MTudbCIZg7wdpyeKCvY3qrsuKvTz8kau4dSA9RPPx4SmMEG+G5XOChc0wJYULfsj EiSr8KENNseoFPAnHc9PTjMt+JnawhxQUeypc= Received: by 10.52.172.197 with SMTP id be5mr4737690vdc.448.1311628217070; Mon, 25 Jul 2011 14:10:17 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.52.188.34 with HTTP; Mon, 25 Jul 2011 14:09:47 -0700 (PDT) From: Sriganesh Kini Date: Mon, 25 Jul 2011 14:09:47 -0700 X-Google-Sender-Auth: 30y7Nim30UBxgwWxMLcgP9AB5oc Message-ID: Subject: draft-kini-mpls-frr-ldp-01 for review To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Srikanth Narayanan 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, 25 Jul 2011 21:10:31 -0000 Hello, Regarding draft-kini-mpls-frr-ldp-01. We had feedback from the mpls WG to present this draft at RTGWG. Since our request for a slot was late, there is a chance that we may not have adequate time at the end of the session for this draft. In any case we wanted to make the WG aware of the draft and would appreciate any comments. Regards -- - Sri From akatlas@gmail.com Mon Jul 25 14:15:11 2011 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 0D28721F8A4D for ; Mon, 25 Jul 2011 14:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, 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 0A797zzew3St for ; Mon, 25 Jul 2011 14:15:10 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id 734F221F89A1 for ; Mon, 25 Jul 2011 14:15:10 -0700 (PDT) Received: by pzk6 with SMTP id 6so8683025pzk.26 for ; Mon, 25 Jul 2011 14:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SPQRbKuQ8InS4QaOFxOa0u5oXEr2r8YB8fABOfc5Uak=; b=od/BdrKSBv36HUHv1k1MZGBEKqyXYgotiEnhqWYopInKe3D+9H9Qm5r4aYhiy+oD4p yM3jNEou3jyXXVkM2/FzfzsVuKuH7W9xrjq60tFxGph3cl7+26+LgQc66XahZxJFNeYg Q4EQRwI1SghyuYEN55qkySD3uc9QlG4J0X3gg= MIME-Version: 1.0 Received: by 10.68.49.41 with SMTP id r9mr8127397pbn.438.1311628510048; Mon, 25 Jul 2011 14:15:10 -0700 (PDT) Received: by 10.68.64.195 with HTTP; Mon, 25 Jul 2011 14:15:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jul 2011 17:15:10 -0400 Message-ID: Subject: Re: draft-kini-mpls-frr-ldp-01 for review From: Alia Atlas To: Sriganesh Kini Content-Type: multipart/alternative; boundary=bcaec54306826b32bf04a8eb4fca Cc: Srikanth Narayanan , 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, 25 Jul 2011 21:15:11 -0000 --bcaec54306826b32bf04a8eb4fca Content-Type: text/plain; charset=ISO-8859-1 I would encourage folks to read all the drafts, including this one, that will be discussed at RTGWG. As always, the list is a great place to have questions and discussions - and this week those can go to f2f when needed. Alia On Mon, Jul 25, 2011 at 5:09 PM, Sriganesh Kini wrote: > Hello, > > Regarding draft-kini-mpls-frr-ldp-01. > > We had feedback from the mpls WG to present this draft at RTGWG. Since > our request for a slot was late, there is a chance that we may not > have adequate time at the end of the session for this draft. In any > case we wanted to make the WG aware of the draft and would appreciate > any comments. > > Regards > > -- > - Sri > _______________________________________________ > rtgwg mailing list > rtgwg@ietf.org > https://www.ietf.org/mailman/listinfo/rtgwg > --bcaec54306826b32bf04a8eb4fca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would encourage folks to read all the drafts, including this one, that wi= ll be discussed at RTGWG.
As always, the list is a great place to have q= uestions and discussions - and this week those
can go to f2f when needed= .

Alia

On Mon, Jul 25, 2011 at 5:09 PM,= Sriganesh Kini <sriganesh.kini@ericsson.com> wrote:
Hello,

Regarding draft-kini-mpls-frr-ldp-01.

We had feedback from the mpls WG to present this draft at RTGWG. Since
our request for a slot was late, there is a chance that we may not
have adequate time at the end of the session for this draft. In any
case we wanted to make the WG aware of the draft and would appreciate
any comments.

Regards

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

--bcaec54306826b32bf04a8eb4fca--