From jschiel@flowtools.net Mon Feb 4 22:45:35 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2934B21F858C for ; Mon, 4 Feb 2013 22:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MorONqnp-w2R for ; Mon, 4 Feb 2013 22:45:34 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02F0E21F8545 for ; Mon, 4 Feb 2013 22:45:33 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id n8so7379232lbj.31 for ; Mon, 04 Feb 2013 22:45:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=zLr4HvaoFD0s1TmnH2pRwCb2aDb8S+VBbG4Lo17a2Ig=; b=cpu3cdl5SN3oO1S3takIrqIJDbn5x71jhZ1d4DsoQJrLe94CUCMv84ksDuSO0zV8Ai ZjPfI2ERaz77gmnglOgyGOLUQ4r4I4iC77tMtkrgLpnWrxVA9t1Uh2HNop0xGUvthWxY pRCfsmrXVaQQkc56cSzeGHOSyYAkFVMpZmkzV4UgVzV8iKfNoVAGkJVkBcsKyFcHBeke KITeIy8k2OKBTamL5hUJQCQp0GMQYCQPmxgyN1ahtRqtEvWL9dskINv4GmKk57w9aoNt Fc5Z2JiX5y69ZkxGCeo082ek84ucTIFmqM3MNOu4L24e28AqT3RKCvDWxO/lmfyIqcpK gkcg== MIME-Version: 1.0 X-Received: by 10.112.82.136 with SMTP id i8mr9149642lby.74.1360046732510; Mon, 04 Feb 2013 22:45:32 -0800 (PST) Received: by 10.112.26.163 with HTTP; Mon, 4 Feb 2013 22:45:32 -0800 (PST) X-Originating-IP: [67.40.131.57] In-Reply-To: <5107264A.2020501@umn.edu> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> Date: Mon, 4 Feb 2013 23:45:32 -0700 Message-ID: From: John Schiel To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmeOkgQ6FpI5HKK5elGLgzg53xM+Yzv2TcJfXEZYF3nQWQLLnneAZCteLLkIzS+oDpwXWLr Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 06:45:35 -0000 On Mon, Jan 28, 2013 at 6:30 PM, David Farmer wrote: > On 1/28/13 19:03 , Jeff Wheeler wrote: >> >> On Mon, Jan 28, 2013 at 3:33 PM, David Farmer wrote: >>> >>> This creates a knob, and I really don't like that, but honestly there are >>> implementations that DO NOT conform with the "when received, any value >>> MUST >>> be accepted" clause, and we have to deal with, at least for now. So, >>> while >>> I think creating knobs should be avoided, I'm not sure it can >>> realistically >>> be avoided in this case, and with the implementations that are in the >>> wild >>> today. >> >> >> I always like options/knobs but I doubt your suggestion will be popular. >> >> Why do you think propagate-as-received should be the default behavior? > > > The argument is in the intro of the draft; > > The real issue is that reserved flags are only useful if there is > some hope of someday using them for something. If implementations > reset these flags on propagation, then a future revision to the BGP > specification which introduces a new flag will not be able to > propagate the new attribute flag end to end, since it would be very > likely that some well-meaning intermediate router would zero on it. > The effort to roll out implementations that transited the new flag > would almost certainly be prohibitive. > > The compromise is require all conforming implementations to at least support > propagate-as-received as an option. It doesn't completely eliminate the > issue described in the intro, but at least there is still some minimal hope > of being able to implement new flags some day. Especially, since it should > be clear that propagate-as-zero is really just a transition, and maybe in > some future revision it could be removed once any-value-MUST-be-accepted is > more or less universally implemented. One can hope, at least I link that > better than "the bits are dead". > > What do others think? > David I like your suggestion. While not optimal as it does add another knob, it does give the operator the choice on how to deal with these bits and implement a configuration that is expected between the different router makers and versions of code. --John > > -- > ================================================ > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jsw@inconcepts.biz Tue Feb 5 04:40:48 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAEB21F87F7 for ; Tue, 5 Feb 2013 04:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.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 wEaOwvI6HsPQ for ; Tue, 5 Feb 2013 04:40:48 -0800 (PST) Received: from mail-ia0-x22e.google.com (ia-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 54FE021F87D3 for ; Tue, 5 Feb 2013 04:40:48 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id o25so89583iad.19 for ; Tue, 05 Feb 2013 04:40:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Lqhkdboaot6/P9PI3kfRqaTDgm+aHsrkZFL5K2FvudA=; b=hee/ji1KcdQN6RCvHQPAEktuSbo8nhKF68E4f/3ckyqNDRSNAcp+s+fRHn/5FLCsmw xCKAx78hWDOkSguM55v3AyKv1Fr4EcAHwHH+Tmc3luAX8mSUqTeEcn2TS3MwsCYeArHg Ks6wCX3wyEP/4ti23FjfVKx/fL4WsIyxLd+G2cKm+Sg97tZhL2+Oj6XmnRKWRG6z+mhM q+AsAwAD+kDS7l3qTWTK7fftpsVN+I17vTOPDONv/YuXpo6HmBgns58vRtw4avrvHdZR 0xrGRMrkXobAUYt5NSWyCAzWlkzzeJq7IfYosspaYLXlHNbE+AHpW5muyt3TTsHvqekl mgcg== MIME-Version: 1.0 X-Received: by 10.50.40.129 with SMTP id x1mr12678939igk.54.1360068042669; Tue, 05 Feb 2013 04:40:42 -0800 (PST) Received: by 10.50.128.170 with HTTP; Tue, 5 Feb 2013 04:40:42 -0800 (PST) X-Originating-IP: [12.164.118.2] In-Reply-To: <5107264A.2020501@umn.edu> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> Date: Tue, 5 Feb 2013 07:40:42 -0500 Message-ID: From: Jeff Wheeler To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlrBFp7WrdPuxZ+n1sYYIXkLGtzxDirmDgVKzqW68oNrb2u3anWe1n0Jv40VhBGRYCJCiE2 Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 12:40:49 -0000 On Mon, Jan 28, 2013 at 8:30 PM, David Farmer wrote: >> Why do you think propagate-as-received should be the default behavior? > The argument is in the intro of the draft; ... > issue described in the intro, but at least there is still some minimal hope > of being able to implement new flags some day. Especially, since it should > be clear that propagate-as-zero is really just a transition, and maybe in I might agree if John & Susan's draft was honest about the fact that this is a CHANGE in behavior. However, they have instead claimed it is a "clarification." That is really not true and it is an important distinction! As far as I am aware, no one is proposing a use for these bits. I agree that they cannot ever be used without an end-to-end agreement not to zero them out, but it's hard to imagine that it will become "safe" to do this unless someone is willing to originate routes to the DFZ with these bits set, label it an experiment, and break a significant portion of the Internet until networks affected by the didn't-ignore bug update their code. If there was any proposal to use the bits, one would also be changing the language that forbids setting the reserved bits or requires the implementation to ignore the bits on receipt. Notice that they are NOT changing those things. If they really want to apply this change to BGP then they should admit it is a change and request a BGP Capability Code so it is negotiated. The entire goal of the proposal seems to be to allow Juniper to avoid repairing a bug or even admitting that they have a bug, so I think it is unlikely that they will update their draft, get a cap code, write software to implement it, and add a knob to the Juniper UI. So far there has been no reasonable argument supporting their draft, unless you think "I didn't understand what send meant and now I don't want to change my code" is a reasonable justification for changing standardized language that is 20 years old. You know why I oppose this change? Because it is being mis-labeled a clarification, because there is no proposed utility to the change (no use for the bits), and because it is virtually guaranteed that any routes announced to the DFZ this way today would still break networks and cost money. That's a pretty good reason to reject their idea. They are welcome to prove me wrong. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From shares@ndzh.com Tue Feb 5 08:16:02 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD83A21F8934 for ; Tue, 5 Feb 2013 08:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.155 X-Spam-Level: * X-Spam-Status: No, score=1.155 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 5O+GI5W3yO8X for ; Tue, 5 Feb 2013 08:15:52 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC8821F8935 for ; Tue, 5 Feb 2013 08:15:51 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jeff Wheeler'" , "'David Farmer'" References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> In-Reply-To: Date: Tue, 5 Feb 2013 11:15:46 -0500 Message-ID: <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBMhac0XhAnKoHOyYB3aId+E7wFgHJJ7KtAMf02rcB0pPthgHFcHlVAW6OAVoBUTytvAJiFGYcAd5SlwqZG8f+wA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:16:02 -0000 Jeff and Dave: Due to the fact I was there when we draft the text, I called it a clarification. However, my view of history may make it unclear to others. I will update the draft to the word "change". Are you also a supporter of signaling this change with an OPEN option so it can be negotiated? Sue Hares -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Wheeler Sent: Tuesday, February 05, 2013 7:41 AM To: David Farmer Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. On Mon, Jan 28, 2013 at 8:30 PM, David Farmer wrote: >> Why do you think propagate-as-received should be the default behavior? > The argument is in the intro of the draft; ... > issue described in the intro, but at least there is still some minimal > hope of being able to implement new flags some day. Especially, since > it should be clear that propagate-as-zero is really just a transition, > and maybe in I might agree if John & Susan's draft was honest about the fact that this is a CHANGE in behavior. However, they have instead claimed it is a "clarification." That is really not true and it is an important distinction! As far as I am aware, no one is proposing a use for these bits. I agree that they cannot ever be used without an end-to-end agreement not to zero them out, but it's hard to imagine that it will become "safe" to do this unless someone is willing to originate routes to the DFZ with these bits set, label it an experiment, and break a significant portion of the Internet until networks affected by the didn't-ignore bug update their code. If there was any proposal to use the bits, one would also be changing the language that forbids setting the reserved bits or requires the implementation to ignore the bits on receipt. Notice that they are NOT changing those things. If they really want to apply this change to BGP then they should admit it is a change and request a BGP Capability Code so it is negotiated. The entire goal of the proposal seems to be to allow Juniper to avoid repairing a bug or even admitting that they have a bug, so I think it is unlikely that they will update their draft, get a cap code, write software to implement it, and add a knob to the Juniper UI. So far there has been no reasonable argument supporting their draft, unless you think "I didn't understand what send meant and now I don't want to change my code" is a reasonable justification for changing standardized language that is 20 years old. You know why I oppose this change? Because it is being mis-labeled a clarification, because there is no proposed utility to the change (no use for the bits), and because it is virtually guaranteed that any routes announced to the DFZ this way today would still break networks and cost money. That's a pretty good reason to reject their idea. They are welcome to prove me wrong. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From enkechen@cisco.com Tue Feb 5 10:32:37 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191D021F8497 for ; Tue, 5 Feb 2013 10:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R6DFYf1PV+7 for ; Tue, 5 Feb 2013 10:32:36 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id CE99821F8552 for ; Tue, 5 Feb 2013 10:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2855; q=dns/txt; s=iport; t=1360089150; x=1361298750; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=96rS/6yatxABI//rVCOlESpaL+P5M2nill4T/cu5eUI=; b=V9Eupv6CovABhkkUfu04a/GRoSL1O9KjMopzo9iNk7R6hzeMIKLuaWkh cZGznl82bBF4jL6xK6ZADySV27j9ecr/BZVaXtycJis7Z78miH3bJEJy0 tDXHv2F5ES6Xk9+zKCCYxb82TT3JLU9TtUpKosr3TRtlPW+QpMyPHM9+1 A=; X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; d="scan'208";a="70834298" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 05 Feb 2013 18:32:28 +0000 Received: from [10.21.68.52] (sjc-vpn3-1076.cisco.com [10.21.68.52]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r15IWRaC023199; Tue, 5 Feb 2013 18:32:27 GMT Message-ID: <5111503A.1000101@cisco.com> Date: Tue, 05 Feb 2013 10:32:26 -0800 From: Enke Chen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jeff Wheeler References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 18:32:37 -0000 Hi, folks: Clearly there are different implementations in the field because of the ambiguity. I do not think it would be feasible to mandate one behavior over another (after 20 years). It might be useful, however, to document the differences in behavior, and warn coders about not resetting the session. -- Enke On 2/5/13 4:40 AM, Jeff Wheeler wrote: > On Mon, Jan 28, 2013 at 8:30 PM, David Farmer wrote: >>> Why do you think propagate-as-received should be the default behavior? >> The argument is in the intro of the draft; > ... >> issue described in the intro, but at least there is still some minimal hope >> of being able to implement new flags some day. Especially, since it should >> be clear that propagate-as-zero is really just a transition, and maybe in > I might agree if John & Susan's draft was honest about the fact that > this is a CHANGE in behavior. However, they have instead claimed it > is a "clarification." That is really not true and it is an important > distinction! > > As far as I am aware, no one is proposing a use for these bits. I > agree that they cannot ever be used without an end-to-end agreement > not to zero them out, but it's hard to imagine that it will become > "safe" to do this unless someone is willing to originate routes to the > DFZ with these bits set, label it an experiment, and break a > significant portion of the Internet until networks affected by the > didn't-ignore bug update their code. > > If there was any proposal to use the bits, one would also be changing > the language that forbids setting the reserved bits or requires the > implementation to ignore the bits on receipt. Notice that they are > NOT changing those things. > > If they really want to apply this change to BGP then they should admit > it is a change and request a BGP Capability Code so it is negotiated. > The entire goal of the proposal seems to be to allow Juniper to avoid > repairing a bug or even admitting that they have a bug, so I think it > is unlikely that they will update their draft, get a cap code, write > software to implement it, and add a knob to the Juniper UI. > > So far there has been no reasonable argument supporting their draft, > unless you think "I didn't understand what send meant and now I don't > want to change my code" is a reasonable justification for changing > standardized language that is 20 years old. > > You know why I oppose this change? Because it is being mis-labeled a > clarification, because there is no proposed utility to the change (no > use for the bits), and because it is virtually guaranteed that any > routes announced to the DFZ this way today would still break networks > and cost money. That's a pretty good reason to reject their idea. > > They are welcome to prove me wrong. From jsw@inconcepts.biz Tue Feb 5 11:20:45 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2DC21F8681 for ; Tue, 5 Feb 2013 11:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.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 UR3eefSJFHZs for ; Tue, 5 Feb 2013 11:20:45 -0800 (PST) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id EF64E21F8654 for ; Tue, 5 Feb 2013 11:20:44 -0800 (PST) Received: by mail-ia0-f179.google.com with SMTP id x24so553053iak.38 for ; Tue, 05 Feb 2013 11:20:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+LornNauXoHa9ndd6o2ZodVykqdc8AQCwB9aMHRgaH4=; b=WMRGJRz1TI03WkRxUqvdWUU+XKuwEk3plJhJvx6G63t4ebp+tJmBVBREndIfzfi3tZ UvHzCMS2rKUoeP/HeVfqHchKqFgsJe+2lehuTpGLmgjqkjJ/bn2ATIqO2xDsidmrfVm5 Hze+DGXqFx7B4KOkeEznE6m+5t3PFVaKXWuyUQ33BHWNOlk73FiNKOEcL5PqE4inKrbF BdhWjpSr9UiGkGJL2kWzAVUJh/rSXfTAX4/J9yU3CiNvv/2jlW98DaowhNkNj/X/2ZAa oHVLJI8gJzudR34tQzPaot7RuItxhPY5GTVXiyQrctRwk7pqI+8we4SuzFKTv+1jEtjc vFew== MIME-Version: 1.0 X-Received: by 10.42.33.196 with SMTP id j4mr23708410icd.4.1360092039733; Tue, 05 Feb 2013 11:20:39 -0800 (PST) Received: by 10.50.128.170 with HTTP; Tue, 5 Feb 2013 11:20:39 -0800 (PST) X-Originating-IP: [12.164.118.2] In-Reply-To: <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> Date: Tue, 5 Feb 2013 14:20:39 -0500 Message-ID: From: Jeff Wheeler To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQng2Kv8w/HGYvZnIgT4DEy05eDLkyOnHK61pBEkBY8yZVMaswA5fLDNi7NqgK9YgeV1VU0y Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:20:46 -0000 On Tue, Feb 5, 2013 at 11:15 AM, Susan Hares wrote: > I will update the draft to the word "change". Are you also a supporter of > signaling this change with an OPEN option so it can be negotiated? I assume you mean a Capability Code will be used to indicate a receiver's willingness to accept non-zero reserved Attribute Flags bits. I support that idea if it is also standardized that any router announcing such Capability promises NOT to send non-zero reserved bits, if the BGP neighbor did not also advertise the Capability. This means that any vendor who wants to use the bits can do so safely, and a vendor who wants to implement that feature will definitely fail-safe if his neighboring router might mis-handle the bits (fail to IGNORE.) -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From jakob.heitz@ericsson.com Tue Feb 5 16:11:37 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF321F8984 for ; Tue, 5 Feb 2013 16:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qP1Noa515XgJ for ; Tue, 5 Feb 2013 16:11:36 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B9A5721F897A for ; Tue, 5 Feb 2013 16:11:36 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-e9-51119fb73873 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id C3.B6.31450.7BF91115; Wed, 6 Feb 2013 01:11:36 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 19:11:35 -0500 From: Jakob Heitz To: Jeff Wheeler Thread-Topic: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: AQHOA9XzZWjnsAjwK0ua8g75qN29v5hr9WBf Date: Wed, 6 Feb 2013 00:11:34 +0000 Message-ID: References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyuXRPrO6O+YKBBg2TBC1e3X7GZHFu5TdG iz9vXrE4MHssWfKTyWPt/PvsHrNfX2cNYI7isklJzcksSy3St0vgyti3bApLwSXuij0/drI3 MK7g7GLk5JAQMJE4v+oNI4QtJnHh3nq2LkYuDiGBI4wSz+62sEI4yxglbixZCVbFJqAj8e16 FzOILSKgKtH0/SdQBwcHs4CFxK6vISCmsECsxN0nlRAVcRJXP2+BqjaSaJ3bzgRiswioSLze 28gGYvMK2Ev8/beDBWLVVBaJfVP6mEHmcAoESnw66wFSwwh02/dTa8B6mQXEJW49mc8EcbOA xJI955khbFGJl4//sULU6Egs2P2JDcLWlli28DUzxC5BiZMzn7BMYBSdhWTULCQts5C0zELS soCRZRUjR2lxalluupHBJkZgfByTYNPdwbjnpeUhRmkOFiVx3iDXCwFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGOuWq0/66M3KkPNyDfe2HxL7a2x8WGYaSM0tufL9ZabeTad3Z5iWNURq ioqmx1hbNnxVN65V8v1woTjoY43I8qc2868qV+by6s07plN9KCaq5JMnk0r6LA1DEePg6K23 fDym2UXanP/yXEt18/f3AZbVGkFTFkyJyDZbWedw5tQd7sLgBk1uJZbijERDLeai4kQADNax aV0CAAA= Cc: idr wg , Susan Hares Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 00:11:37 -0000 If you want to use the bits in a new feature, you can only do it to signal = something to the neighbor router, not to have it propagate to further route= rs. There is a large installed base of routers many of which will not be up= graded for many years or ever. You can not assume that these bits will make= it further than one hop. -- Jakob Heitz. On Feb 6, 2013, at 3:21 AM, "Jeff Wheeler" wrote: > On Tue, Feb 5, 2013 at 11:15 AM, Susan Hares wrote: >> I will update the draft to the word "change". Are you also a supporter = of >> signaling this change with an OPEN option so it can be negotiated? >=20 > I assume you mean a Capability Code will be used to indicate a > receiver's willingness to accept non-zero reserved Attribute Flags > bits. >=20 > I support that idea if it is also standardized that any router > announcing such Capability promises NOT to send non-zero reserved > bits, if the BGP neighbor did not also advertise the Capability. This > means that any vendor who wants to use the bits can do so safely, and > a vendor who wants to implement that feature will definitely fail-safe > if his neighboring router might mis-handle the bits (fail to IGNORE.) >=20 > --=20 > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From stbryant@cisco.com Wed Feb 6 10:54:52 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831A921F8A4A for ; Wed, 6 Feb 2013 10:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwD0WOJoSaKt for ; Wed, 6 Feb 2013 10:54:50 -0800 (PST) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD9321F8473 for ; Wed, 6 Feb 2013 10:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4813; q=dns/txt; s=iport; t=1360176888; x=1361386488; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ZLMRG133HkYXE2KBIkWKv1eVbtjinEIxYGSlcv5HzVo=; b=cTpKXpW1aPDgpvKpGjqVxB083Zac2sMJ9g7qAbIN1VEc1dgJNSF4qvlc sh9SJOkLTLXxWh4PvvjJXW6lN39KJcM21vpdSv60AFCeDjah5ZhE34gzw 1hcYr8A97lhyr7iMy4bMUog90leu1ePeNucM7UMeYCCHOsXJPP8zBPqDg A=; X-IronPort-AV: E=Sophos;i="4.84,617,1355097600"; d="scan'208";a="11644787" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 06 Feb 2013 18:54:47 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r16Isl7n024839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2013 18:54:47 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r16IsjUk008112; Wed, 6 Feb 2013 18:54:46 GMT Message-ID: <5112A6F5.9040807@cisco.com> Date: Wed, 06 Feb 2013 18:54:45 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: RFC Errata System References: <20130123043109.DF35472E039@rfc-editor.org> In-Reply-To: <20130123043109.DF35472E039@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: idr@ietf.org, david@opensourcerouting.org, yakov@juniper.net, shares@ndzh.com Subject: Re: [Idr] [Technical Errata Reported] RFC5291 (3468) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 18:54:52 -0000 I think that the right process is for the WG to decide the answer and if necessary for someone to write up a short update to RFC5291 I will close the errata with a pointer to this thread in the IDR archive. Stewart On 23/01/2013 04:31, RFC Errata System wrote: > The following errata report has been submitted for RFC5291, > "Outbound Route Filtering Capability for BGP-4". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5291&eid=3468 > > -------------------------------------- > Type: Technical > Reported by: David Lamparter > > Section: 5 > > Original Text > ------------- > 5. Outbound Route Filtering Capability > > > > > > A BGP speaker that is willing to receive ORF entries from its peer, > > or a BGP speaker that would like to send ORF entries to its peer, > > advertises this to the peer by using the Outbound Route Filtering > > Capability, as described below. > > > > The Outbound Route Filtering Capability is a new BGP Capability > > [BGP-CAP] defined as follows: > > > > Capability code: 3 > > > > Capability length: variable > > > > Capability value: one or more of the entries as shown in Figure 3. > > > > +--------------------------------------------------+ > > | Address Family Identifier (2 octets) | > > +--------------------------------------------------+ > > | Reserved (1 octet) | > > +--------------------------------------------------+ > > | Subsequent Address Family Identifier (1 octet) | > > +--------------------------------------------------+ > > | Number of ORFs (1 octet) | > > +--------------------------------------------------+ > > | ORF Type (1 octet) | > > +--------------------------------------------------+ > > | Send/Receive (1 octet) | > > +--------------------------------------------------+ > > | ... | > > +--------------------------------------------------+ > > | ORF Type (1 octet) | > > +--------------------------------------------------+ > > | Send/Receive (1 octet) | > > +--------------------------------------------------+ > > > > Figure 3: Outbound Route Filtering Capability Encoding > > > > Corrected Text > -------------- > > > Notes > ----- > RFC5291 does not specify how the ORF capability is supposed to be used > > in conjunction with multiple enabled AFI/SAFI combinations. The text > > can be interpreted as either "one capability instance will be sent, > > carrying multiple blocks as described in Figure 3" or as "the > > capability will be supplied in more than instance". > > > > Note also that RFC3392 [BGP-CAP] Section 4 reads: > > > > BGP speakers MAY include more than one instance of a capability (as > > identified by the Capability Code) with non-zero Capability Length > > field, but with different Capability Value, and either the same or > > different Capability Length. Processing of these capability > > instances is specific to the Capability Code and MUST be described in > > the document introducing the new capability. > > > > Latter description of how multiple instances of the capability are to be > > processed - albeit relatively obvious - is nowhere to be found in RFC5291. > > > > > > Respectfully requesting a clarification, > > > > David Lamparter > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5291 (draft-ietf-idr-route-filter-17) > -------------------------------------- > Title : Outbound Route Filtering Capability for BGP-4 > Publication Date : August 2008 > Author(s) : E. Chen, Y. Rekhter > Category : PROPOSED STANDARD > Source : Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From equinox@diac24.net Wed Feb 6 12:49:40 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EB321F871D for ; Wed, 6 Feb 2013 12:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-O4FlSc8nxT for ; Wed, 6 Feb 2013 12:49:39 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD6321F86EB for ; Wed, 6 Feb 2013 12:49:39 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U3Bw1-0006NH-00; Wed, 06 Feb 2013 21:49:37 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1U3Bvo-00AyZW-10; Wed, 06 Feb 2013 21:49:26 +0100 Date: Wed, 6 Feb 2013 21:49:23 +0100 From: David Lamparter To: Stewart Bryant Message-ID: <20130206204923.GL1775516@jupiter.n2.diac24.net> References: <20130123043109.DF35472E039@rfc-editor.org> <5112A6F5.9040807@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5112A6F5.9040807@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org Subject: Re: [Idr] [Technical Errata Reported] RFC5291 (3468) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 20:49:40 -0000 On Wed, Feb 06, 2013 at 06:54:45PM +0000, Stewart Bryant wrote: > I think that the right process is for the WG to decide the answer > and if necessary for someone to write up a short update to > RFC5291 > > I will close the errata with a pointer to this thread in the > IDR archive. Thanks for the reply. I was hoping that there would be an easy fix, maybe because the approach was clear from discussions back at the creation of the draft, but, alas, no such luck it seems. -David > On 23/01/2013 04:31, RFC Errata System wrote: > > The following errata report has been submitted for RFC5291, > > "Outbound Route Filtering Capability for BGP-4". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5291&eid=3468 [...] > > Notes > > ----- > > RFC5291 does not specify how the ORF capability is supposed to be used > > in conjunction with multiple enabled AFI/SAFI combinations. The text > > can be interpreted as either "one capability instance will be sent, > > carrying multiple blocks as described in Figure 3" or as "the > > capability will be supplied in more than instance". [...] From internet-drafts@ietf.org Thu Feb 7 05:27:08 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD0421F87AB; Thu, 7 Feb 2013 05:27:08 -0800 (PST) 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=[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 e7PF79N5HjoC; Thu, 7 Feb 2013 05:27:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A132A21F8569; Thu, 7 Feb 2013 05:27:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130207132707.29655.57582.idtracker@ietfa.amsl.com> Date: Thu, 07 Feb 2013 05:27:07 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-as-private-reservation-03.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 13:27:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Autonomous System (AS) Reservation for Private Use Author(s) : Jon Mitchell Filename : draft-ietf-idr-as-private-reservation-03.txt Pages : 5 Date : 2013-02-07 Abstract: This document describes the reservation of Autonomous System numbers (ASNs) that are for Private Use only and MUST NOT be advertised to the Internet, known as Private Use ASNs. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-as-private-reservation-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-as-private-reservation-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shares@ndzh.com Thu Feb 7 10:16:14 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5566721F8B7D for ; Thu, 7 Feb 2013 10:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.409 X-Spam-Level: * X-Spam-Status: No, score=1.409 tagged_above=-999 required=5 tests=[AWL=0.904, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 Ky8lWuLhP4ie for ; Thu, 7 Feb 2013 10:16:14 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BA8ED21F8AD4 for ; Thu, 7 Feb 2013 10:16:13 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jeff Wheeler'" References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> In-Reply-To: Date: Thu, 7 Feb 2013 13:16:07 -0500 Message-ID: <002a01ce055f$33771fc0$9a655f40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBMhac0XhAnKoHOyYB3aId+E7wFgHJJ7KtAMf02rcB0pPthgHFcHlVAW6OAVoBUTytvAJiFGYcAd5SlwoCPqYz+AHuGxF/mPvql6A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 18:16:14 -0000 Jeff: Thank you for the indication of the support of the capability code. Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Wheeler Sent: Tuesday, February 05, 2013 2:21 PM To: Susan Hares Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. On Tue, Feb 5, 2013 at 11:15 AM, Susan Hares wrote: > I will update the draft to the word "change". Are you also a > supporter of signaling this change with an OPEN option so it can be negotiated? I assume you mean a Capability Code will be used to indicate a receiver's willingness to accept non-zero reserved Attribute Flags bits. I support that idea if it is also standardized that any router announcing such Capability promises NOT to send non-zero reserved bits, if the BGP neighbor did not also advertise the Capability. This means that any vendor who wants to use the bits can do so safely, and a vendor who wants to implement that feature will definitely fail-safe if his neighboring router might mis-handle the bits (fail to IGNORE.) -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From Donald.Smith@CenturyLink.com Thu Feb 7 11:20:15 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E8521F8856 for ; Thu, 7 Feb 2013 11:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZeaTVybWKVv for ; Thu, 7 Feb 2013 11:20:14 -0800 (PST) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBDA21F8809 for ; Thu, 7 Feb 2013 11:20:14 -0800 (PST) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id r17JKDi9029403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2013 12:20:13 -0700 (MST) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 215121E005A; Thu, 7 Feb 2013 13:20:08 -0600 (CST) Received: from sudnp797.qintra.com (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id F06B51E0059; Thu, 7 Feb 2013 13:20:07 -0600 (CST) Received: from sudnp797.qintra.com (localhost [127.0.0.1]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r17JK7RY003401; Thu, 7 Feb 2013 12:20:07 -0700 (MST) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.qintra.com [151.119.128.28]) by sudnp797.qintra.com (8.14.4/8.14.4) with ESMTP id r17JK7ET003391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Feb 2013 12:20:07 -0700 (MST) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.02.0318.001; Thu, 7 Feb 2013 12:20:06 -0700 From: "Smith, Donald" To: Susan Hares , "'Jeff Wheeler'" Thread-Topic: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. Thread-Index: AQHOBV86oR6rhctP+kW6Xag7IAqfFphuwipG Date: Thu, 7 Feb 2013 19:20:06 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> , <002a01ce055f$33771fc0$9a655f40$@ndzh.com> In-Reply-To: <002a01ce055f$33771fc0$9a655f40$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: multipart/alternative; boundary="_000_68EFACB32CF4464298EA2779B058889D0A2C1015PDDCWMBXEX503ct_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 19:20:15 -0000 --_000_68EFACB32CF4464298EA2779B058889D0A2C1015PDDCWMBXEX503ct_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This works but only if the announcer is saying "I support the use of those = bits AND all of my peers do" or "I support the use of those bits AND won't = propagate to peers that don't support the use of those bits". Otherwise you support it, I support it but some of my peers don't and when = I advertise those to them unmodified they fail. Right? (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com ________________________________ From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Susan Hares = [shares@ndzh.com] Sent: Thursday, February 07, 2013 11:16 AM To: 'Jeff Wheeler' Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-= low-bits-fix-00. Jeff: Thank you for the indication of the support of the capability code. Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Wheeler Sent: Tuesday, February 05, 2013 2:21 PM To: Susan Hares Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. On Tue, Feb 5, 2013 at 11:15 AM, Susan Hares wrote: > I will update the draft to the word "change". Are you also a > supporter of signaling this change with an OPEN option so it can be negotiated? I assume you mean a Capability Code will be used to indicate a receiver's willingness to accept non-zero reserved Attribute Flags bits. I support that idea if it is also standardized that any router announcing such Capability promises NOT to send non-zero reserved bits, if the BGP neighbor did not also advertise the Capability. This means that any vendor who wants to use the bits can do so safely, and a vendor who wants to implement that feature will definitely fail-safe if his neighboring router might mis-handle the bits (fail to IGNORE.) -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_68EFACB32CF4464298EA2779B058889D0A2C1015PDDCWMBXEX503ct_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This works but only if the announcer is saying "I support the use o= f those bits AND all of my peers do" or "I support the use of tho= se bits AND won't propagate to peers that don't support the use of those bi= ts".

 

Otherwise you support it, I support it but some of my peers don't and wh= en I advertise those to them unmodified they fail.

 

Right?

 

 

(coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centuryl= ink.com
From: idr-bounces@ietf.org [idr-bounces@ie= tf.org] on behalf of Susan Hares [shares@ndzh.com]
Sent: Thursday, February 07, 2013 11:16 AM
To: 'Jeff Wheeler'
Cc: 'idr wg'
Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-upd= ate-attrib-low-bits-fix-00.

Jeff:

Thank you for the indication of the support of the capability code.

Sue

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeff
Wheeler
Sent: Tuesday, February 05, 2013 2:21 PM
To: Susan Hares
Cc: idr wg
Subject: Re: [Idr] 2 week WG adoption & LC
ondraft-hares-idr-update-attrib-low-bits-fix-00.

On Tue, Feb 5, 2013 at 11:15 AM, Susan Hares <shares@ndzh.com> wrote:=
> I will update the draft to the word "change".  Are you = also a
> supporter of signaling this change with an OPEN option so it can be negotiated?

I assume you mean a Capability Code will be used to indicate a receiver's willingness to accept non-zero reserved Attribute Flags bits.

I support that idea if it is also standardized that any router announcing such Capability promises NOT to send non-zero reserved bits, if the BGP
neighbor did not also advertise the Capability.  This means that any v= endor
who wants to use the bits can do so safely, and a vendor who wants to
implement that feature will definitely fail-safe if his neighboring router<= br> might mis-handle the bits (fail to IGNORE.)

--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr
--_000_68EFACB32CF4464298EA2779B058889D0A2C1015PDDCWMBXEX503ct_-- From shares@ndzh.com Thu Feb 7 11:26:51 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687DB21F88FC for ; Thu, 7 Feb 2013 11:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.229 X-Spam-Level: * X-Spam-Status: No, score=1.229 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 ngp1kKrmkRj8 for ; Thu, 7 Feb 2013 11:26:41 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C5D3221F8678 for ; Thu, 7 Feb 2013 11:26:40 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Smith, Donald'" , "'Jeff Wheeler'" References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> , <002a01ce055f$33771fc0$9a655f40$@ndzh.com> <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> Date: Thu, 7 Feb 2013 14:26:36 -0500 Message-ID: <005801ce0569$0bc92680$235b7380$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0059_01CE053F.22F58F80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBMhac0XhAnKoHOyYB3aId+E7wFgHJJ7KtAMf02rcB0pPthgHFcHlVAW6OAVoBUTytvAJiFGYcAd5SlwoCPqYz+AHuGxF/AdtrIpABfHBkipji/OMg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 19:26:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0059_01CE053F.22F58F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Donald Yes. To be precise. Peer A----Peer-B if both support, then it works. Peer-A-peer-B-Peer-c Only if all peers support. If peering A-B and not see, no support yes. Therefore, If I am B and I want this to work - I refuse A & C unless on. It becomes a configuration. Iteration out. Networks can adopt this configuration flag to assure themselves this bug won't happen. If you want to mix and match, then community flags could be set. However, general community support is there. If we want to establish a "well-known" community, it is possible; but I would prefer to have actual use dictate that. Sue From: Smith, Donald [mailto:Donald.Smith@CenturyLink.com] Sent: Thursday, February 07, 2013 2:20 PM To: Susan Hares; 'Jeff Wheeler' Cc: 'idr wg' Subject: RE: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. This works but only if the announcer is saying "I support the use of those bits AND all of my peers do" or "I support the use of those bits AND won't propagate to peers that don't support the use of those bits". Otherwise you support it, I support it but some of my peers don't and when I advertise those to them unmodified they fail. Right? (coffee != sleep) & (!coffee == sleep) Donald.Smith@centurylink.com _____ From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Susan Hares [shares@ndzh.com] Sent: Thursday, February 07, 2013 11:16 AM To: 'Jeff Wheeler' Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. Jeff: Thank you for the indication of the support of the capability code. Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Wheeler Sent: Tuesday, February 05, 2013 2:21 PM To: Susan Hares Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. On Tue, Feb 5, 2013 at 11:15 AM, Susan Hares wrote: > I will update the draft to the word "change". Are you also a > supporter of signaling this change with an OPEN option so it can be negotiated? I assume you mean a Capability Code will be used to indicate a receiver's willingness to accept non-zero reserved Attribute Flags bits. I support that idea if it is also standardized that any router announcing such Capability promises NOT to send non-zero reserved bits, if the BGP neighbor did not also advertise the Capability. This means that any vendor who wants to use the bits can do so safely, and a vendor who wants to implement that feature will definitely fail-safe if his neighboring router might mis-handle the bits (fail to IGNORE.) -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_0059_01CE053F.22F58F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Donald


Yes. To be precise.

 

Peer A----Peer-B  if both support, then it = works.

Peer-A-peer-B-Peer-c Only if all peers support. =

 

If peering A-B and not see, no support yes.  Therefore, If I am = B and I want this to work – I refuse A & C unless on. It = becomes a configuration. Iteration out.  Networks can adopt this = configuration flag to assure themselves this bug won’t happen. =

 

If you want to mix and match, then community flags could be set. =  However, general community support is there.  If we want to = establish a “well-known” community, it is possible; but I = would prefer to have actual use dictate that.

 

Sue

 

 

 

 

From:= = Smith, Donald [mailto:Donald.Smith@CenturyLink.com]
Sent: = Thursday, February 07, 2013 2:20 PM
To: Susan Hares; 'Jeff = Wheeler'
Cc: 'idr wg'
Subject: RE: [Idr] 2 week WG = adoption & LC = ondraft-hares-idr-update-attrib-low-bits-fix-00.

 

= This works but only if the announcer is saying "I support the use = of those bits AND all of my peers do" or "I support the use of = those bits AND won't propagate to peers that don't support the use of = those bits".

=  

= Otherwise you support it, I support it but some of my peers don't and = when I advertise those to them unmodified they = fail.

=  

= Right?

=  

=  

= (coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centurylink.com=

= From:= idr-bounces@ietf.org = [idr-bounces@ietf.org] on behalf of Susan Hares = [shares@ndzh.com]
Sent: Thursday, February 07, 2013 11:16 = AM
To: 'Jeff Wheeler'
Cc: 'idr = wg'
Subject: Re: [Idr] 2 week WG adoption & LC = ondraft-hares-idr-update-attrib-low-bits-fix-00.

Jeff:

Thank you for the = indication of the support of the capability code.

Sue =

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Jeff
Wheeler
Sent: Tuesday, February 05, 2013 2:21 PM
To: Susan = Hares
Cc: idr wg
Subject: Re: [Idr] 2 week WG adoption & = LC
ondraft-hares-idr-update-attrib-low-bits-fix-00.

On Tue, = Feb 5, 2013 at 11:15 AM, Susan Hares <shares@ndzh.com> wrote:
> I = will update the draft to the word "change".  Are you also = a
> supporter of signaling this change with an OPEN option so it = can be
negotiated?

I assume you mean a Capability Code will be = used to indicate a receiver's
willingness to accept non-zero reserved = Attribute Flags bits.

I support that idea if it is also = standardized that any router announcing
such Capability promises NOT = to send non-zero reserved bits, if the BGP
neighbor did not also = advertise the Capability.  This means that any vendor
who wants = to use the bits can do so safely, and a vendor who wants to
implement = that feature will definitely fail-safe if his neighboring = router
might mis-handle the bits (fail to IGNORE.)

--
Jeff = S Wheeler <jsw@inconcepts.biz>
Sr = Network Operator  /  Innovative Network = Concepts
_______________________________________________
Idr = mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

__= _____________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

------=_NextPart_000_0059_01CE053F.22F58F80-- From shares@ndzh.com Thu Feb 7 11:30:25 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E61221F88DD for ; Thu, 7 Feb 2013 11:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 g2DLewTQnAtP for ; Thu, 7 Feb 2013 11:30:23 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D5A0A21F85EE for ; Thu, 7 Feb 2013 11:30:22 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Smith, Donald'" , "'Jeff Wheeler'" References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> , <002a01ce055f$33771fc0$9a655f40$@ndzh.com> <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> <005801ce0569$0bc92680$235b7380$@ndzh.com> In-Reply-To: <005801ce0569$0bc92680$235b7380$@ndzh.com> Date: Thu, 7 Feb 2013 14:30:18 -0500 Message-ID: <007a01ce0569$905ea5f0$b11bf1d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01CE053F.A78D58E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBMhac0XhAnKoHOyYB3aId+E7wFgHJJ7KtAMf02rcB0pPthgHFcHlVAW6OAVoBUTytvAJiFGYcAd5SlwoCPqYz+AHuGxF/AdtrIpABfHBkigEZ7+KdmNovU2A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 19:30:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007B_01CE053F.A78D58E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ignore earlier text.. (sigh.. obviously I need more coffee today). From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, February 07, 2013 2:27 PM To: 'Smith, Donald'; 'Jeff Wheeler' Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. Donald Yes. To be precise. Peer A----Peer-B if both support, then it works. Peer-A-peer-B-Peer-c Only if all peers support. If peering A-B and C . Therefore, If I am B and I want this to work - I refuse A & C unless flag bit on. Therefore, it becomes a configuration issue. Networks can adopt this configuration flag to assure themselves this bug won't happen. If you want to track this in UPDATEs, then you could use community flags. If we want to establish a "well-known" community, it is possible; but I would prefer to have actual use dictate that. Sue From: Smith, Donald [mailto:Donald.Smith@CenturyLink.com] Sent: Thursday, February 07, 2013 2:20 PM To: Susan Hares; 'Jeff Wheeler' Cc: 'idr wg' Subject: RE: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. This works but only if the announcer is saying "I support the use of those bits AND all of my peers do" or "I support the use of those bits AND won't propagate to peers that don't support the use of those bits". Otherwise you support it, I support it but some of my peers don't and when I advertise those to them unmodified they fail. Right? (coffee != sleep) & (!coffee == sleep) Donald.Smith@centurylink.com _____ From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Susan Hares [shares@ndzh.com] Sent: Thursday, February 07, 2013 11:16 AM To: 'Jeff Wheeler' Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. Jeff: Thank you for the indication of the support of the capability code. Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Wheeler Sent: Tuesday, February 05, 2013 2:21 PM To: Susan Hares Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. On Tue, Feb 5, 2013 at 11:15 AM, Susan Hares wrote: > I will update the draft to the word "change". Are you also a > supporter of signaling this change with an OPEN option so it can be negotiated? I assume you mean a Capability Code will be used to indicate a receiver's willingness to accept non-zero reserved Attribute Flags bits. I support that idea if it is also standardized that any router announcing such Capability promises NOT to send non-zero reserved bits, if the BGP neighbor did not also advertise the Capability. This means that any vendor who wants to use the bits can do so safely, and a vendor who wants to implement that feature will definitely fail-safe if his neighboring router might mis-handle the bits (fail to IGNORE.) -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_007B_01CE053F.A78D58E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ignore earlier text…. (sigh.. obviously I need more coffee = today).

 

From:= = idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Susan Hares
Sent: Thursday, February 07, 2013 2:27 = PM
To: 'Smith, Donald'; 'Jeff Wheeler'
Cc: 'idr = wg'
Subject: Re: [Idr] 2 week WG adoption & LC = ondraft-hares-idr-update-attrib-low-bits-fix-00.

 

Donald


Yes. To be precise.

 

Peer A----Peer-B  if both support, then it = works.

Peer-A-peer-B-Peer-c Only if all peers support. =

 

If peering A-B and C .  Therefore, If I am B and I want this to work – I refuse = A & C unless flag bit on.

Therefore, it becomes a configuration issue.  Networks can adopt this configuration flag to assure = themselves this bug won’t happen.

 

If you want to track this in UPDATEs,  then you could use community flags. If we want to establish a “well-known” community, = it is possible; but I would prefer to have actual use dictate that. =

 

Sue

 

 

 

 

From:= = Smith, Donald [mailto:Donald.Smith@CenturyL= ink.com]
Sent: Thursday, February 07, 2013 2:20 = PM
To: Susan Hares; 'Jeff Wheeler'
Cc: 'idr = wg'
Subject: RE: [Idr] 2 week WG adoption & LC = ondraft-hares-idr-update-attrib-low-bits-fix-00.

 

= This works but only if the announcer is saying "I support the use = of those bits AND all of my peers do" or "I support the use of = those bits AND won't propagate to peers that don't support the use of = those bits".

=  

= Otherwise you support it, I support it but some of my peers don't and = when I advertise those to them unmodified they = fail.

=  

= Right?

=  

=  

= (coffee !=3D sleep) & (!coffee =3D=3D sleep)
 Donald.Smith@centurylink.com=

= From:= idr-bounces@ietf.org = [idr-bounces@ietf.org] on behalf of Susan Hares = [shares@ndzh.com]
Sent: Thursday, February 07, 2013 11:16 = AM
To: 'Jeff Wheeler'
Cc: 'idr = wg'
Subject: Re: [Idr] 2 week WG adoption & LC = ondraft-hares-idr-update-attrib-low-bits-fix-00.

Jeff:

Thank you for the = indication of the support of the capability code.

Sue =

-----Original Message-----
From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Jeff
Wheeler
Sent: Tuesday, February 05, 2013 2:21 PM
To: Susan = Hares
Cc: idr wg
Subject: Re: [Idr] 2 week WG adoption & = LC
ondraft-hares-idr-update-attrib-low-bits-fix-00.

On Tue, = Feb 5, 2013 at 11:15 AM, Susan Hares <shares@ndzh.com> wrote:
> I = will update the draft to the word "change".  Are you also = a
> supporter of signaling this change with an OPEN option so it = can be
negotiated?

I assume you mean a Capability Code will be = used to indicate a receiver's
willingness to accept non-zero reserved = Attribute Flags bits.

I support that idea if it is also = standardized that any router announcing
such Capability promises NOT = to send non-zero reserved bits, if the BGP
neighbor did not also = advertise the Capability.  This means that any vendor
who wants = to use the bits can do so safely, and a vendor who wants to
implement = that feature will definitely fail-safe if his neighboring = router
might mis-handle the bits (fail to IGNORE.)

--
Jeff = S Wheeler <jsw@inconcepts.biz>
Sr = Network Operator  /  Innovative Network = Concepts
_______________________________________________
Idr = mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

__= _____________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

------=_NextPart_000_007B_01CE053F.A78D58E0-- From jsw@inconcepts.biz Thu Feb 7 14:34:49 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B254421F83EF for ; Thu, 7 Feb 2013 14:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 cMds41yZ+5iB for ; Thu, 7 Feb 2013 14:34:49 -0800 (PST) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0E92321F8958 for ; Thu, 7 Feb 2013 14:34:48 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id r4so3521044iaj.34 for ; Thu, 07 Feb 2013 14:34:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=0LHzyK5tEaqBczbxNaklQYoeC2FNbJfihMxSwJi46P8=; b=EwLW2NIKomcG/i+9FuoRxFDnvqHh/USt6UzjNrJuNULgXVBlwHHJ1rCEKp9cBN58by pOebP6u7CgzWFnwTmxtTmK0ctsV4xWE4UqOHPadITJKv/JpgxQ1KYG2CW32xCRDHnBbA 06ImKe3t8nVUvPw/0OI1tTM1d4FdoV3K2RR10MIka4MGoJgOtoq9WlGhPuFnpCzmusth MBhNv9eWn9pSHXj2PABPz2f36vbbV4i+7PXVzFWVJqRRzF4XUYkcGhGocYe1kW6I93OL T6+N7lNTeUnbkzgzBk3b2Zq+tEE6A1xhDQLTJotWTTgPCg62nyHuydQLgHtL5qURVWnJ nFkg== MIME-Version: 1.0 X-Received: by 10.42.91.209 with SMTP id q17mr5378380icm.50.1360276487051; Thu, 07 Feb 2013 14:34:47 -0800 (PST) Received: by 10.50.36.4 with HTTP; Thu, 7 Feb 2013 14:34:46 -0800 (PST) X-Originating-IP: [74.134.22.105] Date: Thu, 7 Feb 2013 17:34:46 -0500 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnyrwXKeFEoSe3GtnqgRjHgPNeHkaqvG4y2E9/poQdMK2ZEWwZ+opkhHN4LTn8xfG1WZ/CF Subject: [Idr] reserved attribute bits, challenges with using them X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 22:34:49 -0000 The Hares/Scudder draft regarding the use of reserved bits in the BGP Attribute Flags field, on the surface, aims to provide a means to use these bits in the future. I do not know of any proposed use for them, but if there were, obviously some problems must first be resolved. The first is the issue they seek to fix, which is, to make it safe to propagate values other than 0 in those bits. The second problem is that a receiving router cannot know, with certainty, that zeroes in these bits are actually information, or if a router in the signaling path has reset them to 0. Imagine that the Capability idea were adopted and you had the following routers and BGP sessions: R1---R2---R3---R4 Routers R1, R3, and R4 all support this new Capability and agree that they can pass 1 bits in the reserved field. However, R2 is older, and it is zeroing out the bits. R3 has direct knowledge that R2 might behave this way, because R3 knows R2 did not announce the new Cap Code. R4, on the other hand, doesn't know if the zeroes it sees in the reserved bits were included intentionally or if R2 erased the information and propagated the routes and attributes anyway. R4 has no idea if the value of a reserved bit is the one applied by the origin router, or if it got lost along the way. I believe any effort to make the reserved bits useful should deal with this problem. Otherwise, no information can be reliably carried in 0 values of reserved bits, because you will not know when the values have been lost. This can be accomplished by mandating that the first reserved bit be set to 1 whenever any of the other three bits are being used to signal information (whether those three bits are 0 or 1.) If R4 sees a 1 in the first reserved bit, it knows it can rely on the information contained in the other three. If not, it knows something has been lost. This seems like a lot of fuss over nothing, since there appears to be no use for these bits; but if the standard is going to be adjusted so they can be used, then IMO the above functionality is important. Certainly any vendor who wishes to propagate these values should agree it is important to know if the value is being carried end-to-end or not! -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From pmohapat@cisco.com Thu Feb 7 21:05:03 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41B21F0D0B for ; Thu, 7 Feb 2013 21:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNfgp-J12X5Q for ; Thu, 7 Feb 2013 21:05:03 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB361F0D0A for ; Thu, 7 Feb 2013 21:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=458; q=dns/txt; s=iport; t=1360299903; x=1361509503; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nDLBxRFqsdURR6/8mAfQRFqlN2IE4kh0VYuodLTXPhk=; b=SmxHzGdYH9GmLuoD3hiH+nw8rzL0gMUUylFLcPVNvUQAHc+1SL18s5vA OuXlm5QfKtnJUgYwPTFC8rx8f+d0X9ZtOhrCTVNRdumBfqj4SeM+moM6X OEWhRKNnD1VHktnpNSwmIKNJyCBiKKm6fJAkHL7jcbwU1f8IANZcGkNOX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJCGFFGtJV2d/2dsb2JhbABFwHIWc4IfAQEBAwE6PxIBCCIUQiUCBAENDYgDBsArkHthA6ZzgwCCJA X-IronPort-AV: E=Sophos;i="4.84,626,1355097600"; d="scan'208";a="174802173" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 08 Feb 2013 05:05:03 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r18552sQ011452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Feb 2013 05:05:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.10]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 7 Feb 2013 23:05:02 -0600 From: "Pradosh Mohapatra (pmohapat)" To: "Stewart Bryant (stbryant)" , RFC Errata System Thread-Topic: [Idr] [Technical Errata Reported] RFC5291 (3468) Thread-Index: AQHOBJt6Jnwe7II0U0GdYv4at+R8b5hvSPGA Date: Fri, 8 Feb 2013 05:05:02 +0000 Message-ID: In-Reply-To: <5112A6F5.9040807@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.21.83.38] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "shares@ndzh.com" , "david@opensourcerouting.org" , "yakov@juniper.net" Subject: Re: [Idr] [Technical Errata Reported] RFC5291 (3468) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 05:05:04 -0000 >> Capability value: one or more of the entries as shown in Figure >>3. I agree this needs clarification/correction in the RFC. Should be similar to the wordings in RFC4760 for multi protocol extensions capability: A speaker that supports multiple tuples includes them as multiple Capabilities in the Capabilities Optional Parameter. This is what the current implementations do (those I'm aware of). - Pradosh From jschiel@flowtools.net Thu Feb 7 23:00:44 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4339121F8814 for ; Thu, 7 Feb 2013 23:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.643 X-Spam-Level: X-Spam-Status: No, score=-0.643 tagged_above=-999 required=5 tests=[AWL=-2.333, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 YTTgAlEFgQpe for ; Thu, 7 Feb 2013 23:00:43 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 30F3721F880F for ; Thu, 7 Feb 2013 23:00:42 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id fr10so3470470lab.12 for ; Thu, 07 Feb 2013 23:00:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=q1CVdDy4HRYQxpKno0KNMH4vkBMbwrM+N0qpVqTiQVM=; b=DmFS29FmllT0Mo93yW0qDgwQL6hw2Br2ET7oYtg27fKzS6fbp8pzLdbgu59lXq0FS9 LZMnl7U7q+imZ9uy/fLD62Q7qUdJ/XaMN2UtYKZtr/uqqjsv9/PUlC74Du3syrbZbqQA Z8gIA5nEEzdQeK7pFFmUwLSsTA7HXG/MUnlTXOXEf66zNsbt+Qn9vhWUDH9jQHDuIeXA ommFS7FoejgnzJSa5rizJGcEAi/3klvJYbHa+iDaG/PTkPdgiaa9+NmYUGaBpimHGZ+c LMI996fopyS+gwF846Cdlh5rv32l3G5KBUEyfj13eQh2kfnaMlIWjIWI0XTid1V218PI /X7w== MIME-Version: 1.0 X-Received: by 10.152.109.176 with SMTP id ht16mr3914314lab.2.1360306841657; Thu, 07 Feb 2013 23:00:41 -0800 (PST) Received: by 10.112.26.163 with HTTP; Thu, 7 Feb 2013 23:00:41 -0800 (PST) X-Originating-IP: [67.40.131.57] In-Reply-To: <007a01ce0569$905ea5f0$b11bf1d0$@ndzh.com> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> <002a01ce055f$33771fc0$9a655f40$@ndzh.com> <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> <005801ce0569$0bc92680$235b7380$@ndzh.com> <007a01ce0569$905ea5f0$b11bf1d0$@ndzh.com> Date: Fri, 8 Feb 2013 00:00:41 -0700 Message-ID: From: John Schiel To: Susan Hares Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkMHjtfJRI1Jv4lrnQgtoGWX8anL0bYiy2vpOt/9+6pTFV6bMfDCqOJVlQcXj+/ILksAs2h Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 07:00:44 -0000 > > Donald > > > Yes. To be precise. > > > > Peer A----Peer-B if both support, then it works. > > Peer-A-peer-B-Peer-c Only if all peers support. > > > > If peering A-B and C . Therefore, If I am B and I want this to work =96 = I > refuse A & C unless flag bit on. > > Therefore, it becomes a configuration issue. Networks can adopt this > configuration flag to assure themselves this bug won=92t happen. > > > > If you want to track this in UPDATEs, then you could use community flags= . > If we want to establish a =93well-known=94 community, it is possible; but= I > would prefer to have actual use dictate that. > I just read Capabilities Advertisement with BGP-4 http://tools.ietf.org/html/rfc5492 and it states the Capability is for an OPEN. If that is true, then an UPDATE could break things and we would be back to where we are today correct? If I understand RFC5492 correctly and what Jeff has proposed, if the Capability is not accepted on an OPEN, then if the peers agree not to use that Capabiity, then the sending router must zero out the bits. Correct? --John > > > Sue > > > > > > > > > > From: Smith, Donald [mailto:Donald.Smith@CenturyLink.com] > Sent: Thursday, February 07, 2013 2:20 PM > To: Susan Hares; 'Jeff Wheeler' > Cc: 'idr wg' > Subject: RE: [Idr] 2 week WG adoption & LC > ondraft-hares-idr-update-attrib-low-bits-fix-00. > > > > This works but only if the announcer is saying "I support the use of thos= e > bits AND all of my peers do" or "I support the use of those bits AND won'= t > propagate to peers that don't support the use of those bits". > > > > Otherwise you support it, I support it but some of my peers don't and whe= n I > advertise those to them unmodified they fail. > > > > Right? > > > > > > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@centurylink.com > > ________________________________ > > From: idr-bounces@ietf.org [idr-bounces@ietf.org] on behalf of Susan Hare= s > [shares@ndzh.com] > Sent: Thursday, February 07, 2013 11:16 AM > To: 'Jeff Wheeler' > Cc: 'idr wg' > Subject: Re: [Idr] 2 week WG adoption & LC > ondraft-hares-idr-update-attrib-low-bits-fix-00. > > Jeff: > > Thank you for the indication of the support of the capability code. > > Sue > > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jef= f > Wheeler > Sent: Tuesday, February 05, 2013 2:21 PM > To: Susan Hares > Cc: idr wg > Subject: Re: [Idr] 2 week WG adoption & LC > ondraft-hares-idr-update-attrib-low-bits-fix-00. > > On Tue, Feb 5, 2013 at 11:15 AM, Susan Hares wrote: >> I will update the draft to the word "change". Are you also a >> supporter of signaling this change with an OPEN option so it can be > negotiated? > > I assume you mean a Capability Code will be used to indicate a receiver's > willingness to accept non-zero reserved Attribute Flags bits. > > I support that idea if it is also standardized that any router announcing > such Capability promises NOT to send non-zero reserved bits, if the BGP > neighbor did not also advertise the Capability. This means that any vend= or > who wants to use the bits can do so safely, and a vendor who wants to > implement that feature will definitely fail-safe if his neighboring route= r > might mis-handle the bits (fail to IGNORE.) > > -- > Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From jsw@inconcepts.biz Fri Feb 8 00:55:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD8C21F84F8 for ; Fri, 8 Feb 2013 00:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 WLcKde4+YV8x for ; Fri, 8 Feb 2013 00:55:18 -0800 (PST) Received: from mail-ie0-x22f.google.com (ie-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 37BEF21F84D5 for ; Fri, 8 Feb 2013 00:55:17 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id c12so4672925ieb.20 for ; Fri, 08 Feb 2013 00:55:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=o5fedPzwHU5gAwqA6PqmEWIHSm6Ly/RaH96tdxxZwUQ=; b=mZjVoaPyasQ2E3MVNsS0V1RdkRJABM3xq8jFEsP+pYt2+iX8M1jfun7P5xUdkTSgqy UK6i2/tiy8INL7ZyW8XXtCgSx/J5ihRlQbRHKaSFesxFeSc3m2CaSLTLUozaIWb5toCP UvafOS84FeW1ZvoZ2cVQ4silyHK3+k+RfVHemNUbMPgW/sudsnrg+tY7G7UQR62yP/NF YE/t2JreBgqMA9XyiwbrPOEQ3eYrS3XJzeVWC8Zt6MyS/tkP5chSyMiPFsebYzYlg1Q+ y2UgFMbVJcGhzUB2LSEFrRtxi8J+zFXEyLgeWtVYcu3sCNghUJnhShaI2McEox4MDGhY 6KQA== MIME-Version: 1.0 X-Received: by 10.50.208.41 with SMTP id mb9mr936626igc.42.1360313717480; Fri, 08 Feb 2013 00:55:17 -0800 (PST) Received: by 10.50.36.4 with HTTP; Fri, 8 Feb 2013 00:55:17 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> <002a01ce055f$33771fc0$9a655f40$@ndzh.com> <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> <005801ce0569$0bc92680$235b7380$@ndzh.com> <007a01ce0569$905ea5f0$b11bf1d0$@ndzh.com> Date: Fri, 8 Feb 2013 03:55:17 -0500 Message-ID: From: Jeff Wheeler To: John Schiel Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQklE8Z41Sh4uqTeJE28XE1FZl8oz+bHP7naxdyA0evoMyOjR1nB98a2JwEXG7RyrS0vVUZ/ Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 08:55:18 -0000 On Fri, Feb 8, 2013 at 2:00 AM, John Schiel wrote: > I just read Capabilities Advertisement with BGP-4 > http://tools.ietf.org/html/rfc5492 and it states the Capability is for > an OPEN. If that is true, then an UPDATE could break things and we > would be back to where we are today correct? The underlying problem is with bits in Path Attributes, which are always carried by UPDATE messages. Capabilities are advertised (negotiated) in OPEN messages because capabilities are established at the beginning of a BGP session, and remain the same throughout the lifetime of that session. For example, if you send Capability 1 and your neighbor also sends Capability 1, then the BGP session supports MP-BGP updates. This means, for example, you can receive MP_REACH_NLRI and MP_UNREACH_NLRI Attributes in UPDATE messages, and they may contain NLRI of IPv6, various VPN AFIs, labeled-unicast next-hops, or whatever. Of course the specific address families supported by an MP-BGP session are further negotiated by data in the capability value. > If I understand RFC5492 correctly and what Jeff has proposed, if the > Capability is not accepted on an OPEN, then if the peers agree not to > use that Capabiity, then the sending router must zero out the bits. > Correct? You've understood my proposal correctly, yes. The underlying issue here is some folks really want a "solution" that allows them to avoid saying their code was at fault for outages that their customers experienced. My idea gives them that solution by couching the "fix" -- them changing their code to begin zeroing out the bits -- in a capability-negotiated feature. The ambiguous language in the base specification for BGP can be left alone and vendors can continue to blame it if customers cry. But they can also say, look, customer, if you upgrade to RainbowOS 13, we have this new "feature" that prevents the problem from happening. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From shares@ndzh.com Fri Feb 8 03:22:28 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2580321F84F5 for ; Fri, 8 Feb 2013 03:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 q53s6JNsoDNf for ; Fri, 8 Feb 2013 03:22:27 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 81E9121F84DA for ; Fri, 8 Feb 2013 03:22:27 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Jeff Wheeler'" , "'John Schiel'" References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> <002a01ce055f$33771fc0$9a655f40$@ndzh.com> <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> <005801ce0569$0bc92680$235b7380$@ndzh.com> <007a01ce0569$905ea5f0$b11bf1d0$@ndzh.com> In-Reply-To: Date: Fri, 8 Feb 2013 06:22:20 -0500 Message-ID: <001f01ce05ee$90173b40$b045b1c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBMhac0XhAnKoHOyYB3aId+E7wFgHJJ7KtAMf02rcB0pPthgHFcHlVAW6OAVoBUTytvAJiFGYcAd5SlwoCPqYz+AHuGxF/AdtrIpABfHBkigEZ7+KdAfzdl4kBeBULeAH89XX5mK+qeAA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 11:22:28 -0000 +1 on this description of problem/solution. Sue -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Jeff Wheeler Sent: Friday, February 08, 2013 3:55 AM To: John Schiel Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. On Fri, Feb 8, 2013 at 2:00 AM, John Schiel wrote: > I just read Capabilities Advertisement with BGP-4 > http://tools.ietf.org/html/rfc5492 and it states the Capability is for > an OPEN. If that is true, then an UPDATE could break things and we > would be back to where we are today correct? The underlying problem is with bits in Path Attributes, which are always carried by UPDATE messages. Capabilities are advertised (negotiated) in OPEN messages because capabilities are established at the beginning of a BGP session, and remain the same throughout the lifetime of that session. For example, if you send Capability 1 and your neighbor also sends Capability 1, then the BGP session supports MP-BGP updates. This means, for example, you can receive MP_REACH_NLRI and MP_UNREACH_NLRI Attributes in UPDATE messages, and they may contain NLRI of IPv6, various VPN AFIs, labeled-unicast next-hops, or whatever. Of course the specific address families supported by an MP-BGP session are further negotiated by data in the capability value. > If I understand RFC5492 correctly and what Jeff has proposed, if the > Capability is not accepted on an OPEN, then if the peers agree not to > use that Capabiity, then the sending router must zero out the bits. > Correct? You've understood my proposal correctly, yes. The underlying issue here is some folks really want a "solution" that allows them to avoid saying their code was at fault for outages that their customers experienced. My idea gives them that solution by couching the "fix" -- them changing their code to begin zeroing out the bits -- in a capability-negotiated feature. The ambiguous language in the base specification for BGP can be left alone and vendors can continue to blame it if customers cry. But they can also say, look, customer, if you upgrade to RainbowOS 13, we have this new "feature" that prevents the problem from happening. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From iesg-secretary@ietf.org Fri Feb 8 10:15:50 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43EE21F8B73; Fri, 8 Feb 2013 10:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 rauqiygEH0ym; Fri, 8 Feb 2013 10:15:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BABC21F8B84; Fri, 8 Feb 2013 10:15:50 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130208181550.25421.43051.idtracker@ietfa.amsl.com> Date: Fri, 08 Feb 2013 10:15:50 -0800 Cc: idr@ietf.org Subject: [Idr] Last Call: (Autonomous System (AS) Reservation for Private Use) to Best Current Practice X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 18:15:51 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Autonomous System (AS) Reservation for Private Use' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-02-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the reservation of Autonomous System numbers (ASNs) that are for Private Use only and MUST NOT be advertised to the Internet, known as Private Use ASNs. This document enlarges the total space available for Private Use ASNs by documenting the reservation of a second, larger range and updates RFC 1930 by replacing Section 10. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-as-private-reservation/ballot/ No IPR declarations have been submitted directly on this I-D. From farmer@umn.edu Fri Feb 8 10:20:27 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3184521F8B9B for ; Fri, 8 Feb 2013 10:20:27 -0800 (PST) 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 0yEEJJU5EdoM for ; Fri, 8 Feb 2013 10:20:26 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 230D521F8B11 for ; Fri, 8 Feb 2013 10:20:26 -0800 (PST) Received: from mail-da0-f71.google.com (mail-da0-f71.google.com [209.85.210.71]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 8 Feb 2013 12:20:15 -0600 (CST) X-Umn-Remote-Mta: [N] mail-da0-f71.google.com [209.85.210.71] #+LO+TR X-Umn-Classification: local Received: by mail-da0-f71.google.com with SMTP id n41so2798314dak.2 for ; Fri, 08 Feb 2013 10:20:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=ZRiXBCYC1eKHqJsrUkxhuWd4zj51YtRSowhAMpzieuQ=; b=fLrWI/LEw3wu135KtQOntUjoTU6S+NcjJFYqLzfDn8eHJn/yZ5l6QgCEuNt+019DY7 GR2sFlivanTLitha5j7PVO4efjgZo2QfWhH/zkLd5BW3/M59NZ19ayZmQjkwvOf5Tjb+ 7G9RXZWG42CpYDf75slJWNHnDSyVRpqtFzqhcpqmG6H0q0RV6akLAJjzFBvIFv/fbxRj K877xEHBLZK1vqNNaGx4E+tFp14YsjPKSMO2Oo4ULK/895kQcHfsTYmDrYYBCXxnmaH0 0X1cSy4L7Sx+Z6OZonQcvuOjvF+yGEfHPrR9xQA+EreXsl/JWnig9s2ku/lsCpB/By68 BgOg== X-Received: by 10.66.80.68 with SMTP id p4mr19632695pax.35.1360347614441; Fri, 08 Feb 2013 10:20:14 -0800 (PST) X-Received: by 10.66.80.68 with SMTP id p4mr19632667pax.35.1360347614298; Fri, 08 Feb 2013 10:20:14 -0800 (PST) Received: from oit201651646.local (mobile-166-137-185-097.mycingular.net. [166.137.185.97]) by mx.google.com with ESMTPS id m3sm56253871pav.4.2013.02.08.10.20.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 10:20:13 -0800 (PST) Message-ID: <511541D9.3060507@umn.edu> Date: Fri, 08 Feb 2013 12:20:09 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jeff Wheeler References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> <002a01ce055f$33771fc0$9a655f40$@ndzh.com> <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> <005801ce0569$0bc92680$235b7380$@ndzh.com> <007a01ce0569$905ea5f0$b11bf1d0$@ndzh.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkcGFHNJ1sCnGwpld6k5hnN+SVMeSsRFw4PAyXeyKI1rJKRdz4pTGPwTZaw/sXhtPD0GV6J8+KkUtTDii0kGuhAmyLDrg3LvVaLcOHrGmf6IgQGndMPJ8aUqA/2gDfewaWK//zx Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 18:20:27 -0000 On 2/8/13 02:55 , Jeff Wheeler wrote: .... > My idea gives them that solution by couching the "fix" -- them > changing their code to begin zeroing out the bits -- in a > capability-negotiated feature. The ambiguous language in the base > specification for BGP can be left alone and vendors can continue to > blame it if customers cry. But they can also say, look, customer, if > you upgrade to RainbowOS 13, we have this new "feature" that prevents > the problem from happening. I'm fine with the capability-negotiation solution you propose, it would basically determine if you "propagate as received" or "propagate as zero". However, one part of the current language should not be left alone. "When received, any value MUST be accepted", should be included as an explicit clarification of the current specification. While the intent of the current language, with regards to how to propagate these bits is ambiguous, I believe "When received, any value MUST be accepted" is implied in the current specification. Making it explicit is a valid clarification that needs to be made, and should be the expected behavior regardless of support for the capability you are proposing. Negotiating if it is safe to "propagate as received" is a change in the spec and more than just a clarification. Making it clear that the expected behavior is "propagate as zero", unless the capability has been negotiated. So, future deployment of any features that requires the use of the currently unused bits would require the new capability being proposed here be widely deployed and support even by implementations that do not directly support the future new feature that would use the bits. Therefore, I believe we should fix this now to allow implementation and deployment of code that can safely allow future use of the unused bits, well before any proposed use of the bits themselves. By the way, what is the status of this draft? I would respectfully suggest that call for WG adoption gained consensus and the WGLC did not, but that not my call. Chairs? Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From brian.peter.dickson@gmail.com Fri Feb 8 10:31:23 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDAE21F8BC9 for ; Fri, 8 Feb 2013 10:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ldz3GHdBDYp for ; Fri, 8 Feb 2013 10:31:14 -0800 (PST) Received: from mail-ie0-x22c.google.com (ie-in-x022c.1e100.net [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id AD9CA21F8BB0 for ; Fri, 8 Feb 2013 10:31:14 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so5455106ieb.31 for ; Fri, 08 Feb 2013 10:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=j6m6b3ZogIkp/OtXpCNq8p6GHW7ePCGsQq/oaK5AJwc=; b=t0htBN8ylcF+VPIsVWWlabMVkVJR6xfMNiC5dpYsMDeMqes/hMAK6tE6uX3qQRQcLg aCQhIt6qm3UgsEYkW2AuxU8TsPGbdpdZbP5/Ydgc0daW0yDNz+HFFfGf+AW2ZipG5n0D W+6/b/PopnLPEu6/8B3v/FYGoE5Hh9qNNlZKzKSlC+Q8O8Zc5I5ChuZB10h8NTx4hmZc FnApN5vnUd79KP/OWXTKw//zl2BNA2vTOf3Zu0mdqJrVrSI3TdS1Rmv28XqsEDXcVrqX s5KETniUzkaDWKfYr5kvuWUs+OQaLnePQhvCJekQPUuDk7NMjHzHjn88LdOtYv+wSp/M rMTg== MIME-Version: 1.0 X-Received: by 10.50.208.68 with SMTP id mc4mr4357520igc.35.1360348274193; Fri, 08 Feb 2013 10:31:14 -0800 (PST) Received: by 10.64.40.234 with HTTP; Fri, 8 Feb 2013 10:31:13 -0800 (PST) In-Reply-To: <511541D9.3060507@umn.edu> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> <002a01ce055f$33771fc0$9a655f40$@ndzh.com> <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> <005801ce0569$0bc92680$235b7380$@ndzh.com> <007a01ce0569$905ea5f0$b11bf1d0$@ndzh.com> <511541D9.3060507@umn.edu> Date: Fri, 8 Feb 2013 13:31:13 -0500 Message-ID: From: Brian Dickson To: David Farmer Content-Type: multipart/alternative; boundary=14dae93408e7a776d704d53ac3ae Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 18:31:23 -0000 --14dae93408e7a776d704d53ac3ae Content-Type: text/plain; charset=ISO-8859-1 +1 (to what David wrote). Brian On Fri, Feb 8, 2013 at 1:20 PM, David Farmer wrote: > On 2/8/13 02:55 , Jeff Wheeler wrote: > .... > > My idea gives them that solution by couching the "fix" -- them >> changing their code to begin zeroing out the bits -- in a >> capability-negotiated feature. The ambiguous language in the base >> specification for BGP can be left alone and vendors can continue to >> blame it if customers cry. But they can also say, look, customer, if >> you upgrade to RainbowOS 13, we have this new "feature" that prevents >> the problem from happening. >> > > I'm fine with the capability-negotiation solution you propose, it would > basically determine if you "propagate as received" or "propagate as zero". > However, one part of the current language should not be left alone. "When > received, any value MUST be accepted", should be included as an explicit > clarification of the current specification. > > While the intent of the current language, with regards to how to propagate > these bits is ambiguous, I believe "When received, any value MUST be > accepted" is implied in the current specification. Making it explicit is a > valid clarification that needs to be made, and should be the expected > behavior regardless of support for the capability you are proposing. > > Negotiating if it is safe to "propagate as received" is a change in the > spec and more than just a clarification. Making it clear that the expected > behavior is "propagate as zero", unless the capability has been negotiated. > > So, future deployment of any features that requires the use of the > currently unused bits would require the new capability being proposed here > be widely deployed and support even by implementations that do not directly > support the future new feature that would use the bits. Therefore, I > believe we should fix this now to allow implementation and deployment of > code that can safely allow future use of the unused bits, well before any > proposed use of the bits themselves. > > By the way, what is the status of this draft? I would respectfully > suggest that call for WG adoption gained consensus and the WGLC did not, > but that not my call. Chairs? > > Thanks. > > > -- > ==============================**================== > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ==============================**================== > ______________________________**_________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/**listinfo/idr > --14dae93408e7a776d704d53ac3ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 (to what David wrote).

Brian

On Fri, Feb 8, 2013 at 1:20 PM, David Farmer &l= t;farmer@umn.edu>= ; wrote:
On 2/8/13 02:55 , Jeff Wheeler wrote:
....

My idea gives them that solution by couching the "fix" -- them changing their code to begin zeroing out the bits -- in a
capability-negotiated feature. =A0The ambiguous language in the base
specification for BGP can be left alone and vendors can continue to
blame it if customers cry. =A0But they can also say, look, customer, if
you upgrade to RainbowOS 13, we have this new "feature" that prev= ents
the problem from happening.

I'm fine with the capability-negotiation solution you propose, it =A0wo= uld basically determine if you "propagate as received" or "p= ropagate as zero". =A0However, one part of the current language should= not be left alone. =A0"When received, any value MUST be accepted"= ;, should be included as an explicit clarification of the current specifica= tion.

While the intent of the current language, with regards to how to propagate = these bits is ambiguous, I believe "When received, any value MUST be a= ccepted" is implied in the current specification. =A0Making it explici= t is a valid clarification that needs to be made, and should be the expecte= d behavior regardless of support for the capability you are proposing.

Negotiating if it is safe to "propagate as received" is a change = in the spec and more than just a clarification. =A0Making it clear that the= expected behavior is "propagate as zero", unless the capability = has been negotiated.

So, future deployment of any features that requires the use of the currentl= y unused bits would require the new capability being proposed here be widel= y deployed and support even by implementations that do not directly support= the future new feature that would use the bits. Therefore, I believe we sh= ould fix this now to allow implementation and deployment of code that can s= afely allow future use of the unused bits, well before any proposed use of = the bits themselves.

By the way, what is the status of this draft? =A0I would respectfully sugge= st that call for WG adoption gained consensus and the WGLC did not, but tha= t not my call. =A0Chairs?

Thanks.


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
David Farmer =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email: farmer@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE =A0 =A0 Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 =A0Cell: 1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--14dae93408e7a776d704d53ac3ae-- From jsw@inconcepts.biz Fri Feb 8 11:23:28 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37EB21F8BEF for ; Fri, 8 Feb 2013 11:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 nTllV5Vm-RNJ for ; Fri, 8 Feb 2013 11:23:26 -0800 (PST) Received: from mail-ia0-x22f.google.com (ia-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 044D121F8BED for ; Fri, 8 Feb 2013 11:23:21 -0800 (PST) Received: by mail-ia0-f175.google.com with SMTP id r4so4523489iaj.6 for ; Fri, 08 Feb 2013 11:23:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=xsorGnzufLEJTbIkxxCCJ4ZuvVxXoX25GfIG7zWYaQ8=; b=jigwJuYkWBg6xNF5PfMNbQQxlV7csEWCB9ZgjpHsy3ItQ/3LCQPiiPtjM5LwZGFj9d g/g3DGiZET9r9vJmu46AceqQNOIc0cJuiYUcLtjstiALlEdzTU4DTFn15HGFOdUYGSVU hE5nUC+8huhSTKj8gdItAXd9OJAf7IkGWMIIrkjD+iqdUJ/Hre9R7183cTR1Ui9wHV+Y PYI4/wwL9nB25Kyh9VKfsnzflqrdJVhLQqZsOdsJcoWqXPZtCjW+nuTIRSaDvStkSVQO 3Zuv0WZmgl82txGMOh/aEdP3+qLHPvquRwj8e4JG2NG8uUMArRFLsY/GmufD3kBOU5oV 4zXg== MIME-Version: 1.0 X-Received: by 10.50.37.236 with SMTP id b12mr2146551igk.42.1360351400624; Fri, 08 Feb 2013 11:23:20 -0800 (PST) Received: by 10.50.36.4 with HTTP; Fri, 8 Feb 2013 11:23:20 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: <511541D9.3060507@umn.edu> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> <002a01ce055f$33771fc0$9a655f40$@ndzh.com> <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> <005801ce0569$0bc92680$235b7380$@ndzh.com> <007a01ce0569$905ea5f0$b11bf1d0$@ndzh.com> <511541D9.3060507@umn.edu> Date: Fri, 8 Feb 2013 14:23:20 -0500 Message-ID: From: Jeff Wheeler To: David Farmer Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnf0qFgBZWasNFsFeYKZCI4LEJIXv0Nvm5r7M7t99/NAoNaHfcLcKxK6fVnB31Cij/aO+h4 Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:23:28 -0000 On Fri, Feb 8, 2013 at 1:20 PM, David Farmer wrote: > While the intent of the current language, with regards to how to propagate > these bits is ambiguous, I believe "When received, any value MUST be > accepted" is implied in the current specification. Making it explicit is a > valid clarification that needs to be made, and should be the expected > behavior regardless of support for the capability you are proposing. I can buy into your suggestion, "When received, any value MUST be accepted." Can that be accomplished using the errata process? > By the way, what is the status of this draft? I would respectfully suggest > that call for WG adoption gained consensus and the WGLC did not, but that > not my call. Chairs? I do not know how the IETF process works. The draft, in its current form, does what I think is the opposite of good. I believe Susan has warmed to my suggestion that a capability should be used, and behavior in absence of this capability from a neighbor must be to zero-out the bits. This seems like a huge departure from its original intent. I really did not know how little understanding there is of this problem by some folks on the list. I have made some slides that may be helpful: http://inconcepts.biz/~jsw/bgp_attrib_flags_problem.pdf Included are diagrams of the BGP Path Attribute header on slides #5 and #6. If you don't have 30 minutes to go through the whole file, just read those slides. The reason I made these is I am absolutely shocked by some of the off-list mail I have got from a couple of people who have posted as if they understand this problem, and they do not know what happened that broke the DFZ, why, etc. Frankly I think if people want to express an opinion about this topic, that is fine, but anyone doing so should spend a little time understanding the problem so they can form an educated opinion! I have received questions about how this problem could be tested or reproduced, what equipment would be needed, etc. and I am happy to answer these questions, but I do not think people that do not already know this should be advocating a position on this matter -- they should first understand the problem so they can decide what their position should be! Just to clear up how to reproduce the problem, by the way (and PLEASE DO NOT DO THIS IN THE DFZ BECAUSE IT WILL BREAK NETWORKS), all you need to do is advertise a route to an older OpenBGPd, Alcatel, or other router that fails to ignore the reserved bits, and instead, closes the BGP session. There is a diagram on slide#6 that shows the structure of the BGP Path Attribute header needed to do this (obviously it can work for any path attribute type, not just Aggregator.) You can advertise such a route trivially by just modifying any open-source BGP speaker or your own company's implementation, or spending 1 hour writing a very basic BGP speaker just for this purpose. Again, please, do not reproduce this problem on the DFZ. If you are going to reproduce this I would suggest your announcement should be an RFC1918 prefix just in case. No kidding, if you send routes out like this today, it will break some very big networks and cost "the Internet" a lot of money, and some vendors will have to endure more wrath from angry customers. If any vendor needs help with test code to reproduce this, I would be happy to assist; but it is so basic, your own programmers can definitely do it. I have provided all the information they need (several times) and now it is in slide-show form. Finally, I really am shocked that people on this list are advocating a position and writing text to modify the BGP specification without understanding this problem, or even its scope. I am not going to forward off-list mails, but these people are advocating a dangerous and foolish modification to BGP without spending some time to understand the problem or the ramifications of own suggestions. This is an irresponsible way to forge policy and it is exactly why the operator community is disdainful of the IETF -- because operators generally think "IETF people" are a bunch of policy hawks who don't understand our problems. Sometimes that belief is right. If anyone thinks they might not understand the issue, please, contact me off-list. Email, phone, smoke signals, whatever. You're going to get my opinion, but you can seek other opinions within your company or from others on this list, and form your own view. At the very least, if you have a discussion about it with me, I assure you that you will have a more thorough understanding of the issue, whether or not you end up agreeing with my opinion about what solutions are most practical. Thanks -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From jsw@inconcepts.biz Fri Feb 8 12:34:08 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D1821F8BD7 for ; Fri, 8 Feb 2013 12:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 Xx2KLrM9AQCa for ; Fri, 8 Feb 2013 12:34:07 -0800 (PST) Received: from mail-ia0-x236.google.com (ia-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 70DD221F8BBD for ; Fri, 8 Feb 2013 12:34:07 -0800 (PST) Received: by mail-ia0-f182.google.com with SMTP id w33so4658522iag.13 for ; Fri, 08 Feb 2013 12:34:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=4diPchitsTlkJh7t6rXBPSJO/w14AQhPNG4lhjCPQ/g=; b=IV+MGg7knyftFftNMm/jWsKYZ4HkRXwwomxlqBvETwyBNMCiKNK+KiniuWRdbtO/ei tYNvStF68SfKblrIQDXHJADjrpQz8do4+LY+QeGTwMyhMNvp+SjeAz6ufxvpVaow3+jX VzvvSGisY6HMDjXuA0AJArbG7+GnqQNvK3ap6W9VgC3aRtdmfuyz8xLEtQm7m6mh3/tU DrkxZVR7tPhiMyYMEWXAyVdbU0aonMpwfjby7MFAth3KSn3dsZ8oOyq0EDRhEUTdwJ/S AXGw2izaq2p+7s54tJMVw0g5Fx6JPZ24KXju/aD/nKWQc/VXfLl0Sc5NkAyHAe39aM9V vW7g== MIME-Version: 1.0 X-Received: by 10.42.82.136 with SMTP id d8mr11275375icl.31.1360355646969; Fri, 08 Feb 2013 12:34:06 -0800 (PST) Received: by 10.50.36.4 with HTTP; Fri, 8 Feb 2013 12:34:06 -0800 (PST) X-Originating-IP: [74.134.22.105] Date: Fri, 8 Feb 2013 15:34:06 -0500 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm6lhZU+NFmDZYC4c+oG5okq954AP9M8rB20fg5U79MmivlS6pfoo1lx3Sh5N11flaxWoVx Subject: [Idr] BGP Attributes Flags problem, Capability solution proposed text X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 20:34:08 -0000 I don't know how you folks normally get this done, but in the interest of moving the process towards the capability solution, I have provided some (very rough) text below. Note that I personally would not support furthering this text without obvious addition of boilerplate material, re-organization / re-wording of some of the below text, etc. I am just posting it to keep things moving in a constructive way. I think this language can be polished to result in an effective technical (and political) solution that most people can probably agree is the best way to solve the problem. Abstract This describes an extension to the BGP-4 [ref] protocol facilitating the use of previously reserved bits in the BGP Path Attributes Flags field of UPDATE messages. These bits may be used to carry information about Path Attributes. Introduction The BGP Path Attributes Flags carry information about their associated attributes. To date, they are used to differentiate between well-known and optional attributes (Optional flag), to specify handling of unrecognized optional attributes (Transitive flag), to indicate end-to-end support for features which utilize particular attributes (Partial flag), and to enable attributes with data longer than 255 octets (Extended Length flag.) Four additional flags bits are reserved and have no standardized use. Implementations vary on their handling of the four reserved bits. Observed behaviors include * zeroing out the bits when propagating them to BGP neighbors * propagating the values unchanged * closing the BGP session if any of these bits are set to 1 * intentionally or accidentally setting one or more bits to 1 This gives rise to several inter-operation problems which are rectified by implementing this extension to BGP-4. These problems are: The bits cannot reliably used today because it is unknown if transit routers are resetting the value of the bits to zero. Some routers close BGP sessions in response to 1 values in these bits. This has resulted in outages to some Internet networks [ref]. Significant confusion exists about the proper procedure for handling these bits. Some vendors strongly disagree about their appropriate handling, and new policy language is needed to resolve these potentially serious inter-op problems. Capability Support for the BGP Path Attributes Flags Extension feature must be negotiated using BGP Capabilities [ref]. An implementation supporting this feature MUST advertise Capability Code TBDcc when establishing BGP sessions to neighbors. It MUST NOT send flags extension bits to neighbors who do not announce support for Capability Code TBDcc. Update to RFC4271 Section 4.3 UPDATE Message Format, Path Attributes section: The low-order four bits of the Attribute Flags octet are redefined by this specification. The three low-order bits are the Attribute Flags Extension Bits. They may be used to carry information about attributes. The fifth bit [diagram needed to avoid confusion] is the Path Attribute Flags Extension Present bit. If any information is contained in the Extension Bits, the value of the Flags Extension Present bit MUST be set to 1. The Attribute Flags Extension Bits, and Extension Present bit, MUST be zeroed-out when sending or propagating attributes to neighbors which do not support the Capability. See updates to RFC4271 Section 5.x for further details. Update to RFC4271 Section 5 Path Attributes New subsection 5.x Path Attribute Flags Extension Bits When a neighboring BGP speaker does not announce the Path Attribute Flags Extension Capability Code, that neighbor is not able to receive extension bit information. The value of the Extension Bits Present bit, and the three extension bits, must be set to 0 when propagating and/or sending attributes to such a neighbor. The Flags Extension Bits, the three low-order bits of the Path Attribute Flags octet, may be utilized to carry additional information about attributes. A BGP-speaker may signal information in these bits provided that the Flags Extension Present bit, (binary nnnn1nnn), is set to 1, indicating to receivers that a value is contained in one or more of the extension bits. When a neighboring BGP speaker announces the Path Attribute Flags Extension Capability Code, that neighbor is able to receive extension bit information. When transmitting messages to such neighbors, the value of the Flags Extension Present bit MUST be set to 1 if any data is carried by the extension bits. The Flags Extension Present bit MUST NOT be reset to zero. When receiving attributes from a neighbor supporting the Capability, if an attribute has any extension bits set to 1, the implementation MUST check the value of the Extension Bits Present bit. If the Present bit is 0, the implementation SHOULD log a diagnostic message including the attribute type code and any NLRI or MP_NLRI [ref] contained in the UPDATE, and MUST treat the attribute as if all the extension bits were 0, and MUST NOT propagate these bits to other BGP neighbors without modification. The implementation is free to make use of the bits, and to transmit such used bits to neighbors supporting the Capability, but if data is carried in the bits, it MUST set the Extension Bits Present bit to 1 when transmitting the attribute to other neighbors. IANA Considerations A BGP Capability Code shall be allocated to indicate support for the BGP Path Attributes Flags Extension feature, defined by this specification. No procedure is defined for allocation of the path attributes flags extension bits at this time. Security Considerations Implementing this specification reduces exposure to a denial-of-service vulnerability that may be present in some BGP networks due to inter-operation problems with use of the BGP Path Attributes Flags reserved bits. No other security implications are known at this time. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From shares@ndzh.com Fri Feb 8 12:39:12 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BD321F8B07 for ; Fri, 8 Feb 2013 12:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.958 X-Spam-Level: X-Spam-Status: No, score=0.958 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 4L2dr5J8Yx6P for ; Fri, 8 Feb 2013 12:39:09 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C629921F8B06 for ; Fri, 8 Feb 2013 12:39:03 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Brian Dickson'" , "'David Farmer'" References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> <000c01ce03bc$0f0bf560$2d23e020$@ndzh.com> <002a01ce055f$33771fc0$9a655f40$@ndzh.com> <68EFACB32CF4464298EA2779B058889D0A2C1015@PDDCWMBXEX503.ctl.intranet> <005801ce0569$0bc92680$235b7380$@ndzh.com> <007a01ce0569$905ea5f0$b11bf1d0$@ndzh.com> <511541D9.3060507@umn.edu> In-Reply-To: Date: Fri, 8 Feb 2013 15:39:00 -0500 Message-ID: <003c01ce063c$53d44df0$fb7ce9d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01CE0612.6B015330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBMhac0XhAnKoHOyYB3aId+E7wFgHJJ7KtAMf02rcB0pPthgHFcHlVAW6OAVoBUTytvAJiFGYcAd5SlwoCPqYz+AHuGxF/AdtrIpABfHBkigEZ7+KdAfzdl4kBeBULeAH89XX5AZ3yVMoCXl89UZiQYiOw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Cc: 'idr wg' Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 20:39:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003D_01CE0612.6B015330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Brian and David: I agree that the WG adoption did work; and the WGLC did not. The authors (being chairs) will respin the draft and send it out for more debate. This author has been gathering lots of public and private debate points. I want to thank everyone for all their comments. I've got a few more private emails to work through prior to releasing a new version of the draft. Then I'll summarize our discussion and post the draft. Thanks for the candid nature of the debate. Sue From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Brian Dickson Sent: Friday, February 08, 2013 1:31 PM To: David Farmer Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. +1 (to what David wrote). Brian On Fri, Feb 8, 2013 at 1:20 PM, David Farmer wrote: On 2/8/13 02:55 , Jeff Wheeler wrote: .... My idea gives them that solution by couching the "fix" -- them changing their code to begin zeroing out the bits -- in a capability-negotiated feature. The ambiguous language in the base specification for BGP can be left alone and vendors can continue to blame it if customers cry. But they can also say, look, customer, if you upgrade to RainbowOS 13, we have this new "feature" that prevents the problem from happening. I'm fine with the capability-negotiation solution you propose, it would basically determine if you "propagate as received" or "propagate as zero". However, one part of the current language should not be left alone. "When received, any value MUST be accepted", should be included as an explicit clarification of the current specification. While the intent of the current language, with regards to how to propagate these bits is ambiguous, I believe "When received, any value MUST be accepted" is implied in the current specification. Making it explicit is a valid clarification that needs to be made, and should be the expected behavior regardless of support for the capability you are proposing. Negotiating if it is safe to "propagate as received" is a change in the spec and more than just a clarification. Making it clear that the expected behavior is "propagate as zero", unless the capability has been negotiated. So, future deployment of any features that requires the use of the currently unused bits would require the new capability being proposed here be widely deployed and support even by implementations that do not directly support the future new feature that would use the bits. Therefore, I believe we should fix this now to allow implementation and deployment of code that can safely allow future use of the unused bits, well before any proposed use of the bits themselves. By the way, what is the status of this draft? I would respectfully suggest that call for WG adoption gained consensus and the WGLC did not, but that not my call. Chairs? Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_003D_01CE0612.6B015330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian and David:

 

I agree that the WG adoption did work; and the WGLC did not. =   

 

The authors (being chairs) will respin the draft and send it out for = more debate.   This author has been gathering lots of public = and private debate points. I want to thank everyone for all their = comments. 

 

I’ve got a few more private emails to work through prior to = releasing a new version of the draft.  Then I’ll summarize = our discussion and post the draft.

 

Thanks for the candid nature of the debate.

 

Sue

 

From:= = idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Brian Dickson
Sent: Friday, February 08, 2013 1:31 = PM
To: David Farmer
Cc: idr wg
Subject: = Re: [Idr] 2 week WG adoption & LC = ondraft-hares-idr-update-attrib-low-bits-fix-00.

 

+1 (to what = David wrote).

 

Brian

On Fri, Feb 8, 2013 at 1:20 PM, David Farmer <farmer@umn.edu> = wrote:

On 2/8/13 02:55 , Jeff Wheeler = wrote:
....

 

My idea = gives them that solution by couching the "fix" -- = them
changing their code to begin zeroing out the bits -- in = a
capability-negotiated feature.  The ambiguous language in the = base
specification for BGP can be left alone and vendors can continue = to
blame it if customers cry.  But they can also say, look, = customer, if
you upgrade to RainbowOS 13, we have this new = "feature" that prevents
the problem from = happening.

 

I'm = fine with the capability-negotiation solution you propose, it =  would basically determine if you "propagate as received" = or "propagate as zero".  However, one part of the current = language should not be left alone.  "When received, any value = MUST be accepted", should be included as an explicit clarification = of the current specification.

While the intent of the current = language, with regards to how to propagate these bits is ambiguous, I = believe "When received, any value MUST be accepted" is implied = in the current specification.  Making it explicit is a valid = clarification that needs to be made, and should be the expected behavior = regardless of support for the capability you are = proposing.

Negotiating if it is safe to "propagate as = received" is a change in the spec and more than just a = clarification.  Making it clear that the expected behavior is = "propagate as zero", unless the capability has been = negotiated.

So, future deployment of any features that requires = the use of the currently unused bits would require the new capability = being proposed here be widely deployed and support even by = implementations that do not directly support the future new feature that = would use the bits. Therefore, I believe we should fix this now to allow = implementation and deployment of code that can safely allow future use = of the unused bits, well before any proposed use of the bits = themselves.

By the way, what is the status of this draft?  I = would respectfully suggest that call for WG adoption gained consensus = and the WGLC did not, but that not my call. =  Chairs?

Thanks.



-- =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
David Farmer               Email: = farmer@umn.edu
Office of Information = Technology
University of Minnesota
2218 University Ave SE   =   Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 =  Cell: 1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

_______________________________________________
Idr = mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

 

------=_NextPart_000_003D_01CE0612.6B015330-- From jsw@inconcepts.biz Fri Feb 8 12:41:07 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7828921F8BD7 for ; Fri, 8 Feb 2013 12:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 tOkE9YSEzpsU for ; Fri, 8 Feb 2013 12:41:07 -0800 (PST) Received: from mail-ie0-x22e.google.com (ie-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F347621F8B8B for ; Fri, 8 Feb 2013 12:41:06 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k10so5573192iea.33 for ; Fri, 08 Feb 2013 12:41:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=Q+5JfjVQSimqv1P/QRX+szNWZkm8Nt57CmOlNtmeTgs=; b=klXIZaP7+eL3lGbDNuuoSYIAZuDilL0TH6rU6u8HHjOJFuKVSR5XibaroEhaNtHY9z SQYpvTLjsdhi6l8Pb9GWeUTwe8vQ4kLm9CXg+Uhh/U+TbLc3Xhp9gIzlPCcj9vofxWrY s6flK9dgXcC2yoYP8rf9R+52d/4kaF7A7g8YaUTneLzkJfSWHBRRGI0RYthjdKoBV6/A wX4m1/WGzmMIKsWMoH5pdS8FZCH5DGWuxt/N1BwxuFtS02/zv7BIKLrOikhgWjP3MbVI l3BTAy51s44lj/l6ixr7Zc6t9/mXHGso7TZ+srqSRTMMeSn+jjMOULZaF4bAcJHpOubA gVfA== MIME-Version: 1.0 X-Received: by 10.50.37.236 with SMTP id b12mr2630474igk.42.1360356061244; Fri, 08 Feb 2013 12:41:01 -0800 (PST) Received: by 10.50.36.4 with HTTP; Fri, 8 Feb 2013 12:41:01 -0800 (PST) X-Originating-IP: [74.134.22.105] In-Reply-To: References: Date: Fri, 8 Feb 2013 15:41:01 -0500 Message-ID: From: Jeff Wheeler To: idr@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlx4UtQis40s8bbhublNA8iNyZma92uwwLU28xB2PEAMxG79dLIBrqYIJi5bn0Pr1rZ22ht Subject: Re: [Idr] BGP Attributes Flags problem, Capability solution proposed text X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 20:41:07 -0000 On Fri, Feb 8, 2013 at 3:34 PM, Jeff Wheeler wrote: > The bits cannot reliably used today because it is unknown if transit > routers are resetting the value of the bits to zero. Also, sorry to respond immediately to my own post, but I want to expand on this particular text and provide a reference. The IP Explicit Congestion Notification (ECN) (RFC3168) bits have this same problem. They were taken from what was originally the Type of Service (ToS) field in the base IPv4 specification. Routers were and still are free to reset these bits to 0 unless they support ECN, in which case, I believe they must not(?) reset them. ECN went through a couple of revisions. The current specification uses two bits, a 1 value in either bit carries information, but a 0 bit does not necessarily carry information. That is because transit routers might reset them to 0. Basically, two bits, which are capable of encoding 4 possible values (00b, 01b, 10b, 11b) are used but they can only reliably carry positive values for two independent conditions (01b or 10b) or three values if used together (01b, 10b, 11b). Any future use of the reserved bits would encounter the same difficulty, because some existing BGP implementations reset them to zero. My proposal solves this by setting aside one of the bits to indicate if any of the other three bits can be relied on. I wanted to provide this reference to ECN because I believe it is an example of a similar problem which had a different solution which was appropriate for ECN's encoding into the ToS field. I do not think the "ECN approach" is needed for these bits in BGP, though. Thanks for reading, -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From jgs@juniper.net Wed Feb 13 10:08:07 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB021F862A for ; Wed, 13 Feb 2013 10:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQ33SFsW3SfL for ; Wed, 13 Feb 2013 10:08:06 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 073ED21F85D2 for ; Wed, 13 Feb 2013 10:08:03 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKURvWguj7T5jUmJy9tIYyKkMYCR6/X7mJ@postini.com; Wed, 13 Feb 2013 10:08:04 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 13 Feb 2013 10:05:49 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 13 Feb 2013 10:05:48 -0800 Received: from CH1EHSOBE007.bigfish.com (216.32.181.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 13 Feb 2013 10:08:30 -0800 Received: from mail115-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Feb 2013 18:05:47 +0000 Received: from mail115-ch1 (localhost [127.0.0.1]) by mail115-ch1-R.bigfish.com (Postfix) with ESMTP id BCA3036004F for ; Wed, 13 Feb 2013 18:05:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.238.5; KIP:(null); UIP:(null); (null); H:BY2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -3 X-BigFish: PS-3(zzc85fh1519M4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1155h) Received: from mail115-ch1 (localhost.localdomain [127.0.0.1]) by mail115-ch1 (MessageSwitch) id 1360778745798509_22421; Wed, 13 Feb 2013 18:05:45 +0000 (UTC) Received: from CH1EHSMHS027.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail115-ch1.bigfish.com (Postfix) with ESMTP id B7C173006B7 for ; Wed, 13 Feb 2013 18:05:45 +0000 (UTC) Received: from BY2PRD0512HT001.namprd05.prod.outlook.com (157.56.238.5) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Feb 2013 18:05:45 +0000 Received: from ricardod-sslvpn-nc.jnpr.net (66.129.232.2) by pod51010.outlook.com (10.255.243.34) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 13 Feb 2013 18:05:42 +0000 From: John Scudder Content-Type: multipart/alternative; boundary="Apple-Mail=_9A3A399E-7D4B-46AE-9A49-6C22C4C9705C" Message-ID: Date: Wed, 13 Feb 2013 13:05:39 -0500 To: "idr@ietf.org List" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.232.2] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Idr] IETF-86 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 18:08:07 -0000 --Apple-Mail=_9A3A399E-7D4B-46AE-9A49-6C22C4C9705C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Folks, We're planning to meet at IETF-86 on Wednesday, March 13 from 9:00 to = 11:30. Please forward any IDR agenda items you might have to Sue and = myself. The deadline is February 26 by 13:00 U.S. Eastern Time, = although earlier is better. Given the tardiness of this announcement = we'll work to accommodate those who need additional time, but priority = will still be given to those who get their requests in before the = deadline. If you have previously presented on your topic at an IDR meeting, please = explain in your request what you hope to achieve with your presentation = this time. If you plan to make a presentation, please keep in mind the IDR = tradition, "no Internet Draft - no time slot". You should also plan to = send your slides to Sue and me no later than 24 hours prior to the = meeting, though again, earlier is better. Finally, if you request an agenda slot, please do so by replying to this = message and don't change the subject line. Thanks, --John & Sue --Apple-Mail=_9A3A399E-7D4B-46AE-9A49-6C22C4C9705C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Finally, if you request an agenda slot, please = do so by replying to this message and don't change the subject = line.

Thanks,

--John & Sue
= --Apple-Mail=_9A3A399E-7D4B-46AE-9A49-6C22C4C9705C-- From jgs@juniper.net Fri Feb 15 13:26:18 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3DAC21F865B for ; Fri, 15 Feb 2013 13:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnMEpUMRSCNz for ; Fri, 15 Feb 2013 13:26:17 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 940AA21F8644 for ; Fri, 15 Feb 2013 13:26:17 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUR6n+RRb9ATt0nWtIWHUoykkQelXjjxv@postini.com; Fri, 15 Feb 2013 13:26:17 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 15 Feb 2013 13:25:45 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 15 Feb 2013 13:25:44 -0800 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.209) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 15 Feb 2013 13:34:26 -0800 Received: from mail47-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Feb 2013 21:25:42 +0000 Received: from mail47-am1 (localhost [127.0.0.1]) by mail47-am1-R.bigfish.com (Postfix) with ESMTP id 98102440136 for ; Fri, 15 Feb 2013 21:25:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 2 X-BigFish: PS2(zzc85fh4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzzz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1155h) Received: from mail47-am1 (localhost.localdomain [127.0.0.1]) by mail47-am1 (MessageSwitch) id 1360963540471149_22267; Fri, 15 Feb 2013 21:25:40 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.234]) by mail47-am1.bigfish.com (Postfix) with ESMTP id 70F8A20051 for ; Fri, 15 Feb 2013 21:25:40 +0000 (UTC) Received: from BN1PRD0512HT002.namprd05.prod.outlook.com (132.245.2.21) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Feb 2013 21:25:39 +0000 Received: from [IPv6:::1] (66.129.224.36) by pod51010.outlook.com (10.255.193.35) with Microsoft SMTP Server (TLS) id 14.16.263.1; Fri, 15 Feb 2013 21:25:37 +0000 From: John Scudder Content-Type: multipart/alternative; boundary="Apple-Mail=_EAB1C1A5-4CCC-4226-973C-1D9A4D74B8D1" Message-ID: <3BD8D5C8-77D5-40C6-8BC2-B8B839463544@juniper.net> Date: Fri, 15 Feb 2013 16:25:33 -0500 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 21:26:18 -0000 --Apple-Mail=_EAB1C1A5-4CCC-4226-973C-1D9A4D74B8D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Folks, The authors have requested IDR adopt = draft-simpson-idr-flowspec-redirect-02 as a working group document. Please send any comments to the list by March 1. Thanks, --John & Sue --Apple-Mail=_EAB1C1A5-4CCC-4226-973C-1D9A4D74B8D1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii" Folks,

The authors have requested IDR adopt draft-simpson-idr-flowspec-redirect-02 as a working group document.

Please send any comments to the list by March 1.

Thanks,

--John & Sue
--Apple-Mail=_EAB1C1A5-4CCC-4226-973C-1D9A4D74B8D1-- From jgs@juniper.net Fri Feb 15 13:28:30 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21AD21E8039 for ; Fri, 15 Feb 2013 13:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU9zt9XH4EWM for ; Fri, 15 Feb 2013 13:28:30 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 3D07921F869A for ; Fri, 15 Feb 2013 13:28:30 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUR6ofoxTGnTOL+/MtSKQivRHdcl9raru@postini.com; Fri, 15 Feb 2013 13:28:30 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 15 Feb 2013 13:27:53 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 15 Feb 2013 13:27:52 -0800 Received: from CO9EHSOBE016.bigfish.com (207.46.163.24) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 15 Feb 2013 13:30:29 -0800 Received: from mail74-co9-R.bigfish.com (10.236.132.243) by CO9EHSOBE016.bigfish.com (10.236.130.79) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Feb 2013 21:27:52 +0000 Received: from mail74-co9 (localhost [127.0.0.1]) by mail74-co9-R.bigfish.com (Postfix) with ESMTP id E814426022C for ; Fri, 15 Feb 2013 21:27:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -18 X-BigFish: PS-18(zzc85fh4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275dhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1155h) Received: from mail74-co9 (localhost.localdomain [127.0.0.1]) by mail74-co9 (MessageSwitch) id 1360963669347703_21862; Fri, 15 Feb 2013 21:27:49 +0000 (UTC) Received: from CO9EHSMHS013.bigfish.com (unknown [10.236.132.226]) by mail74-co9.bigfish.com (Postfix) with ESMTP id 52D424E0059 for ; Fri, 15 Feb 2013 21:27:49 +0000 (UTC) Received: from BN1PRD0512HT002.namprd05.prod.outlook.com (132.245.2.21) by CO9EHSMHS013.bigfish.com (10.236.130.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Feb 2013 21:27:49 +0000 Received: from [IPv6:::1] (66.129.224.36) by pod51010.outlook.com (10.255.193.35) with Microsoft SMTP Server (TLS) id 14.16.263.1; Fri, 15 Feb 2013 21:27:47 +0000 From: John Scudder Content-Type: multipart/alternative; boundary="Apple-Mail=_01BDA5D1-342C-4369-8030-341A1DA95396" Message-ID: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> Date: Fri, 15 Feb 2013 16:27:44 -0500 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.224.36] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 21:28:30 -0000 --Apple-Mail=_01BDA5D1-342C-4369-8030-341A1DA95396 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Folks, We have received a request for a working group last call on = draft-ietf-idr-rfd-usable-01. A URL for the draft is = http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-01 Please send comments to the list by March 1. Thanks, --John & Sue --Apple-Mail=_01BDA5D1-342C-4369-8030-341A1DA95396 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii" Folks,

We have received a request for a working group last call on draft-ietf-idr-rfd-usable-01. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-01

Please send comments to the list by March 1.

Thanks,

--John & Sue
--Apple-Mail=_01BDA5D1-342C-4369-8030-341A1DA95396-- From bduvivie@cisco.com Fri Feb 15 17:12:13 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B9D21F855D for ; Fri, 15 Feb 2013 17:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42o2ErxBOcId for ; Fri, 15 Feb 2013 17:12:12 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 649AB21F855C for ; Fri, 15 Feb 2013 17:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=469; q=dns/txt; s=iport; t=1360977132; x=1362186732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=s+Qm9Ke9ejBHRwPnnslFGiqIz5M5WCfEvVlZHDxEJDY=; b=kYLWH5P4TlWeKGYcG8T50k8Fg9pMIptDouCPj6NlMdAXz3If8gqC+59+ mMNzXvP10wCejREObThfx0hXEzcklc0d21tAdn4WO/eg2hBiRCJQgXduu 1nrroxEEycRJaarEy5StmhUcboMyDfJWTT5wkQ5PtZtzWJketNrQFiUa2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAIrbHlGtJV2Z/2dsb2JhbABEhgK6EX0Wc4IfAQEBAwEBAQE3NAsFCwIBCA4oECcLJQIEDgWIDAYMvUUEjngzB4JfYQOWKJBVgwc X-IronPort-AV: E=Sophos;i="4.84,676,1355097600"; d="scan'208";a="177796012" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 16 Feb 2013 01:12:12 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1G1CB7h029237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 16 Feb 2013 01:12:12 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 19:12:11 -0600 From: "Bertrand Duvivier (bduvivie)" To: John Scudder Thread-Topic: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 Thread-Index: AQHOC8McBW6TNWUULEyXBxsNI13NuJh8Dm6A Date: Sat, 16 Feb 2013 01:12:11 +0000 Message-ID: <64DB401C-96D9-43BB-99D6-36D25F6B0DBD@cisco.com> References: <3BD8D5C8-77D5-40C6-8BC2-B8B839463544@juniper.net> In-Reply-To: <3BD8D5C8-77D5-40C6-8BC2-B8B839463544@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <87C4AA0CA28D7A41B5D1442ECF4CCA52@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 01:12:13 -0000 Make sense to me Sent from iPAD On Feb 15, 2013, at 10:26 PM, "John Scudder" wrote: > Folks, >=20 > The authors have requested IDR adopt draft-simpson-idr-flowspec-redirect-= 02 as a working group document. >=20 > Please send any comments to the list by March 1. >=20 > Thanks, >=20 > --John & Sue > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From jgs@juniper.net Fri Feb 15 17:36:52 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE5A21F8570 for ; Fri, 15 Feb 2013 17:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.067 X-Spam-Level: X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83tXHQm+-UoM for ; Fri, 15 Feb 2013 17:36:51 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id A678A21F852B for ; Fri, 15 Feb 2013 17:36:51 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUR7isHT6Qr2j5ih+j4S8wgsZNXq052bo@postini.com; Fri, 15 Feb 2013 17:36:51 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 15 Feb 2013 17:36:09 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 15 Feb 2013 17:36:08 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 15 Feb 2013 17:38:45 -0800 Received: from mail9-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.23; Sat, 16 Feb 2013 01:36:08 +0000 Received: from mail9-tx2 (localhost [127.0.0.1]) by mail9-tx2-R.bigfish.com (Postfix) with ESMTP id D4D1B34030C for ; Sat, 16 Feb 2013 01:36:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 0 X-BigFish: PS0(zzdb82h98dI9371I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz8275fhz2dh2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1155h) Received: from mail9-tx2 (localhost.localdomain [127.0.0.1]) by mail9-tx2 (MessageSwitch) id 1360978566178040_12149; Sat, 16 Feb 2013 01:36:06 +0000 (UTC) Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.249]) by mail9-tx2.bigfish.com (Postfix) with ESMTP id 285E9C0051; Sat, 16 Feb 2013 01:36:06 +0000 (UTC) Received: from BL2PRD0512HT003.namprd05.prod.outlook.com (157.56.242.197) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 16 Feb 2013 01:36:02 +0000 Received: from [IPv6:::1] (66.129.224.52) by pod51010.outlook.com (10.255.233.36) with Microsoft SMTP Server (TLS) id 14.16.263.1; Sat, 16 Feb 2013 01:36:02 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "John G. Scudder" In-Reply-To: Date: Fri, 15 Feb 2013 20:35:58 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <155C1AC2-95A7-4C7E-ACB8-C8F39A4B5FBE@juniper.net> References: <001c01cded0d$91df4a20$b59dde60$@ndzh.com> <20130107202228.GD47093@verdi> <00fa01cdedb6$64f94160$4001a8c0@gateway.2wire.net> <50EC770C.40603@umn.edu> <7A7C19B9-2416-4B7E-B671-AFDCFDD56F85@ericsson.com> <5106E0AA.6090402@umn.edu> <5107264A.2020501@umn.edu> To: Jeff Wheeler X-Mailer: Apple Mail (2.1499) X-Originating-IP: [66.129.224.52] X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%INCONCEPTS.BIZ$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: idr wg Subject: Re: [Idr] 2 week WG adoption & LC ondraft-hares-idr-update-attrib-low-bits-fix-00. X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 01:36:52 -0000 Sorry to reply to this so late: On Feb 5, 2013, at 7:40 AM, Jeff Wheeler wrote: > The entire goal of the proposal seems to be to allow Juniper to avoid > repairing a bug or even admitting that they have a bug This was not the goal, regardless of how it seemed to you. I won't reply = individually to any of your other notes making similar claims, but the = same applies to them. I see that the conversation has gone down more constructive paths = subsequently. I appreciate that and won't belabor the point further but = will instead focus on contributing to the actual work. Let's get the = protocol right, where the meaning of "right" is the result of a fuzzy = multi-variable calculation and debate, but not one that includes saving = face (for my employer or anyone else's) as an input.=20 Thanks, --John From danny@tcb.net Sun Feb 17 06:29:53 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D682D21F8845 for ; Sun, 17 Feb 2013 06:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.472 X-Spam-Level: X-Spam-Status: No, score=-100.472 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, 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 t1aRaVwBegLo for ; Sun, 17 Feb 2013 06:29:53 -0800 (PST) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7995C21F8716 for ; Sun, 17 Feb 2013 06:29:53 -0800 (PST) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id BA859300025 for ; Sun, 17 Feb 2013 14:29:52 +0000 (UTC) Received: from dul1dmcphers-m2.home (pool-71-171-117-166.clppva.fios.verizon.net [71.171.117.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 2F18730000E; Sun, 17 Feb 2013 07:29:52 -0700 (MST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Danny McPherson In-Reply-To: <3BD8D5C8-77D5-40C6-8BC2-B8B839463544@juniper.net> Date: Sun, 17 Feb 2013 09:29:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5492B727-611E-4F9C-BAFF-1FCA2891B820@tcb.net> References: <3BD8D5C8-77D5-40C6-8BC2-B8B839463544@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1499) X-DSPAM-Result: Innocent X-DSPAM-Processed: Sun Feb 17 07:29:52 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 5120e96042078765316248 X-DSPAM-Factors: 27, 2013+at, 0.40000, idr+#+#+#+as, 0.40000, Feb+#+2013, 0.40000, To*Scudder+jgs, 0.40000, will+#+on, 0.40000, Subject*requested+#+draft-simpson-idr-flowspec-redirect-02, 0.40000, any+comments, 0.40000, authors+#+#+IDR, 0.40000, Subject*WG+#+#+for, 0.40000, Please+#+#+#+to, 0.40000, Mime-Version*OS+X, 0.40000, a+#+group, 0.40000, 2013+#+#+25, 0.40000, working+group, 0.40000, flowspec+#+#+#+a, 0.40000, 02+#+a, 0.40000, list+#+#+1, 0.40000, Subject*Re+#+#+adoption, 0.40000, have+requested, 0.40000, send+#+#+to, 0.40000, comment+on, 0.40000, group+#+#+#+any, 0.40000, Subject*for+draft-simpson-idr-flowspec-redirect-02, 0.40000, juniper+#+#+#+The, 0.40000, Feb+#+#+#+4, 0.40000, send+any, 0.40000, draft+#+#+#+redirect, 0.40000 Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 14:29:54 -0000 On Feb 15, 2013, at 4:25 PM, John Scudder wrote: > Folks, >=20 > The authors have requested IDR adopt = draft-simpson-idr-flowspec-redirect-02 as a working group document. >=20 > Please send any comments to the list by March 1. Support and will comment on WG version.. -danny From warren@kumari.net Mon Feb 18 10:19:57 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9C521F88A3 for ; Mon, 18 Feb 2013 10:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 mciAcFS69lmz for ; Mon, 18 Feb 2013 10:19:57 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9F721F8890 for ; Mon, 18 Feb 2013 10:19:56 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 1B1A01B41869; Mon, 18 Feb 2013 13:19:56 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> Date: Mon, 18 Feb 2013 13:19:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <468491B1-9898-4ECE-B2FF-9B39C2204E99@kumari.net> References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1499) Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:19:57 -0000 On Feb 15, 2013, at 4:27 PM, John Scudder wrote: > Folks, >=20 > We have received a request for a working group last call on = draft-ietf-idr-rfd-usable-01. A URL for the draft is = http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-01 Support. W >=20 > Please send comments to the list by March 1. >=20 > Thanks, >=20 > --John & Sue > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- It's a mistake trying to cheer up camels. You might as well drop = meringues into a black hole. -- Terry Prachett From shtsuchi@cisco.com Mon Feb 18 18:18:37 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E28C21E8099 for ; Mon, 18 Feb 2013 18:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, 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 I7vmpDuTQZkL for ; Mon, 18 Feb 2013 18:18:36 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF2721E8053 for ; Mon, 18 Feb 2013 18:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=707; q=dns/txt; s=iport; t=1361240316; x=1362449916; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=bpJx+utUysQzc04U76Gxuds9dHO/hlwFOzh9O3J0hu0=; b=IwWjwu/zhr6oHWA8tTCCIGEuGJJts78v0Izd+T7P8WhuCBXeI7hrLFPM TDILS6gNBQkdXvMDaoOO4s9nq4y0J+mNkmY+ehIkhbu+DzqVz316Q5+zw xninONe9XroKNIkU4DVTwkmmu7EMZLkS1xM6XNdtpXMz7+h4UWm++xdLS 8=; X-IronPort-AV: E=Sophos;i="4.84,692,1355097600"; d="scan'208";a="25654390" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 19 Feb 2013 02:18:30 +0000 Received: from [10.141.43.157] (dhcp-10-141-43-157.cisco.com [10.141.43.157]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1J2ITrp007313; Tue, 19 Feb 2013 02:18:30 GMT Message-ID: <5122E0F5.1010803@cisco.com> Date: Tue, 19 Feb 2013 11:18:29 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: jgs@juniper.net References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> In-Reply-To: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 02:18:37 -0000 Support publish this draft as RFC. One question,RIPE already published "Recommendations on Route Flap Damping" as ripe-580. http://www.ripe.net/ripe/docs/ripe-580 RIPE580 will be pointed as References on this draft? Regards, -Shishio (2013/02/16 6:27), John Scudder wrote: > Folks, > > We have received a request for a working group last call on draft-ietf-idr-rfd-usable-01. A URL for the draft is http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-01 > > Please send comments to the list by March 1. > > Thanks, > > --John & Sue > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From christopher.morrow@gmail.com Mon Feb 18 19:03:35 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777F021E80BB for ; Mon, 18 Feb 2013 19:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 Ld94mUXbO03V for ; Mon, 18 Feb 2013 19:03:35 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id B2C1621E804B for ; Mon, 18 Feb 2013 19:03:34 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id m4so4778084lbo.0 for ; Mon, 18 Feb 2013 19:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XJUGu7hDNucW02tIQ5ikN52FCXyURUFOllfB4QUd6/w=; b=kXkQ6ky7eSLUJLh5VP1aAkD3vPupaOlEC4jCgQSor6p5rqeD1Uk9THJf4uVkkmcrZv KhQRE4o3voGO+fEsHPpeS4CaYTVFHXXDwyNyYf5u7wKdoAL0oe6ZGThYlp3j3RBNa9hg Uvowfb4CY78xbWkoZm/YfwpSMBv1XKZs+s/EhJRsD+zfcFMdBlKmkteJYbWLpprN5RXA NpyIB1byu0DbDtqCNO/obReE9BQ23/94MTAGCFJ7geVuHc1P+IsdFNOVetnoSIiepWzR iM9U3Iy4x7J2oyIIXUnFk/QOqkJ8Gv0Bt+DMBcGOjQJc+Yg587GkZebWN59BkpB78j0C HHXw== MIME-Version: 1.0 X-Received: by 10.112.45.165 with SMTP id o5mr6560308lbm.67.1361243013485; Mon, 18 Feb 2013 19:03:33 -0800 (PST) Sender: christopher.morrow@gmail.com Received: by 10.152.27.163 with HTTP; Mon, 18 Feb 2013 19:03:33 -0800 (PST) In-Reply-To: <5122E0F5.1010803@cisco.com> References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> <5122E0F5.1010803@cisco.com> Date: Mon, 18 Feb 2013 22:03:33 -0500 X-Google-Sender-Auth: m6qcF1qoi9K683qt5wGaBWRs4ik Message-ID: From: Christopher Morrow To: Shishio Tsuchiya Content-Type: text/plain; charset=ISO-8859-1 Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 03:03:35 -0000 On Mon, Feb 18, 2013 at 9:18 PM, Shishio Tsuchiya wrote: > Support publish this draft as RFC. I do as well, thanks to the authors and wg for the work. From kawamucho@mesh.ad.jp Mon Feb 18 19:38:23 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F195321F8B69 for ; Mon, 18 Feb 2013 19:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 srg5MVpo8StS for ; Mon, 18 Feb 2013 19:38:22 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [210.143.35.51]) by ietfa.amsl.com (Postfix) with ESMTP id 762E221E8040 for ; Mon, 18 Feb 2013 19:38:13 -0800 (PST) Received: from mailgate3.nec.co.jp ([10.7.69.197]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id r1J3c8lS007411; Tue, 19 Feb 2013 12:38:08 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id r1J3c8G12501; Tue, 19 Feb 2013 12:38:08 +0900 (JST) Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id r1J3c7sv009221; Tue, 19 Feb 2013 12:38:07 +0900 (JST) Received: from mail.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id r1J3c7gY018563; Tue, 19 Feb 2013 12:38:07 +0900 Received: from [127.0.0.1] (osknet452.sys.biglobe.nec.co.jp [10.84.99.49]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/10031711) with ESMTP id r1J3c74v028180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2013 12:38:07 +0900 Message-ID: <5122F39D.2060406@mesh.ad.jp> Date: Tue, 19 Feb 2013 12:38:05 +0900 From: Seiichi Kawamura User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Christopher Morrow References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> <5122E0F5.1010803@cisco.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2MTGNJJITTENMHGDOPXRQ" Cc: idr@ietf.org Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 03:38:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2MTGNJJITTENMHGDOPXRQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I do support as well, hoping that the feature will be of some use in my network. Seiichi (2013/02/19 12:03), Christopher Morrow wrote: > On Mon, Feb 18, 2013 at 9:18 PM, Shishio Tsuchiya = wrote: >> Support publish this draft as RFC. >=20 > I do as well, thanks to the authors and wg for the work. > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr >=20 ------enig2MTGNJJITTENMHGDOPXRQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iEYEARECAAYFAlEi858ACgkQcrhTYfxyMkJrgQCfY7wP8HZpL845jcynB5aqVXuP wNQAn2almnUhFZvGhYW/6FRPF91gBfsg =fLYI -----END PGP SIGNATURE----- ------enig2MTGNJJITTENMHGDOPXRQ-- From warren@kumari.net Tue Feb 19 14:44:24 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A585221F8790 for ; Tue, 19 Feb 2013 14:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, 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 6fPSuvgdg329 for ; Tue, 19 Feb 2013 14:44:23 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CE721F88A2 for ; Tue, 19 Feb 2013 14:44:23 -0800 (PST) Received: from [192.168.1.145] (unknown [66.84.81.126]) by vimes.kumari.net (Postfix) with ESMTPSA id 7299C1B4115F; Tue, 19 Feb 2013 17:44:21 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Warren Kumari In-Reply-To: <3BD8D5C8-77D5-40C6-8BC2-B8B839463544@juniper.net> Date: Tue, 19 Feb 2013 17:44:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3BD8D5C8-77D5-40C6-8BC2-B8B839463544@juniper.net> To: John Scudder X-Mailer: Apple Mail (2.1499) Cc: "idr@ietf. org" Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:44:24 -0000 On Feb 15, 2013, at 4:25 PM, John Scudder wrote: > Folks, >=20 > The authors have requested IDR adopt = draft-simpson-idr-flowspec-redirect-02 as a working group document. I support (and will review / comment / etc) W >=20 > Please send any comments to the list by March 1. >=20 > Thanks, >=20 > --John & Sue > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr -- "When it comes to glittering objects, wizards have all the taste and = self-control of a deranged magpie." -- Terry Pratchett From iesg-secretary@ietf.org Thu Feb 21 11:08:32 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1442021F8931; Thu, 21 Feb 2013 11:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 dp0X1jAjehFP; Thu, 21 Feb 2013 11:08:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17B621F87DC; Thu, 21 Feb 2013 11:08:31 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130221190831.2299.79158.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2013 11:08:31 -0800 Cc: idr@ietf.org Subject: [Idr] Last Call: (Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:08:32 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document requests IANA to deprecate the BGP path attributes DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet Draft and a Historic RFC, respectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-dpa-etal/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-dpa-etal/ballot/ No IPR declarations have been submitted directly on this I-D. This document was previously Last Called as Informational. However it deprecates codepoints that were created by Standards Track documents. It is therefore being re Last Called as a Proposed Standard. The text change to PS is provided via an RFC Editor Note in the tracker. From iesg-secretary@ietf.org Thu Feb 21 11:08:32 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454C921F8C48 for ; Thu, 21 Feb 2013 11:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 UtQKTjtcOOjJ; Thu, 21 Feb 2013 11:08:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB8C21F886A; Thu, 21 Feb 2013 11:08:31 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-idr-deprecate-dpa-etal X-IETF-Draft-revision: 00 Message-ID: <20130221190831.2299.85304.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2013 11:08:31 -0800 Cc: idr@ietf.org Subject: [Idr] Last Call: (Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:08:32 -0000 The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document requests IANA to deprecate the BGP path attributes DPA, ADVERTISER, and RCID_PATH / CLUSTER_ID, associated with an abandoned Internet Draft and a Historic RFC, respectively. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-dpa-etal/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-dpa-etal/ballot/ No IPR declarations have been submitted directly on this I-D. This document was previously Last Called as Informational. However it deprecates codepoints that were created by Standards Track documents. It is therefore being re Last Called as a Proposed Standard. The text change to PS is provided via an RFC Editor Note in the tracker. From randy@psg.com Thu Feb 21 13:08:38 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A1721F88E2; Thu, 21 Feb 2013 13:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.595 X-Spam-Level: X-Spam-Status: No, score=-2.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 DR38Dzzx7ypo; Thu, 21 Feb 2013 13:08:38 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 59B7521F87DC; Thu, 21 Feb 2013 13:08:38 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U8dNd-0007Y9-Jr; Thu, 21 Feb 2013 21:08:37 +0000 Date: Fri, 22 Feb 2013 06:08:36 +0900 Message-ID: From: Randy Bush To: The IESG In-Reply-To: <20130221190831.2299.79158.idtracker@ietfa.amsl.com> References: <20130221190831.2299.79158.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: idr wg Subject: Re: [Idr] Last Call: (Deprecation of BGP Path Attributes DPA, ADVERTISER and RCID_PATH / CLUSTER_ID) to Proposed Standard X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 21:08:38 -0000 i support this draft being moved forward. randy From bvenkata@cisco.com Thu Feb 21 15:32:21 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F16621E803D for ; Thu, 21 Feb 2013 15:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JQXzBndyFit for ; Thu, 21 Feb 2013 15:32:20 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8636621E8039 for ; Thu, 21 Feb 2013 15:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4248; q=dns/txt; s=iport; t=1361489540; x=1362699140; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=aU7TLLpIKUNxMB6iwHK8BAYZYZ9P0smMV5r/ayCFSO4=; b=ePPg5UmD9hlF+oswwrrELfxUkoVJUwOnz6FIKLjpSBbqXwJ5zfdR4ioD 9BILmS2YAFluWTUbPfl6AbFbfpBzb7N7OOmaFy9ti9odUBQIcY2PqTpGp 8zq9PNkg/Zup2ImcTh3skxuwooQ4F0UmsTUupcBHHkFNfGSr8pXKgjqhK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFALmtJlGtJV2Z/2dsb2JhbABFgkODRLJrAYgggQYWc4IfAQEBBC1cAgEIDgMEAQELHQcyFAkIAgQBEgiICgy/II5dJhEBgl9hA5dTj0GDB4In X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208,217";a="179835043" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 21 Feb 2013 23:32:20 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1LNWK6D002722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 23:32:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 17:32:19 -0600 From: "Balaji Pitta Venkatachalapathy (bvenkata)" To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Thread-Index: AQHOC8Nro8QV3BKqaEWUKFjEheMA4piE/6LQ Date: Thu, 21 Feb 2013 23:32:19 +0000 Message-ID: References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> In-Reply-To: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.208.174] Content-Type: multipart/alternative; boundary="_000_AFC24BD7A229264C88C0C9FFA49749340FDD6713xmbrcdx09ciscoc_" MIME-Version: 1.0 Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 23:32:21 -0000 --_000_AFC24BD7A229264C88C0C9FFA49749340FDD6713xmbrcdx09ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Balaji From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John = Scudder Sent: Friday, February 15, 2013 1:28 PM To: idr@ietf. org Subject: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Folks, We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://tools.ietf.org/html/draft-ietf= -idr-rfd-usable-01 Please send comments to the list by March 1. Thanks, --John & Sue --_000_AFC24BD7A229264C88C0C9FFA49749340FDD6713xmbrcdx09ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support=

 <= /p>

Balaji<= /p>

 <= /p>

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder
Sent: Friday, February 15, 2013 1:28 PM
To: idr@ietf. org
Subject: [Idr] WGLC on draft-ietf-idr-rfd-usable-01

 

Folks,

We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://= tools.ietf.org/html/draft-ietf-idr-rfd-usable-01

Please send comments to the list by March 1.


Thanks,

--John & Sue

--_000_AFC24BD7A229264C88C0C9FFA49749340FDD6713xmbrcdx09ciscoc_-- From seyilmaz@cisco.com Thu Feb 21 15:53:09 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4DC21E8044 for ; Thu, 21 Feb 2013 15:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYolZ-S90tDj for ; Thu, 21 Feb 2013 15:53:09 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D072C21E803D for ; Thu, 21 Feb 2013 15:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6484; q=dns/txt; s=iport; t=1361490789; x=1362700389; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=f1e3YTZWDfKU5di5jXPozg0gK/OtUyhhnFg/3ZM9j8E=; b=JmJvx0q3F+oCdvKKkNvXNbVbQ8AM8/ng2/XccozoUHrWUk5wLUZ8S8tH kcrOT7A6+VaELEasleupBQfX8eeJwFP6A/JJ/DP9LUNfAWfmjT0Ly5Ho6 2DJq+ushPDJ3u+TxTQ/gqhG+kGPQpNp8OWgA1m9xuseeOK+NQWNyZwJgo M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAP6wJlGtJXG8/2dsb2JhbABFgkMjtgsBiCCBBhZzgh8BAQEELVwCAQgRBAEBCx0HMhQJCAIEARIIiAoBC78hjl0mEQGCX2EDl1OPQYMHgic X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208,217";a="179870673" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 21 Feb 2013 23:53:08 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1LNr8aG013661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 23:53:08 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 17:53:07 -0600 From: "Selma Yilmaz (seyilmaz)" To: "Balaji Pitta Venkatachalapathy (bvenkata)" , "John Scudder" , "idr@ietf. org" Thread-Topic: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Thread-Index: AQHOC8NscFQCWMWcKEurfy2FpQOEPJiFZG+A//+hFFA= Date: Thu, 21 Feb 2013 23:53:07 +0000 Message-ID: <23362E229301654FA612243A7EF0DAB8122DCE47@xmb-aln-x13.cisco.com> References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.81.66] Content-Type: multipart/alternative; boundary="_000_23362E229301654FA612243A7EF0DAB8122DCE47xmbalnx13ciscoc_" MIME-Version: 1.0 Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 23:53:09 -0000 --_000_23362E229301654FA612243A7EF0DAB8122DCE47xmbalnx13ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Selma From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Balaj= i Pitta Venkatachalapathy (bvenkata) Sent: Thursday, February 21, 2013 3:32 PM To: John Scudder; idr@ietf. org Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Support Balaji From: idr-bounces@ietf.org [mailto:idr-bounces= @ietf.org] On Behalf Of John Scudder Sent: Friday, February 15, 2013 1:28 PM To: idr@ietf. org Subject: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Folks, We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://tools.ietf.org/html/draft-ietf= -idr-rfd-usable-01 Please send comments to the list by March 1. Thanks, --John & Sue --_000_23362E229301654FA612243A7EF0DAB8122DCE47xmbalnx13ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

Selma

 <= /p>

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Balaji Pitta Venkatachalapathy (bvenkata)
Sent: Thursday, February 21, 2013 3:32 PM
To: John Scudder; idr@ietf. org
Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01

 

Support=

 <= /p>

Balaji<= /p>

 <= /p>

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder
Sent: Friday, February 15, 2013 1:28 PM
To: idr@ietf. org
Subject: [Idr] WGLC on draft-ietf-idr-rfd-usable-01

 

Folks,

We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://= tools.ietf.org/html/draft-ietf-idr-rfd-usable-01

Please send comments to the list by March 1.


Thanks,

--John & Sue

--_000_23362E229301654FA612243A7EF0DAB8122DCE47xmbalnx13ciscoc_-- From ankapoor@cisco.com Thu Feb 21 18:54:20 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0073621E803D for ; Thu, 21 Feb 2013 18:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtNoNmZJnq44 for ; Thu, 21 Feb 2013 18:54:19 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2F30021E803C for ; Thu, 21 Feb 2013 18:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4598; q=dns/txt; s=iport; t=1361501659; x=1362711259; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=C7vI1lFGdUMR/ibShBfLFT9Z8UM7pwELjXCqiT1i8OE=; b=OtpHdMLEGfL13rJxBnNiHhDRcETc4WQ77L/VlUNDOMPx7OjQBI1htXhC pcHjJcvaskfhPHFq6NINWVxuR4W4gOG8vSutWrBhfMGm7EE8UpAKDYP/f c2gcOOCfpeLTkGTCddi9aVuvyRqjkxdrlP9guFbgic4EEXo4CC0JPuQUz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFALDcJlGtJXHA/2dsb2JhbABFgkODRLJxAYgggQkWc4IfAQEBBC1cAgEIDgMEAQELHQcyFAkIAgQBEgiICgy/Mo5dJhEBgl9hA5dTj0GDB4In X-IronPort-AV: E=Sophos;i="4.84,713,1355097600"; d="scan'208,217";a="179881406" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 22 Feb 2013 02:54:18 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1M2sI1o021915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 02:54:18 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.82]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 20:54:18 -0600 From: "Anoop Kapoor (ankapoor)" To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Thread-Index: AQHOC8NrV4hCPnU+pEmuQhDQqNF6MpiFZG+A///TotA= Date: Fri, 22 Feb 2013 02:54:17 +0000 Message-ID: <45BC6BFD9C998D46A7F8CEAA971ED4F1150A4D07@xmb-aln-x10.cisco.com> References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.100.158] Content-Type: multipart/alternative; boundary="_000_45BC6BFD9C998D46A7F8CEAA971ED4F1150A4D07xmbalnx10ciscoc_" MIME-Version: 1.0 Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 02:54:20 -0000 --_000_45BC6BFD9C998D46A7F8CEAA971ED4F1150A4D07xmbalnx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Anoop. From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John = Scudder Sent: Friday, February 15, 2013 1:28 PM To: idr@ietf. org Subject: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Folks, We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://tools.ietf.org/html/draft-ietf= -idr-rfd-usable-01 Please send comments to the list by March 1. Thanks, --John & Sue --_000_45BC6BFD9C998D46A7F8CEAA971ED4F1150A4D07xmbalnx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Support

 

Anoop.

 

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder
Sent: Friday, February 15, 2013 1:28 PM
To: idr@ietf. org
Subject: [Idr] WGLC on draft-ietf-idr-rfd-usable-01

 

Folks,

We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://= tools.ietf.org/html/draft-ietf-idr-rfd-usable-01

Please send comments to the list by March 1.


Thanks,

--John & Sue

--_000_45BC6BFD9C998D46A7F8CEAA971ED4F1150A4D07xmbalnx10ciscoc_-- From gdawra@cisco.com Thu Feb 21 19:33:56 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6618C21F8883 for ; Thu, 21 Feb 2013 19:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXVodx5BXB-4 for ; Thu, 21 Feb 2013 19:33:56 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D2ED721F887F for ; Thu, 21 Feb 2013 19:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2698; q=dns/txt; s=iport; t=1361504036; x=1362713636; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=8HcY8ClVwC8EK+/UPa2YXwz+8437w2O2QO6K5JDFBCw=; b=XZfb2lGNhBlIp08RwxR464IBUf+EmBaklOJ1XL7tSfmkcEITMBhKNJbq M/5m5++pK1TsuEELxrFGEMy04/1AnQYH6qFnpEowkZ6m1xwvAwTkJDW4B 8WTIh8fldGLAPqkTTCTtaPY5EloczG1QiqF9yO6vONCcCm9WKOEiMzO8v A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAMHmJlGtJV2a/2dsb2JhbABFgkODRLJxAYgggQgWc4IfAQEBBIELAQgECgMDAQILHTkUCQgCBAESCIgKDL8hjl0gBhKCX2EDl1OPQYMHgic X-IronPort-AV: E=Sophos;i="4.84,713,1355097600"; d="scan'208,217";a="179883920" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 22 Feb 2013 03:33:55 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1M3XteS021855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 03:33:55 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 21:33:55 -0600 From: "Gaurav Dawra (gdawra)" To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Thread-Index: AQHOEK1w0QvmpOPF30GA7s+TbipSzw== Date: Fri, 22 Feb 2013 03:33:54 +0000 Message-ID: In-Reply-To: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.88.15] Content-Type: multipart/alternative; boundary="_000_DA0CF4624FFC5A4494FF2C4009A57449078837D0xmbalnx08ciscoc_" MIME-Version: 1.0 Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:33:56 -0000 --_000_DA0CF4624FFC5A4494FF2C4009A57449078837D0xmbalnx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. -Gaurav From: John Scudder > Date: Friday, February 15, 2013 1:27 PM To: "idr@ietf. org" > Subject: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Folks, We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://tools.ietf.org/html/draft-ietf= -idr-rfd-usable-01 Please send comments to the list by March 1. Thanks, --John & Sue --_000_DA0CF4624FFC5A4494FF2C4009A57449078837D0xmbalnx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <82CC104B91EA254BAF01E30FB3DF3914@cisco.com> Content-Transfer-Encoding: quoted-printable
Support.

-Gaurav

From: John Scudder <jgs@juniper.net>
Date: Friday, February 15, 2013 1:2= 7 PM
To: "idr@ietf. org" <<= a href=3D"mailto:idr@ietf.org">idr@ietf.org>
Subject: [Idr] WGLC on draft-ietf-i= dr-rfd-usable-01

Folks,

We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://= tools.ietf.org/html/draft-ietf-idr-rfd-usable-01

Please send comments to the list by March 1.

Thanks,

--John & Sue
 --_000_DA0CF4624FFC5A4494FF2C4009A57449078837D0xmbalnx08ciscoc_-- From jrmitche@puck.nether.net Thu Feb 21 19:42:41 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C5521E8064 for ; Thu, 21 Feb 2013 19:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 k1QcyzHhohek for ; Thu, 21 Feb 2013 19:42:41 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id D70F021E805E for ; Thu, 21 Feb 2013 19:42:40 -0800 (PST) Received: from [10.235.135.204] (64.sub-174-253-210.myvzw.com [174.253.210.64]) (authenticated bits=0) by puck.nether.net (8.14.6/8.14.5) with ESMTP id r1M3gWCD022003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2013 22:42:33 -0500 References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> Mime-Version: 1.0 (1.0) In-Reply-To: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> Content-Type: multipart/alternative; boundary=Apple-Mail-A545781B-6C04-4BD8-B46A-9AA4E7AF341B Content-Transfer-Encoding: 7bit Message-Id: <2939B050-0BA6-47ED-B831-6F35BC5CAF55@puck.nether.net> X-Mailer: iPhone Mail (10B141) From: Jon Mitchell Date: Thu, 21 Feb 2013 19:42:35 -0800 To: John Scudder Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 03:42:41 -0000 --Apple-Mail-A545781B-6C04-4BD8-B46A-9AA4E7AF341B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Support. -Jon On Feb 15, 2013, at 1:27 PM, John Scudder wrote: > Folks, >=20 > We have received a request for a working group last call on draft-ietf-idr= -rfd-usable-01. A URL for the draft is http://tools.ietf.org/html/draft-ietf= -idr-rfd-usable-01 >=20 > Please send comments to the list by March 1. >=20 > Thanks, >=20 > --John & Sue > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail-A545781B-6C04-4BD8-B46A-9AA4E7AF341B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Support.

-Jon

On = Feb 15, 2013, at 1:27 PM, John Scudder <jgs@juniper.net> wrote:

= Folks,

We have received a request for a working group last call on dr= aft-ietf-idr-rfd-usable-01. A URL for the draft is http://tools.ietf.org/html/draft-= ietf-idr-rfd-usable-01

Please send comments to the list by March 1= .

Thanks,

--John & Sue
_____________________________________________= __
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
<= /div>= --Apple-Mail-A545781B-6C04-4BD8-B46A-9AA4E7AF341B-- From jeff.tantsura@ericsson.com Thu Feb 21 21:04:52 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D311821E805D for ; Thu, 21 Feb 2013 21:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxObWV2Ao1ir for ; Thu, 21 Feb 2013 21:04:51 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 27A5921E8055 for ; Thu, 21 Feb 2013 21:04:51 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-a5-5126fc72a12f Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 62.14.03705.27CF6215; Fri, 22 Feb 2013 06:04:50 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 00:04:50 -0500 From: Jeff Tantsura To: John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Thread-Index: AQHOC8NrlCNfd+NmO0GKyxW1YWo1HpiFlysA//+TSIA= Date: Fri, 22 Feb 2013 05:04:48 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C748391F51C9@eusaamb109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C748391F51C9eusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXRPgm7RH7VAg1PHjCxe3X7GZDHzxldW ByaPJUt+Mnlcb7rKHsAUxWWTkpqTWZZapG+XwJVx/Lx3wS/Jio0f9jM3ML4X62Lk5JAQMJF4 /vITC4QtJnHh3nq2LkYuDiGBI4wSnz7MYARJCAksZ5RovWkCYrMJGEj8/3YcrEFEwEmi6dBc NhBbWMBcom/XMqA4B1DcQmLaNBWIEiuJG/+fg41hEVCVmPH1AhOIzSvgLfH75w+wVk4BX4m2 VXvAbEagG76fWgNWwywgLnHryXwmiNsEJJbsOc8MYYtKvHz8jxXEFhXQk2g7doYdIq4sseTJ fhaI3nyJxdNfs0HsEpQ4OfMJywRGkVlIxs5CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx5D 9VpLvNy8lglZzQJGjlWMHKXFqWW56UaGmxiBEXVMgs1xB+OCT5aHGKU5WJTEeUNdLwQICaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYBTPEvmVr266tbdvgk7etS9yU7WfMOsvan68wk23+4bl 8lkrHjy6q5+783Xvom3cHxg8hS71aG94YMGZ4af043noPJv58+9terKe045161WpDd3qygXV HA90HH/IvBdROC2UlvNR74rQpMX2Oh4MHfsYWbT9760xLdQ5ePOXyr3gl/tPPPukpazEUpyR aKjFXFScCABKx1H5dgIAAA== Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 05:04:52 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C748391F51C9eusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support Cheers, Jeff From: John Scudder > Date: Friday, February 15, 2013 1:27 PM To: "idr@ietf. org" > Subject: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Folks, We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://tools.ietf.org/html/draft-ietf= -idr-rfd-usable-01 Please send comments to the list by March 1. Thanks, --John & Sue --_000_60DEDD93F5E54B4AB55647B8B6C748391F51C9eusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <3A879AA9D874BB49851E90C9EC590115@ericsson.com> Content-Transfer-Encoding: quoted-printable
Yes/support

Cheers,
Jeff

From: John Scudder <jgs@juniper.net>
Date: Friday, February 15, 2013 1:2= 7 PM
To: "idr@ietf. org" <<= a href=3D"mailto:idr@ietf.org">idr@ietf.org>
Subject: [Idr] WGLC on draft-ietf-i= dr-rfd-usable-01

Folks,

We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://= tools.ietf.org/html/draft-ietf-idr-rfd-usable-01

Please send comments to the list by March 1.

Thanks,

--John & Sue
 --_000_60DEDD93F5E54B4AB55647B8B6C748391F51C9eusaamb109ericsso_-- From wim.henderickx@alcatel-lucent.com Thu Feb 21 22:48:46 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444CD21F8EC6 for ; Thu, 21 Feb 2013 22:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.249 X-Spam-Level: X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[AWL=1.999, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4lx13bLPp+O for ; Thu, 21 Feb 2013 22:48:45 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5069821F8EBC for ; Thu, 21 Feb 2013 22:48:45 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1M6mgEY022910 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 22 Feb 2013 07:48:42 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 22 Feb 2013 07:48:42 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.76]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 22 Feb 2013 07:48:42 +0100 From: "Henderickx, Wim (Wim)" To: Jeff Tantsura , John Scudder , "idr@ietf. org" Thread-Topic: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Thread-Index: AQHOEK1wBAFcaBGBwkKRt5kaekpyYZiFQicAgAAtxwA= Date: Fri, 22 Feb 2013 06:48:41 +0000 Message-ID: In-Reply-To: <60DEDD93F5E54B4AB55647B8B6C748391F51C9@eusaamb109.ericsson.se> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CD4CD35235483wimhenderickxalcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:48:46 -0000 --_000_CD4CD35235483wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: Jeff Tantsura > Date: Friday 22 February 2013 07:04 To: John Scudder >, "idr@ietf. org"= > Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Yes/support Cheers, Jeff From: John Scudder > Date: Friday, February 15, 2013 1:27 PM To: "idr@ietf. org" > Subject: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Folks, We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://tools.ietf.org/html/draft-ietf= -idr-rfd-usable-01 Please send comments to the list by March 1. Thanks, --John & Sue --_000_CD4CD35235483wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9FA74CE006750B40AA8F8914BE2906C0@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
+1

From: Jeff Tantsura <jeff.tantsura@ericsson.com>
Date: Friday 22 February 2013 07:04=
To: John Scudder <jgs@juniper.net>, "idr@ietf. org" <= ;idr@ietf.org>
Subject: Re: [Idr] WGLC on draft-ie= tf-idr-rfd-usable-01

Yes/support

Cheers,
Jeff

From: John Scudder <jgs@juniper.net>
Date: Friday, February 15, 2013 1:2= 7 PM
To: "idr@ietf. org" <<= a href=3D"mailto:idr@ietf.org">idr@ietf.org>
Subject: [Idr] WGLC on draft-ietf-i= dr-rfd-usable-01

Folks,

We have received a request for a working group last call on draft-ietf-idr-= rfd-usable-01. A URL for the draft is http://= tools.ietf.org/html/draft-ietf-idr-rfd-usable-01

Please send comments to the list by March 1.

Thanks,

--John & Sue
 --_000_CD4CD35235483wimhenderickxalcatellucentcom_-- From rraszuk@gmail.com Thu Feb 21 23:00:21 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4506821F8F45 for ; Thu, 21 Feb 2013 23:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt82LeyBavcn for ; Thu, 21 Feb 2013 23:00:20 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id AD25E21F8F44 for ; Thu, 21 Feb 2013 23:00:20 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id k13so350997iea.35 for ; Thu, 21 Feb 2013 23:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=vpCY01QoUdozp1XCabIhP6NV+vHm9NH42WR1+Brc8kY=; b=SBIA+wSDNZPs7x7h8yvxsPx3WU5Bgzlx+U44xYr1l2Ufb8Gr7o5Y1gBgREOIAY7kxj 0cqTtnJC1Pof1ox9MsySynBaHitJJQ1RHT135/k/O6/P7DUV4nLWrLGj7p/1qmSj4l75 b30VcpMCq3BojEENWyDSDKG4PevuPeuecplXLroNx2G6NPsd9vgUNw3F6HerpQWxmKNt +qnImrHIVraI8NTtz+qCGoKPpBPYxFt2xlrWSsWstbZni+GRTf9rReoL8V7XvhnqnE8D xI/pC8dvMzMdmkghgPEFq8UO34DsX3RcYuDusie60A4habsZQnVtm95C0qXNhcv/kF3F huHQ== MIME-Version: 1.0 X-Received: by 10.50.47.200 with SMTP id f8mr14482008ign.98.1361516419971; Thu, 21 Feb 2013 23:00:19 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Thu, 21 Feb 2013 23:00:19 -0800 (PST) In-Reply-To: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> Date: Fri, 22 Feb 2013 08:00:19 +0100 X-Google-Sender-Auth: MG5GjJAFgc6V9Bc9Wgd_khuUkkY Message-ID: From: Robert Raszuk To: John Scudder Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 07:00:21 -0000 I support the draft. However I would like to propose a little addition the the current text which would explicitly encourage vendors to provide "monitoring only mode" with new or old or multiple sets of dampening parameters without actually applying any dampening on the prefixes. I believe that such ability to monitor prefixes subject to be dampened would increase operator's comfort with dampening and therefor turn positive for the stability of the routing system. It would also allow to fine tune parameters depending on the actual AFI/SAFI or peer subject to enabling dampening. Regards, R. On Fri, Feb 15, 2013 at 10:27 PM, John Scudder wrote: > Folks, > > We have received a request for a working group last call on > draft-ietf-idr-rfd-usable-01. A URL for the draft is > http://tools.ietf.org/html/draft-ietf-idr-rfd-usable-01 > > Please send comments to the list by March 1. > > Thanks, > > --John & Sue > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > From randy@psg.com Thu Feb 21 23:03:06 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1EA21F8F47 for ; Thu, 21 Feb 2013 23:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 14KhO8aWBqcZ for ; Thu, 21 Feb 2013 23:03:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4995C21F8F45 for ; Thu, 21 Feb 2013 23:03:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U8meu-0009VS-B3; Fri, 22 Feb 2013 07:03:04 +0000 Date: Fri, 22 Feb 2013 16:03:03 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 07:03:06 -0000 > However I would like to propose a little addition the the current text > which would explicitly encourage vendors to provide "monitoring only > mode" with new or old or multiple sets of dampening parameters without > actually applying any dampening on the prefixes. if you happen to be near a crisco, try show ip bgp dampening dampened-paths i forget the juniper equivalent and do not know other vendors well at all. randy From rraszuk@gmail.com Thu Feb 21 23:09:42 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F1E21F8EF2 for ; Thu, 21 Feb 2013 23:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37IshCELqkHd for ; Thu, 21 Feb 2013 23:09:41 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 804CD21F8EC6 for ; Thu, 21 Feb 2013 23:09:41 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so311578lab.28 for ; Thu, 21 Feb 2013 23:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=x88UrcEHxoLUoNot4EbYQyGp1pKPcmh/t+K/LMHBsJc=; b=j7pLqeFd7dNmhjqFQ3HzFXD3h078sV7ZSvx6oh9ov5VQev2IZ6Ahnbe4gdWd7b2pTH Bw1/HVNVCZAb/O/977wtii4g/Yqw2RRX8+cPfHThgT0IExM/epYo63hjc9TpKSNV76D6 /JbtVpccpcYPOusK4nXpiqJc+7EgeM7YBWbaX5yNfb7TlJWhRlHSgdrY6mT5+r6GPC2u fKxRy+6yolpdijpjKbItlLO0nM4WfM/c14/iOIZZW4FGWQG5iR/kGHsv/e0Cpa+t4E/z M/JUQn7tMQw5Et3PauuZoljDbeUnaK51e2ygLMv7eiACm1uBwXI6OB+HRewzVdepK1q8 n9HA== MIME-Version: 1.0 X-Received: by 10.152.105.244 with SMTP id gp20mr771946lab.34.1361516980325; Thu, 21 Feb 2013 23:09:40 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.112.86.102 with HTTP; Thu, 21 Feb 2013 23:09:40 -0800 (PST) In-Reply-To: References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> Date: Fri, 22 Feb 2013 08:09:40 +0100 X-Google-Sender-Auth: ouGMPRjZo2yOep8ENTycdWdjCm0 Message-ID: From: Robert Raszuk To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 07:09:42 -0000 This command shows actually dampened paths. #sh ip bgp dampening ? dampened-paths Display paths suppressed due to dampening I am asking for something different .. for ability to record what would be dampened for a given set (or sets) of parameters without actually preforming dampening. In cisco both Enke and myself were recommending this mode for a long time, however my comment to include such monitoring into your draft was to raise the awareness of other people who may find such thing useful to get more comfortable with bgp dampening. Many thx, R. On Fri, Feb 22, 2013 at 8:03 AM, Randy Bush wrote: >> However I would like to propose a little addition the the current text >> which would explicitly encourage vendors to provide "monitoring only >> mode" with new or old or multiple sets of dampening parameters without >> actually applying any dampening on the prefixes. > > if you happen to be near a crisco, try > > show ip bgp dampening dampened-paths > > i forget the juniper equivalent and do not know other vendors well at > all. > > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From randy@psg.com Thu Feb 21 23:22:41 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9775121F8EE6 for ; Thu, 21 Feb 2013 23:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, 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 PMulP1RpHvOb for ; Thu, 21 Feb 2013 23:22:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 40D2F21F8EE0 for ; Thu, 21 Feb 2013 23:22:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U8mxs-0009YF-Jt; Fri, 22 Feb 2013 07:22:40 +0000 Date: Fri, 22 Feb 2013 16:22:38 +0900 Message-ID: From: Randy Bush To: Robert Raszuk In-Reply-To: References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 07:22:41 -0000 the draft suggests some painless changes to parameters based on real measurements. these parameters can mostly be set by the operator. to start to change it into an ops, cli, and management draft is a long ugly slope. you may find it more appropriate to write a separate draft to carry on your and enke's old arguments within cisco. randy From pierre.francois@imdea.org Fri Feb 22 00:24:27 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EE321F8F68 for ; Fri, 22 Feb 2013 00:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 iwDO1y7yHi6F for ; Fri, 22 Feb 2013 00:24:26 -0800 (PST) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 98E7721F8F66 for ; Fri, 22 Feb 2013 00:24:26 -0800 (PST) Received: from localhost (estafeta21.imdea.org [172.17.99.144]) by estafeta21.imdea.org (Postfix) with ESMTP id 378E51894E8; Fri, 22 Feb 2013 09:24:24 +0100 (CET) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.144]) by localhost (estafeta21.imdea.org [172.17.99.144]) (amavisd-new, port 10024) with ESMTP id FVvNMwT68SMo; Fri, 22 Feb 2013 09:24:24 +0100 (CET) Received: from [10.151.158.88] (137.Red-176-83-119.dynamicIP.rima-tde.net [176.83.119.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (Postfix) with ESMTP id CF8851894E7; Fri, 22 Feb 2013 09:24:23 +0100 (CET) References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <63E45CCE-6E83-43F2-BAC8-8CA90CCE32E0@imdea.org> X-Mailer: iPhone Mail (10B143) From: Pierre Francois Date: Fri, 22 Feb 2013 09:24:23 +0100 To: Randy Bush Cc: "idr@ietf. org" , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 08:24:27 -0000 Robert, Randy, all, Actually, following Randy's suggestion would be great. Everyone making sense= would be up to know the result of a config change before doing it, right? Moreover, when ops will start following cristel and randy's recommendation, t= hey will change the dynamics of bgp path propagation. It may as a result cha= nge the input to the real measurement they performed, forcing them to update= the draft with a new recommendation.=20 Giving ops the means to understand what will happen upon the next change cou= ld help their work not be still a WG doc in 2050. +1 to the support of this draft and=20 +1 to the support of the draft Robert should write :) Pierre. Sent from my iPhone On Feb 22, 2013, at 8:22 AM, Randy Bush wrote: > the draft suggests some painless changes to parameters based on real > measurements. these parameters can mostly be set by the operator. >=20 > to start to change it into an ops, cli, and management draft is a long > ugly slope. you may find it more appropriate to write a separate draft > to carry on your and enke's old arguments within cisco. >=20 > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From rraszuk@gmail.com Fri Feb 22 05:45:54 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A810A21F88B5 for ; Fri, 22 Feb 2013 05:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oa3WYBL1rwyn for ; Fri, 22 Feb 2013 05:45:54 -0800 (PST) Received: from mail-ia0-x22c.google.com (mail-ia0-x22c.google.com [IPv6:2607:f8b0:4001:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3566A21F8786 for ; Fri, 22 Feb 2013 05:45:54 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id l29so550468iag.3 for ; Fri, 22 Feb 2013 05:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DhBRg9kI7zbuK45ZE6qYNjxLWHsyVxFc0X1eO4XYLRg=; b=lNaFB61/1baDTVDrfwGujlkhNUE/nRBopkczglO+UlHX9IjpX/yaEE6t9a9m0afBeF W8Shn4rZHEXczKPPzTfbtW5y0buQgpS/ZzLn7G8f6uTcPZKEGZOzMjmv1WpYvpnCsuTG lBY6GA52Gu9JJmkO9BiQ4/ofJNMHAWqUm0EdtTgviTBNE51FvxShfUfrf+n1msTO0fE5 qko+ZMrBa82ec9mKsWJuR7n5p5E/3XRdzDwEZXWm3DXY8zOEsjZo5d/HA2HnhyW2G0bk VfO2m1gHaTfRdG95JTMn15nQNGhu/vOeAFNJfDA3jZ7/ceebHp0i0ikk/N6qn7bmXRyg 1+9w== MIME-Version: 1.0 X-Received: by 10.50.47.200 with SMTP id f8mr14987260ign.98.1361540753843; Fri, 22 Feb 2013 05:45:53 -0800 (PST) Sender: rraszuk@gmail.com Received: by 10.64.100.207 with HTTP; Fri, 22 Feb 2013 05:45:53 -0800 (PST) In-Reply-To: <63E45CCE-6E83-43F2-BAC8-8CA90CCE32E0@imdea.org> References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> <63E45CCE-6E83-43F2-BAC8-8CA90CCE32E0@imdea.org> Date: Fri, 22 Feb 2013 14:45:53 +0100 X-Google-Sender-Auth: 0sYdOoS9Oa8tscGZOhVbjy5K7Z4 Message-ID: From: Robert Raszuk To: Pierre Francois Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "idr@ietf. org" Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:45:54 -0000 Hi Pierre, I really do not think that what can be said in two sentences in the current draft justifies a new one. Hence my suggestion just to add this to the current deployment section. Cheers, R. On Fri, Feb 22, 2013 at 9:24 AM, Pierre Francois wrote: > > Robert, Randy, all, > > Actually, following Randy's suggestion would be great. Everyone making se= nse would be up to know the result of a config change before doing it, rig= ht? > > Moreover, when ops will start following cristel and randy's recommendatio= n, they will change the dynamics of bgp path propagation. It may as a resul= t change the input to the real measurement they performed, forcing them to = update the draft with a new recommendation. > > Giving ops the means to understand what will happen upon the next change = could help their work not be still a WG doc in 2050. > > +1 to the support of this draft and > +1 to the support of the draft Robert should write :) > > Pierre. > > > > Sent from my iPhone > > On Feb 22, 2013, at 8:22 AM, Randy Bush wrote: > >> the draft suggests some painless changes to parameters based on real >> measurements. these parameters can mostly be set by the operator. >> >> to start to change it into an ops, cli, and management draft is a long >> ugly slope. you may find it more appropriate to write a separate draft >> to carry on your and enke's old arguments within cisco. >> >> randy >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr From jeff.tantsura@ericsson.com Fri Feb 22 08:35:58 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A23321F8496 for ; Fri, 22 Feb 2013 08:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83xH21dh-atO for ; Fri, 22 Feb 2013 08:35:58 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id D878621F8F51 for ; Fri, 22 Feb 2013 08:35:57 -0800 (PST) X-AuditID: c618062d-b7fcb6d000007ada-70-51279e6cfdfe Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 96.28.31450.C6E97215; Fri, 22 Feb 2013 17:35:56 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 11:35:54 -0500 From: Jeff Tantsura To: Pierre Francois , Randy Bush Thread-Topic: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 Thread-Index: AQHOC8NrlCNfd+NmO0GKyxW1YWo1HpiF0NeAgAAAxICAAAHZAIAAA58AgAARQYCAAAM4AA== Date: Fri, 22 Feb 2013 16:35:54 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C74839284759@eusaamb109.ericsson.se> In-Reply-To: <63E45CCE-6E83-43F2-BAC8-8CA90CCE32E0@imdea.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPgm7OPPVAgylrTC1e3X7GZPHm3R82 i2etL5ksmhY2MTuweCxZ8pPJ4/vaa8weU2fOZvTYvXEBUwBLFJdNSmpOZllqkb5dAlfG8stP 2Qo6+CqOzXvE1sB4kLuLkZNDQsBE4mrjNWYIW0ziwr31bF2MXBxCAkcYJa6vvsUI4SxnlOh9 N5MRpIpNwEDi/7fjLCC2iIC3xOkdB8BsZgFXiX9fL4PZwgLmEn27lgHZHEA1FhLTpqlAmGES nb9dQCpYBFQlLt+cxwRi8wJNWT/tOzuIzSlgK3Gu5zNYnBHonu+n1jBBTBeXuPVkPhPEnQIS S/ach7pZVOLl43+sILaogJ5E27Ez7BBxZYnvcx5BXaYjsWD3JzYI21ri37SVULa2xLKFr5kh bhCUODnzCcsERvFZSNbNQtI+C0n7LCTts5C0L2BkXcXIUVqcWpabbmSwiREYe8ck2HR3MO55 aXmIUZqDRUmcN8j1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRslXh48uPHaJaTZ38Oxl wmYzHT4tbuw+/NL0l5jHfNHv9U9k1rwu+7rs+y7ffY8yNVoTlHWeKFfcrckV0ToYajVZ7LA6 89qJPllSuge0yvnk87/9tLOL47sfPolFTlaFraVm98k7uzO6/u9Lf8PoZHK3XK7r2JmOKf/P BC36Efi0VWeF7WeWBiWW4oxEQy3mouJEAOy+YYCLAgAA Cc: "idr@ietf. org" , Robert Raszuk Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:35:58 -0000 +1 to the upcoming Robert's draft! Cheers, Jeff -----Original Message----- From: Pierre Francois Date: Friday, February 22, 2013 12:24 AM To: Randy Bush Cc: "idr@ietf. org" , "robert@raszuk.net" Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 > >Robert, Randy, all, > >Actually, following Randy's suggestion would be great. Everyone making >sense would be up to know the result of a config change before doing it, >right? > >Moreover, when ops will start following cristel and randy's >recommendation, they will change the dynamics of bgp path propagation. It >may as a result change the input to the real measurement they performed, >forcing them to update the draft with a new recommendation. > >Giving ops the means to understand what will happen upon the next change >could help their work not be still a WG doc in 2050. > >+1 to the support of this draft and >+1 to the support of the draft Robert should write :) > >Pierre. > > > >Sent from my iPhone > >On Feb 22, 2013, at 8:22 AM, Randy Bush wrote: > >> the draft suggests some painless changes to parameters based on real >> measurements. these parameters can mostly be set by the operator. >>=20 >> to start to change it into an ops, cli, and management draft is a long >> ugly slope. you may find it more appropriate to write a separate draft >> to carry on your and enke's old arguments within cisco. >>=20 >> randy >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From shares@ndzh.com Fri Feb 22 12:57:32 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA19C21E8087 for ; Fri, 22 Feb 2013 12:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.925 X-Spam-Level: X-Spam-Status: No, score=0.925 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 183Ut84DN8Xl for ; Fri, 22 Feb 2013 12:57:32 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 11C2621E8085 for ; Fri, 22 Feb 2013 12:57:31 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Randy Bush'" , "'Robert Raszuk'" References: <7E96CF2B-8DCD-4F87-97C4-CF4E1CDC2741@juniper.net> In-Reply-To: Date: Fri, 22 Feb 2013 15:57:14 -0500 Message-ID: <00e701ce113f$31b6abb0$95240310$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGJKHV8TI+wY2/TwMOYEmwwrkJpSwF1sbM3Ag0mu7AC55NABgGBn6bVmNDMGpA= X-Authenticated-User: skh@ndzh.com Cc: "'idr@ietf. org'" Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 20:57:33 -0000 Robert: In the spirit of the last call, you are welcome to make all the suggestions you wish. However, the change you suggest would take this draft out of a last call process and restart the process after discussion. It's always great to hear your ideas, Sue Hares -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Friday, February 22, 2013 2:23 AM To: Robert Raszuk Cc: idr@ietf. org Subject: Re: [Idr] WGLC on draft-ietf-idr-rfd-usable-01 the draft suggests some painless changes to parameters based on real measurements. these parameters can mostly be set by the operator. to start to change it into an ops, cli, and management draft is a long ugly slope. you may find it more appropriate to write a separate draft to carry on your and enke's old arguments within cisco. randy _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From suketusoni@hotmail.com Mon Feb 25 03:19:09 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48F721F8481 for ; Mon, 25 Feb 2013 03:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWOicz7rvByl for ; Mon, 25 Feb 2013 03:19:09 -0800 (PST) Received: from bay0-omc3-s23.bay0.hotmail.com (bay0-omc3-s23.bay0.hotmail.com [65.54.190.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4F89821F8468 for ; Mon, 25 Feb 2013 03:19:09 -0800 (PST) Received: from BAY170-W120 ([65.54.190.187]) by bay0-omc3-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Feb 2013 03:19:09 -0800 X-EIP: [wI6hpxZgXAcRexohO7C4Es8danM2DqKB] X-Originating-Email: [suketusoni@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_830aa116-2be8-418f-aed8-6c9f2006f25f_" From: suketu soni To: Date: Mon, 25 Feb 2013 11:19:08 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 Feb 2013 11:19:09.0327 (UTC) FILETIME=[EE6219F0:01CE1349] Subject: [Idr] BGP maximum message size X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 11:19:09 -0000 --_830aa116-2be8-418f-aed8-6c9f2006f25f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Team=2C RFC 4271 comments about BGP maximum message size: "BGP messages= are sent over TCP connections. A message is processed only after it is ent= irely received. The maximum message size is 4096 octets. All implementation= s are required to support this maximum message size. The smallest message t= hat may be sent consists of a BGP header without a data portion (19 octets)= ." Does this message size - 4096 octets - relate to maximum TCP window size= used by BGP? If yes=2C can a BGP session's throughput be calculated (theor= itical) as per the following formula? [(maximum window size of 4096 octets)= x (8 bits per octet) x 1000] / (round-trip-delay in milli-second)Thanking = you in advance. Best wishes =20 Suketu Soni =20 = --_830aa116-2be8-418f-aed8-6c9f2006f25f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Team=2C
 =3B
RFC 4271 comments about BGP maximum message size:=
 =3B
"BGP messages are sent over TCP connections. A message is proce= ssed only after it is entirely received. The maximum message size is 4096 o= ctets. All implementations are required to support this maximum message siz= e. The smallest message that may be sent consists of a BGP header without a= data portion (19 octets)."
 =3B
Does this = message size - 4096 octets - relate to maximum TCP window size used by BGP?= If yes=2C can a BGP session's throughput be c= alculated (theoritical) as per the following formula?
 =3B
[(maximum window size = of 4096 octets) x (8 bits per octet) x 1000] / (round-trip-delay in milli-s= econd)Tha= nking you in advance.
Best wish= es  =3B
Suketu Soni
 =3B

= --_830aa116-2be8-418f-aed8-6c9f2006f25f_-- From nick@foobar.org Mon Feb 25 03:33:08 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A524F21F8648 for ; Mon, 25 Feb 2013 03:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HURSWBWYimJH for ; Mon, 25 Feb 2013 03:33:07 -0800 (PST) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A5C6721F85FD for ; Mon, 25 Feb 2013 03:33:04 -0800 (PST) X-Envelope-To: idr@ietf.org Received: from crumpet.local (pancake.netability.ie [87.198.142.197]) (authenticated bits=0) by mail.netability.ie (8.14.4/8.14.5) with ESMTP id r1PBUEFW082557 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 25 Feb 2013 11:30:14 GMT (envelope-from nick@foobar.org) Message-ID: <512B4BED.2040003@foobar.org> Date: Mon, 25 Feb 2013 11:33:01 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: suketu soni References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: idr@ietf.org Subject: Re: [Idr] BGP maximum message size X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 11:33:08 -0000 On 25/02/2013 11:19, suketu soni wrote: > Does this message size - 4096 octets - relate to maximum TCP window size > used by BGP? No. it's the size of the bgp message as defined in 4271. E.g. UPDATE + NLRIs + attributes, etc. It's not particularly related to tcp packet size. Nick From tony.li@tony.li Mon Feb 25 03:39:52 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A0A21F92C7 for ; Mon, 25 Feb 2013 03:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, 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 YsYlBa9Wtonh for ; Mon, 25 Feb 2013 03:39:51 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 7694921F92C1 for ; Mon, 25 Feb 2013 03:39:51 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id 4bde1l0031c6gX85FbfrpH; Mon, 25 Feb 2013 11:39:51 +0000 Received: from [192.168.1.66] ([76.218.80.143]) by omta23.westchester.pa.mail.comcast.net with comcast id 4bdQ1l00U35XgAs3jbdWP9; Mon, 25 Feb 2013 11:37:46 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tony Li In-Reply-To: Date: Mon, 25 Feb 2013 03:37:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <58B1D467-5244-4478-BD4D-81284873AF23@tony.li> References: To: suketu soni X-Mailer: Apple Mail (2.1499) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361792391; bh=nT8lNwG7yGRJQHyKLkn+biU/Vrk3SjnF/SYw3Nmoawg=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=JUhr+GFJJR4RZIUbOyQBZUrYh90KMJeGiCaNQ9yJYluNpc7zhmfW557SOo4mBgBfN iNysAao7RsnOMiFD0kq1rB/9UOmWJbV3lq+5OFeiGp35hPcMLg/UiMu5EdaReAz8NG ws1nrbP7x/f+hb9bMQhSxHh2kFS5NVaCHuwI7oFnNOMKdEF7aaieOCt+34Hu7qLEKe b04A1/0ExpwD1KICwzqlIFv7nWrjhvpwAPgp3kdyOlrM25rF0JeskEN0mmFZ4SsfPF HVC1zboYXwyqJFPPhW+4SHcAcrZlCU6jrdfOYU0ZmYTRGt+ypve3Lis/OoZT/KQQSp Ay2S58E8bRT6Q== Cc: idr@ietf.org Subject: Re: [Idr] BGP maximum message size X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 11:39:52 -0000 >=20 > RFC 4271 comments about BGP maximum message size:=20 > =20 > "BGP messages are sent over TCP connections. A message is processed = only after it is entirely received. The maximum message size is 4096 = octets. All implementations are required to support this maximum message = size. The smallest message that may be sent consists of a BGP header = without a data portion (19 octets)." > =20 > Does this message size - 4096 octets - relate to maximum TCP window = size used by BGP? Hi Suketu, No, not at all. They are completely independent. Tony From internet-drafts@ietf.org Mon Feb 25 12:32:48 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBACF21F865D; Mon, 25 Feb 2013 12:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS8X3EEiZznA; Mon, 25 Feb 2013 12:32:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5447421E808F; Mon, 25 Feb 2013 12:32:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225203245.12789.95132.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 12:32:45 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp-bestpath-selection-criteria-06.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 20:32:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : BGP Bestpath Selection Criteria Enhancement Author(s) : Rajiv Asati Filename : draft-ietf-idr-bgp-bestpath-selection-criteria-06.txt Pages : 8 Date : 2013-02-25 Abstract: BGP specification [RFC4271] prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bestpath-selection-crit= eria There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp-bestpath-selection-criteria-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-bestpath-selection-cr= iteria-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 13:03:32 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F0F21E80D2; Mon, 25 Feb 2013 13:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWliSXJd3-04; Mon, 25 Feb 2013 13:03:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED9121F929B; Mon, 25 Feb 2013 13:03:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225210331.11915.60418.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 13:03:31 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ls-distribution-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:03:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : North-Bound Distribution of Link-State and TE Informatio= n using BGP Author(s) : Hannes Gredler Jan Medved Stefano Previdi Adrian Farrel Saikat Ray Filename : draft-ietf-idr-ls-distribution-02.txt Pages : 43 Date : 2013-02-25 Abstract: In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including traffic engineering information. This is information typically distributed by IGP routing protocols within the network This document describes a mechanism by which links state and traffic engineering information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual links. The mechanism described is subject to policy control. Applications of this technique include Application Layer Traffic Optimization (ALTO) servers, and Path Computation Elements (PCEs). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ls-distribution There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ls-distribution-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-ls-distribution-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 14:40:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6341221E812F; Mon, 25 Feb 2013 14:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 AQybEYbn6fDg; Mon, 25 Feb 2013 14:40:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7154221E80F6; Mon, 25 Feb 2013 14:40:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225224034.18570.90487.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 14:40:34 -0800 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-ix-bgp-route-server-02.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 22:40:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Inter-Domain Routing Working Group of the= IETF. Title : Internet Exchange Route Server Author(s) : Elisa Jasinska Nick Hilliard Robert Raszuk Niels Bakker Filename : draft-ietf-idr-ix-bgp-route-server-02.txt Pages : 11 Date : 2013-02-25 Abstract: This document outlines a specification for multilateral interconnections at Internet exchange points (IXPs). Multilateral interconnection is a method of exchanging routing information between three or more exterior BGP speakers using a single intermediate broker system, referred to as a route server. Route servers are typically used on shared access media networks, such as Internet exchange points (IXPs), to facilitate simplified interconnection between multiple Internet routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-ix-bgp-route-server-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-ix-bgp-route-server-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shares@ndzh.com Mon Feb 25 16:22:57 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B3121F906C for ; Mon, 25 Feb 2013 16:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.889 X-Spam-Level: X-Spam-Status: No, score=0.889 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 ukNtHpXpEjbt for ; Mon, 25 Feb 2013 16:22:56 -0800 (PST) Received: from hickoryhill-consulting.com (unknown [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EED6721E81B9 for ; Mon, 25 Feb 2013 16:22:55 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: References: In-Reply-To: Date: Mon, 25 Feb 2013 19:22:49 -0500 Message-ID: <002001ce13b7$69484550$3bd8cff0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CE138D.80746030" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGcqzlS4iUpVdMQVEYaff0a079BS5juFIUA Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-IsFriend: Cc: shares@ndzh.com Subject: Re: [Idr] IETF-86 agenda topics X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:22:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01CE138D.80746030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all This is a second call for the agenda topics. Tomorrow (2/26/13) at 13:00 ET is the deadline. I've only received 1 topic requests for IDR so far. Please request the topic by replying to this message and leaving the subject line alone. If you sent the request to John alone, please resend to me. John's offline Tuesday and Wednesday due to travel. Sue From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder Sent: Wednesday, February 13, 2013 1:06 PM To: idr@ietf.org List Subject: [Idr] IETF-86 agenda topics Folks, We're planning to meet at IETF-86 on Wednesday, March 13 from 9:00 to 11:30. Please forward any IDR agenda items you might have to Sue and myself. The deadline is February 26 by 13:00 U.S. Eastern Time, although earlier is better. Given the tardiness of this announcement we'll work to accommodate those who need additional time, but priority will still be given to those who get their requests in before the deadline. If you have previously presented on your topic at an IDR meeting, please explain in your request what you hope to achieve with your presentation this time. If you plan to make a presentation, please keep in mind the IDR tradition, "no Internet Draft - no time slot". You should also plan to send your slides to Sue and me no later than 24 hours prior to the meeting, though again, earlier is better. Finally, if you request an agenda slot, please do so by replying to this message and don't change the subject line. Thanks, --John & Sue ------=_NextPart_000_0021_01CE138D.80746030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all

 

This is a second call for the agenda topics.   Tomorrow = (2/26/13) at 13:00 ET is the deadline.   I’ve only = received 1 topic requests for IDR so far.

 

Please request the topic by replying to this message and leaving the = subject line alone.

 

If you sent the request to John alone, please resend to me.  = John’s offline Tuesday and Wednesday due to travel.  =  

 

Sue

 

From:= = idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = John Scudder
Sent: Wednesday, February 13, 2013 1:06 = PM
To: idr@ietf.org List
Subject: [Idr] IETF-86 = agenda topics

 

Folks,

We're planning to meet at IETF-86 on = Wednesday, March 13 from 9:00 to 11:30.  Please forward any IDR = agenda items you might have to Sue and myself.  The deadline is = February 26 by 13:00 U.S. Eastern Time, although earlier is better. =  Given the tardiness of this announcement we'll work to accommodate = those who need additional time, but priority will still be given to = those who get their requests in before the deadline.

If you have = previously presented on your topic at an IDR meeting, please explain in = your request what you hope to achieve with your presentation this = time.

If you plan to make a presentation, please keep in mind the = IDR tradition, "no Internet Draft - no time slot".  You = should also plan to send your slides to Sue and me no later than 24 = hours prior to the meeting, though again, earlier is = better.

Finally, if you request an agenda slot, please do so by = replying to this message and don't change the subject = line.

Thanks,

--John & = Sue

------=_NextPart_000_0021_01CE138D.80746030-- From svshah@cisco.com Wed Feb 27 16:45:06 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E9021F96D1; Wed, 27 Feb 2013 16:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 yVi4MtSI96f7; Wed, 27 Feb 2013 16:44:52 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B18BE21F8D37; Wed, 27 Feb 2013 15:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6016; q=dns/txt; s=iport; t=1362009591; x=1363219191; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=X/tGN3686/+38nOlkCQlo9hQqhnMKqbH/MF3F+0Tblk=; b=LFkq85uiR898XDkT5uNfGrG+cuZYpBdNvKVGeSmJvoZnk0N1QA/sORqI e6AKhm58ANNkNBYRIvU4Su6d4yXQspnJKRKyXW9fvw0097QmijitIetW2 5YqdeaCP6wiLzdUqbL/KDjm2wmvhhY6XJk9GESaPzaS5Eq3rEs6C/Kw47 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHCdLlGtJV2b/2dsb2JhbABCA8I9exZzgh8BAQEEKRE/DAYBAgYRBAEBCxQJKBEUCQgCBAENBQiHeQMPDLgbDYlQBIw8gRGBFiEFCwcGC4JOYQOUZI0whReDCIFpPg X-IronPort-AV: E=Sophos;i="4.84,751,1355097600"; d="scan'208";a="181973304" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 27 Feb 2013 23:59:42 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r1RNxgU0001925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Feb 2013 23:59:42 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.82]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 17:59:41 -0600 From: "Shitanshu Shah (svshah)" To: "Black, David" , Brian E Carpenter , "draft-ietf-idr-sla-exchange.all@tools.ietf.org" Thread-Topic: I-D Action: draft-ietf-idr-sla-exchange-00.txt Thread-Index: AQHOFQxM0cBFOjlbZk+SD9PaSGdNOZiOQWGA Importance: high X-Priority: 1 Date: Wed, 27 Feb 2013 23:59:41 +0000 Message-ID: In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7128F9F7114@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.154.208.247] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-sla-exchange-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 00:45:06 -0000 Hi David, In the context of this discussion, couple of important points of motivation/consideration for sla-exchange draft - It is critical to have Diffserv support in SLA exchange. However, at the same time, it should not be limited to Diffserv only. The SLA exchange language in draft-ietf-idr-sla-exchange-00.txt should work for other types of classification rules as well - Current stat of SLA exchange draft does not intend to standardize any code-point or PHB. Rather defined language in the draft merely refers standards defined outside the context. You have precisely captured in your comments that SLA exchange draft is more descriptive in contrast to diffserv-intercon which is more prescriptive An additional note, SLA exchange may be among nodes in the same administrative domain or across. To support earlier use-case, draft should not have to mandate traffic class definition exchanged be based on specific standards only. Unfortunately, I will not be able to make it to IETF this time. However, I know Keyur (co-author) will be there and possibly other co-authors of the draft. It surely will be good to have a conversation among key people and as per outcome, we can have a further follow-up? Regards, Shitanshu On 2/27/13 9:01 AM, "Black, David" wrote: >With my tsvwg WG co-chair hat on, I strongly concur with Brian that this >idr-sla-exchange draft needs to be discussed in the tsvwg WG. In Orlando, >the tsvwg WG meeting expects to take up: > > draft-geib-tsvwg-diffserv-intercon-02.txt > https://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/ > >which is considerably more prescriptive, in contrast to the >idr-sla-exchange draft's descriptive approach. > >While that diffserv-intercon draft is not a WG draft, the tsvwg WG does >intend to do work in this area, so some coordination to have a single >overall approach seems advisable. This does *not* imply a priori that >we need to select one draft and drop the other, and I surely do not want >to work on BGP details in tsvwg ;-). > >Unfortunately the idr and tsvarea (Transport Area open meeting) sessions >conflict on Wednesday morning in Orlando - would it make sense to take an >initial look at this idr-sla-exchange draft during the Monday afternoon >tsvwg session where there are conflicts with any routing WG meeting, and >perhaps have key people talk privately afterwards ? > >Thanks, >--David (tsvwg WG co-chair) >---------------------------------------------------- >David L. Black, Distinguished Engineer >EMC Corporation, 176 South St., Hopkinton, MA 01748 >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >david.black@emc.com Mobile: +1 (978) 394-7754 >---------------------------------------------------- > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Monday, January 07, 2013 10:25 AM >> To: draft-ietf-idr-sla-exchange.all@tools.ietf.org >> Cc: tsvwg-chairs@ietf.org; idr@ietf.org >> Subject: Re: I-D Action: draft-ietf-idr-sla-exchange-00.txt >>=20 >> Hi, >>=20 >> I don't understand which reference model for inter-domain SLAs >> is being used here. There is an arbitrary list of element types >> (IP_DSCP, MPLS_TC, 802_1Q_COS, 802_1Q_DEI, PHB_ID) and then >> an arbitrary list of some QoS metrics. Presumably some of those >> metrics map on to some of the element types, but it isn't obvious >> and I am certain there are gaps. >>=20 >> I don't think you can answer this with the text at the end of >> Section 6: >>=20 >> > There are well-defined recommendations that exist for traffic class >> > mapping between two technologies. Receiver MAY use those defined >> > recommendations for traffic class mapping or MAY define its own as >> > per its network Traffic Class service definition to map to >>advertised >> > Traffic Classes. It is completely up to the receiver how to define >> > such traffic class mapping. >>=20 >> Firstly, if there are such recommendations, they should be given as >> references. Secondly, why was the arbitrary set of QoS metrics chosen >> and how do we know that they are necessary and sufficient? (For >> example, I don't see any metric for drop rate, and for some traffic >> classes that is an important metric.) >>=20 >> I think this draft needs to be discussed in TSVWG before it goes >> much further. A consistent model for QoS metric signalling is needed >> before we standardise a mapping onto IDR. >>=20 >> Nits >> ---- >>=20 >> [RFC2474], [RFC2475] and [RFC3140] are listed as references >> (presumably for IP_DSCP and PHB_ID) but they are not cited in the >> text. That will not get through the final ID-nits check. >>=20 >> Also [RFC2475] is listed as a Normative reference, but it should >> be Informative. >>=20 >> Why is [RFC3552] listed as a reference? >>=20 >> Why is *obsoleted* [RFC1771] listed as a reference? >>=20 >> Why is [RFC4760] *not* listed, since this needs to work for IPv6? >>=20 >> The English in this draft is quite painful in many places. Here >> is one sentence chosen at random: >>=20 >> > Taking same voice service as an >> > example, given Provider already may provision definition of EF code- >> > point for such, signaling this code-point traffic class from PE to >>CE >> > along with low latency service definition, omits administrator at >>the >> > CE to worry about such translation. >>=20 >> I'm guessing that this means: >>=20 >> Taking voice service as an >> example, a given provider might already provision the EF code- >> point for such traffic. Signaling the code-point for this traffic >>class >> from PE to CE, >> with a low latency service definition, would avoid manual operations >>by the >> administrator at the >> CE. >>=20 >> Please run ID-nits and fix the 2 errors and 11 warnings. >>=20 >> Regards >> Brian Carpenter > From mohamed.boucadair@orange.com Wed Feb 27 23:46:08 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E39F21F8B61; Wed, 27 Feb 2013 23:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjuZP+H2wYOO; Wed, 27 Feb 2013 23:46:07 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8ED21F8B2F; Wed, 27 Feb 2013 23:46:04 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 42F40324989; Thu, 28 Feb 2013 08:46:03 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2381735C045; Thu, 28 Feb 2013 08:46:03 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Thu, 28 Feb 2013 08:46:03 +0100 From: To: "Black, David" , Brian E Carpenter , "draft-ietf-idr-sla-exchange.all@tools.ietf.org" Date: Thu, 28 Feb 2013 08:46:01 +0100 Thread-Topic: I-D Action: draft-ietf-idr-sla-exchange-00.txt Thread-Index: Ac3s61OxM/ecaM+rQWWQte+2/QAs6woGBuogACCTnhA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EB47D73FF@PUEXCB1B.nanterre.francetelecom.fr> References: <20130103205630.3871.46704.idtracker@ietfa.amsl.com> <50EAE8D9.5090200@gmail.com> <8D3D17ACE214DC429325B2B98F3AE7128F9F7114@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7128F9F7114@MX15A.corp.emc.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.28.65119 Cc: "idr@ietf.org" , "tsvwg-chairs@ietf.org" Subject: Re: [Idr] I-D Action: draft-ietf-idr-sla-exchange-00.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 07:46:08 -0000 Dear David, I'm aware of dafft-geib-* and I'm following that work. As far as I'm concer= ned (not as a co-author of draft-ietf-idr-sla-exchange), I provided comment= s to draft-geib-* several times; see for instance: * http://www.ietf.org/mail-archive/web/tsvwg/current/msg11713.html * http://www.ietf.org/mail-archive/web/tsvwg/current/msg11594.html IMHO, draft-ietf-idr-sla-exchange and dafft-geib-* are not competing approa= ches.=20 Saying that, I fully agree with you presenting draft-ietf-idr-sla-exchange = in tsvwg would help in clarifying the scope and the goals for this work.=20 Cheers, Med >-----Message d'origine----- >De : Black, David [mailto:david.black@emc.com]=20 >Envoy=E9 : mercredi 27 f=E9vrier 2013 18:02 >=C0 : Brian E Carpenter; draft-ietf-idr-sla-exchange.all@tools.ietf.org >Cc : tsvwg-chairs@ietf.org; idr@ietf.org >Objet : RE: I-D Action: draft-ietf-idr-sla-exchange-00.txt >Importance : Haute > >With my tsvwg WG co-chair hat on, I strongly concur with Brian=20 >that this >idr-sla-exchange draft needs to be discussed in the tsvwg WG. =20 >In Orlando, >the tsvwg WG meeting expects to take up: > > draft-geib-tsvwg-diffserv-intercon-02.txt > https://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/ > >which is considerably more prescriptive, in contrast to the >idr-sla-exchange draft's descriptive approach. > >While that diffserv-intercon draft is not a WG draft, the tsvwg WG does >intend to do work in this area, so some coordination to have a single >overall approach seems advisable. This does *not* imply a priori that >we need to select one draft and drop the other, and I surely=20 >do not want >to work on BGP details in tsvwg ;-). > >Unfortunately the idr and tsvarea (Transport Area open=20 >meeting) sessions >conflict on Wednesday morning in Orlando - would it make sense=20 >to take an >initial look at this idr-sla-exchange draft during the Monday afternoon >tsvwg session where there are conflicts with any routing WG=20 >meeting, and >perhaps have key people talk privately afterwards ? > >Thanks, >--David (tsvwg WG co-chair) >---------------------------------------------------- >David L. Black, Distinguished Engineer >EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 >+1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-77= 86 >david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 >---------------------------------------------------- > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] >> Sent: Monday, January 07, 2013 10:25 AM >> To: draft-ietf-idr-sla-exchange.all@tools.ietf.org >> Cc: tsvwg-chairs@ietf.org; idr@ietf.org >> Subject: Re: I-D Action: draft-ietf-idr-sla-exchange-00.txt >>=20 >> Hi, >>=20 >> I don't understand which reference model for inter-domain SLAs >> is being used here. There is an arbitrary list of element types >> (IP_DSCP, MPLS_TC, 802_1Q_COS, 802_1Q_DEI, PHB_ID) and then >> an arbitrary list of some QoS metrics. Presumably some of those >> metrics map on to some of the element types, but it isn't obvious >> and I am certain there are gaps. >>=20 >> I don't think you can answer this with the text at the end of >> Section 6: >>=20 >> > There are well-defined recommendations that exist for=20 >traffic class >> > mapping between two technologies. Receiver MAY use those defined >> > recommendations for traffic class mapping or MAY define=20 >its own as >> > per its network Traffic Class service definition to map=20 >to advertised >> > Traffic Classes. It is completely up to the receiver=20 >how to define >> > such traffic class mapping. >>=20 >> Firstly, if there are such recommendations, they should be given as >> references. Secondly, why was the arbitrary set of QoS metrics chosen >> and how do we know that they are necessary and sufficient? (For >> example, I don't see any metric for drop rate, and for some traffic >> classes that is an important metric.) >>=20 >> I think this draft needs to be discussed in TSVWG before it goes >> much further. A consistent model for QoS metric signalling is needed >> before we standardise a mapping onto IDR. >>=20 >> Nits >> ---- >>=20 >> [RFC2474], [RFC2475] and [RFC3140] are listed as references >> (presumably for IP_DSCP and PHB_ID) but they are not cited in the >> text. That will not get through the final ID-nits check. >>=20 >> Also [RFC2475] is listed as a Normative reference, but it should >> be Informative. >>=20 >> Why is [RFC3552] listed as a reference? >>=20 >> Why is *obsoleted* [RFC1771] listed as a reference? >>=20 >> Why is [RFC4760] *not* listed, since this needs to work for IPv6? >>=20 >> The English in this draft is quite painful in many places. Here >> is one sentence chosen at random: >>=20 >> > Taking same voice service as an >> > example, given Provider already may provision definition=20 >of EF code- >> > point for such, signaling this code-point traffic class=20 >from PE to CE >> > along with low latency service definition, omits=20 >administrator at the >> > CE to worry about such translation. >>=20 >> I'm guessing that this means: >>=20 >> Taking voice service as an >> example, a given provider might already provision the EF code- >> point for such traffic. Signaling the code-point for this=20 >traffic class >> from PE to CE, >> with a low latency service definition, would avoid manual=20 >operations by the >> administrator at the >> CE. >>=20 >> Please run ID-nits and fix the 2 errors and 11 warnings. >>=20 >> Regards >> Brian Carpenter > >= From yakov@juniper.net Thu Feb 28 06:28:50 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBCC21F8B0A for ; Thu, 28 Feb 2013 06:28:45 -0800 (PST) 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=[BAYES_00=-2.599, 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 usIr9edf+g24 for ; Thu, 28 Feb 2013 06:28:40 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3622321F84D9 for ; Thu, 28 Feb 2013 06:28:10 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKUS9peuCSvJEKHsiKxcuSPyxUDtZoWDT3@postini.com; Thu, 28 Feb 2013 06:28:10 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 28 Feb 2013 06:24:57 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r1SEOt345070 for ; Thu, 28 Feb 2013 06:24:56 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201302281424.r1SEOt345070@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <46675.1362061495.1@juniper.net> Date: Thu, 28 Feb 2013 06:24:55 -0800 From: Yakov Rekhter Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:28:50 -0000 John and Sue, > Folks, > > The authors have requested IDR adopt draft-simpson-idr-flowspec-redirect-02 > as a working group document. Support. Yakov. From wim.henderickx@alcatel-lucent.com Thu Feb 28 06:30:56 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45BD21F8B6E for ; Thu, 28 Feb 2013 06:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 81Q0jP7d42gv for ; Thu, 28 Feb 2013 06:30:56 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id E27CF21F8B2F for ; Thu, 28 Feb 2013 06:30:55 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1SEQCKj006604 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Feb 2013 15:30:53 +0100 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 28 Feb 2013 15:30:44 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.76]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 28 Feb 2013 15:30:43 +0100 From: "Henderickx, Wim (Wim)" To: Yakov Rekhter , "idr@ietf.org" Thread-Topic: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 Thread-Index: AQHOFcAwqoZ9jQPkbEeO8SgdassD7Q== Date: Thu, 28 Feb 2013 14:30:43 +0000 Message-ID: In-Reply-To: <201302281424.r1SEOt345070@magenta.juniper.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:30:56 -0000 +1 support as co-author On 28/02/13 06:24, "Yakov Rekhter" wrote: >John and Sue, >=20 >> Folks, >>=20 >> The authors have requested IDR adopt >>draft-simpson-idr-flowspec-redirect-02 >> as a working group document. > >Support. > >Yakov. >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr From ss2539@att.com Thu Feb 28 06:47:35 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDB721F85A0 for ; Thu, 28 Feb 2013 06:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[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 vnygWeXT8iVj for ; Thu, 28 Feb 2013 06:47:34 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6719C21F8563 for ; Thu, 28 Feb 2013 06:47:34 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 50e6f215.0.254393.00-408.693289.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 28 Feb 2013 14:47:34 +0000 (UTC) X-MXL-Hash: 512f6e0660b17eb0-60c08245702cfe1bbf3d316f1d2129a0b95bab14 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1SElXo4002547; Thu, 28 Feb 2013 09:47:33 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1SElRRw002475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 09:47:28 -0500 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by sflint01.pst.cso.att.com (RSA Interceptor); Thu, 28 Feb 2013 09:47:13 -0500 Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0328.009; Thu, 28 Feb 2013 09:47:05 -0500 From: "SAAD, SAMIR S" To: "idr@ietf. org" Thread-Topic: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 Thread-Index: AQHOC8MdSR8y1pCB2UGfYck3zMOQ/5iPbM8g Date: Thu, 28 Feb 2013 14:47:04 +0000 Message-ID: <438B11A5EC21D347A63ACB77E58C78BA06C52256@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <3BD8D5C8-77D5-40C6-8BC2-B8B839463544@juniper.net> In-Reply-To: <3BD8D5C8-77D5-40C6-8BC2-B8B839463544@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.221.131] Content-Type: multipart/alternative; boundary="_000_438B11A5EC21D347A63ACB77E58C78BA06C52256MISOUT7MSGUSR9N_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Otj4PVDt c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=0gqfc6T_GjYA:10 a=qC7xIHkC-d4A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=_FvKi29JT] X-AnalysisOut: [LAA:10 a=48vgC7mUAAAA:8 a=igP6x1RvhjIvZTal5SsA:9 a=CjuIK1q] X-AnalysisOut: [_8ugA:10 a=lZB815dzVvQA:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA] X-AnalysisOut: [:8 a=ujr85ydN6hoQxXto_bYA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S] X-AnalysisOut: [4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=59yU7GUpX7k8BP] X-AnalysisOut: [gj:21] Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:47:35 -0000 --_000_438B11A5EC21D347A63ACB77E58C78BA06C52256MISOUT7MSGUSR9N_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Samir Saad AT&T Labs From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John = Scudder Sent: Friday, February 15, 2013 4:26 PM To: idr@ietf. org Subject: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirec= t-02 Folks, The authors have requested IDR adopt draft-simpson-idr-flowspec-redirect-02= as a working group document. Please send any comments to the list by March 1. Thanks, --John & Sue --_000_438B11A5EC21D347A63ACB77E58C78BA06C52256MISOUT7MSGUSR9N_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support

 

Samir Saad

AT&T Labs

 <= /p>

From: idr-boun= ces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of John Scudder
Sent: Friday, February 15, 2013 4:26 PM
To: idr@ietf. org
Subject: [Idr] WG adoption requested for draft-simpson-idr-flowspec-= redirect-02

 

Folks,

The authors have requested IDR adopt draft-simpson-idr-flowspec-redire= ct-02 as a working group document.

Please send any comments to the list by March 1.

Thanks,

--John & Sue

--_000_438B11A5EC21D347A63ACB77E58C78BA06C52256MISOUT7MSGUSR9N_-- From roberto.fragassi@alcatel-lucent.com Thu Feb 28 06:50:02 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A69D21F84B0 for ; Thu, 28 Feb 2013 06:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 h3216qWs2pap for ; Thu, 28 Feb 2013 06:50:01 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28121F84A9 for ; Thu, 28 Feb 2013 06:50:01 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1SEmwmH018538 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Feb 2013 15:49:58 +0100 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 28 Feb 2013 15:49:37 +0100 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.135]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Thu, 28 Feb 2013 09:49:35 -0500 From: "Fragassi, Roberto (Roberto)" To: "Henderickx, Wim (Wim)" , Yakov Rekhter , "idr@ietf.org" Thread-Topic: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 Thread-Index: AQHOFcBCd88F6fRiDEeHnhGSWbXqgJiPWgoQ Date: Thu, 28 Feb 2013 14:49:35 +0000 Message-ID: References: <201302281424.r1SEOt345070@magenta.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:50:02 -0000 Read and support. -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Hende= rickx, Wim (Wim) Sent: Thursday, February 28, 2013 9:31 AM To: Yakov Rekhter; idr@ietf.org Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-red= irect-02 +1 support as co-author On 28/02/13 06:24, "Yakov Rekhter" wrote: >John and Sue, >=20 >> Folks, >>=20 >> The authors have requested IDR adopt >>draft-simpson-idr-flowspec-redirect-02 >> as a working group document. > >Support. > >Yakov. >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From ju1738@att.com Thu Feb 28 06:57:37 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4527321F86D5 for ; Thu, 28 Feb 2013 06:57:37 -0800 (PST) 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=[BAYES_00=-2.599, 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 PlL5iPcB6ZRF for ; Thu, 28 Feb 2013 06:57:36 -0800 (PST) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD3321F8534 for ; Thu, 28 Feb 2013 06:57:36 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 0607f215.70f49940.258748.00-549.705740.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 28 Feb 2013 14:57:36 +0000 (UTC) X-MXL-Hash: 512f706006dede34-658e916226a918112525ac935aa97d54e61d00ce Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id f507f215.0.258746.00-359.705729.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 28 Feb 2013 14:57:36 +0000 (UTC) X-MXL-Hash: 512f70602b3c652f-f90a2f5e01ea09f94baf3e7b01568ace373c6848 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1SEvZrv011084; Thu, 28 Feb 2013 09:57:35 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r1SEvVZp011031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 09:57:32 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by sflint02.pst.cso.att.com (RSA Interceptor); Thu, 28 Feb 2013 09:57:19 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0328.009; Thu, 28 Feb 2013 09:57:19 -0500 From: "UTTARO, JAMES" To: "'Henderickx, Wim (Wim)'" , "Yakov Rekhter" , "idr@ietf.org" Thread-Topic: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 Thread-Index: AQHOFcAwqoZ9jQPkbEeO8SgdassD7ZiPXENQ Date: Thu, 28 Feb 2013 14:57:18 +0000 Message-ID: References: <201302281424.r1SEOt345070@magenta.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.138.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=Otj4PVDt c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=8yMdQ3rZCb0A:10 a=qC7xIHkC-d4A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=_FvKi29JTLAA:10 a=48vgC7mUAAAA:8 a=OUXY8nFuAAAA:8] X-AnalysisOut: [ a=WfuU9QPeUD1ufSfEzB8A:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA] X-AnalysisOut: [:10 a=peF9eE_zjQwA:10] Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:57:37 -0000 +1 support as co-author -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Hende= rickx, Wim (Wim) Sent: Thursday, February 28, 2013 9:31 AM To: Yakov Rekhter; idr@ietf.org Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-red= irect-02 +1 support as co-author On 28/02/13 06:24, "Yakov Rekhter" wrote: >John and Sue, >=20 >> Folks, >>=20 >> The authors have requested IDR adopt >>draft-simpson-idr-flowspec-redirect-02 >> as a working group document. > >Support. > >Yakov. >_______________________________________________ >Idr mailing list >Idr@ietf.org >https://www.ietf.org/mailman/listinfo/idr _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From bduvivie@cisco.com Thu Feb 28 07:00:36 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAA521F8A09 for ; Thu, 28 Feb 2013 07:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0gU1WeoTjy2 for ; Thu, 28 Feb 2013 07:00:35 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EEC4121F85A0 for ; Thu, 28 Feb 2013 07:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1159; q=dns/txt; s=iport; t=1362063635; x=1363273235; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EmiBCM1rmEpKov59NwkeeEwHwcaH5ILYW07EVDKOlE4=; b=LPck/VUNUBF5v1IfV8sohdiYts7jbgkKZJ/59HPrIZiArFXy2SBPkfjC 7R337WqxiCJWPOWxuxCmcYophO4EAw4CDjTNosGqUxAlcWRPhjRRHiqOD aS1Drkl7W8yfjgZoDoJw9WIfLaZUls3kj3s1avU6lr4BDZGwMeGE7K+N6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALNuL1GtJXHA/2dsb2JhbABFwix6FnOCHwEBAQQBAQFrCwwEAgEIEQQBAQEnBycLFAkIAgQOBYgTDMFeBI5hMwcGgllhA4g0jg2QaoMI X-IronPort-AV: E=Sophos;i="4.84,755,1355097600"; d="scan'208";a="182237367" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 28 Feb 2013 15:00:34 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1SF0WF5027365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Feb 2013 15:00:32 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 09:00:32 -0600 From: "Bertrand Duvivier (bduvivie)" To: "UTTARO, JAMES" Thread-Topic: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 Thread-Index: AQHOFcAwd88F6fRiDEeHnhGSWbXqgJiPXENQgAAA8ko= Date: Thu, 28 Feb 2013 15:00:31 +0000 Message-ID: References: <201302281424.r1SEOt345070@magenta.juniper.net> , In-Reply-To: Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Yakov Rekhter , "idr@ietf.org" Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 15:00:36 -0000 +1=20 Envoy=E9 de mon iPhone Le 28 Feb 2013 =E0 15:57, "UTTARO, JAMES" a =E9crit : > +1 support as co-author >=20 > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Hen= derickx, Wim (Wim) > Sent: Thursday, February 28, 2013 9:31 AM > To: Yakov Rekhter; idr@ietf.org > Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-r= edirect-02 >=20 > +1 support as co-author >=20 > On 28/02/13 06:24, "Yakov Rekhter" wrote: >=20 >> John and Sue, >>=20 >>> Folks, >>>=20 >>> The authors have requested IDR adopt >>> draft-simpson-idr-flowspec-redirect-02 >>> as a working group document. >>=20 >> Support. >>=20 >> Yakov. >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From pierre.francois@imdea.org Thu Feb 28 07:01:58 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3974221F8AE6 for ; Thu, 28 Feb 2013 07:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECM+gZH4V38l for ; Thu, 28 Feb 2013 07:01:57 -0800 (PST) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6F43421F8AC3 for ; Thu, 28 Feb 2013 07:01:57 -0800 (PST) Received: from localhost (estafeta21.imdea.org [172.17.99.144]) by estafeta21.imdea.org (Postfix) with ESMTP id 2585B18BD9B for ; Thu, 28 Feb 2013 16:01:56 +0100 (CET) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.144]) by localhost (estafeta21.imdea.org [172.17.99.144]) (amavisd-new, port 10024) with ESMTP id 1-u8WEvqbZ+J for ; Thu, 28 Feb 2013 16:01:55 +0100 (CET) Received: from ams3-vpn-dhcp5974.cisco.com (64-103-25-233.cisco.com [64.103.25.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (Postfix) with ESMTP id A262718BD9A for ; Thu, 28 Feb 2013 16:01:55 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Pierre Francois In-Reply-To: Date: Thu, 28 Feb 2013 16:01:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3333ED16-0837-4244-93AD-D4C420963D0B@imdea.org> References: <201302281424.r1SEOt345070@magenta.juniper.net> , To: idr@ietf.org X-Mailer: Apple Mail (2.1499) Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 15:01:58 -0000 +1 Pierre. On Feb 28, 2013, at 4:00 PM, "Bertrand Duvivier (bduvivie)" = wrote: > +1=20 >=20 > Envoy=E9 de mon iPhone >=20 > Le 28 Feb 2013 =E0 15:57, "UTTARO, JAMES" a =E9crit : >=20 >> +1 support as co-author >>=20 >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of = Henderickx, Wim (Wim) >> Sent: Thursday, February 28, 2013 9:31 AM >> To: Yakov Rekhter; idr@ietf.org >> Subject: Re: [Idr] WG adoption requested for = draft-simpson-idr-flowspec-redirect-02 >>=20 >> +1 support as co-author >>=20 >> On 28/02/13 06:24, "Yakov Rekhter" wrote: >>=20 >>> John and Sue, >>>=20 >>>> Folks, >>>>=20 >>>> The authors have requested IDR adopt >>>> draft-simpson-idr-flowspec-redirect-02 >>>> as a working group document. >>>=20 >>> Support. >>>=20 >>> Yakov. >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From paul@unbehagen.net Thu Feb 28 09:30:46 2013 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8886221F8A53 for ; Thu, 28 Feb 2013 09:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 YPoFeLYMLV7k for ; Thu, 28 Feb 2013 09:30:46 -0800 (PST) Received: from mail-gh0-f173.google.com (mail-gh0-f173.google.com [209.85.160.173]) by ietfa.amsl.com (Postfix) with ESMTP id 08F4721F89C0 for ; Thu, 28 Feb 2013 09:30:45 -0800 (PST) Received: by mail-gh0-f173.google.com with SMTP id g2so302634ghb.32 for ; Thu, 28 Feb 2013 09:30:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:references:from:content-type:x-mailer :in-reply-to:message-id:date:to:content-transfer-encoding :mime-version:x-gm-message-state; bh=heIgfgpd3nxB7yM2ACnfiQenwVeHVClm/cQk8tv4hbw=; b=P3G5P5z4gLblcijWZKnn/q77H/cdXr88lRCweTftVtpYHiBAeBwD3VFv9ZOz7ep8DG ShimiMYKk/RfQbYvSpfs7ERnS85qmuG+FfopV2ssUFRRi5dh5rX4x8sHluhQu9fDz0u8 dZRN5jVoIBoBslzo0qqSdmLu9Ga+bmvldSqn6frzJlMvSYqbm91KKeALarPGGYoSKuS9 3mDRF6Cp7MmA1jn7lLRi+SnjYAKSKeOzsTDEhJe6ybCGdRPfONEf2BXAbKtZ13OR39Tj pNGJlOZPYJiH8d+shnmay1Ax0jjf+e3I/qwKvXT1LbdwvwlnOnFixeeBACEtFLcedpQt Ld4Q== X-Received: by 10.236.127.179 with SMTP id d39mr5224927yhi.20.1362072645256; Thu, 28 Feb 2013 09:30:45 -0800 (PST) Received: from [10.238.72.52] (mobile-166-147-119-213.mycingular.net. [166.147.119.213]) by mx.google.com with ESMTPS id d43sm10237239yhk.23.2013.02.28.09.30.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:30:43 -0800 (PST) References: <201302281424.r1SEOt345070@magenta.juniper.net> From: Paul Unbehagen Content-Type: text/plain; charset=utf-8 X-Mailer: iPhone Mail (10B146) In-Reply-To: Message-Id: Date: Thu, 28 Feb 2013 12:30:39 -0500 To: "idr@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQnPOm3ppHPG/d3NXMuIKLcSd8I7HKEmIcv6WoNIz4rSEt7CrdP7/29F5QQ/l0EEiCQDSfDO Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-redirect-02 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 17:30:46 -0000 +1 On Feb 28, 2013, at 10:00 AM, "Bertrand Duvivier (bduvivie)" wrote: > +1=20 >=20 > Envoy=C3=A9 de mon iPhone >=20 > Le 28 Feb 2013 =C3=A0 15:57, "UTTARO, JAMES" a =C3=A9crit= : >=20 >> +1 support as co-author >>=20 >> -----Original Message----- >> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Hen= derickx, Wim (Wim) >> Sent: Thursday, February 28, 2013 9:31 AM >> To: Yakov Rekhter; idr@ietf.org >> Subject: Re: [Idr] WG adoption requested for draft-simpson-idr-flowspec-r= edirect-02 >>=20 >> +1 support as co-author >>=20 >> On 28/02/13 06:24, "Yakov Rekhter" wrote: >>=20 >>> John and Sue, >>>=20 >>>> Folks, >>>>=20 >>>> The authors have requested IDR adopt >>>> draft-simpson-idr-flowspec-redirect-02 >>>> as a working group document. >>>=20 >>> Support. >>>=20 >>> Yakov. >>> _______________________________________________ >>> Idr mailing list >>> Idr@ietf.org >>> https://www.ietf.org/mailman/listinfo/idr >>=20 >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr