From wwwrun@rfc-editor.org Fri Jun 28 03:39: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 8967521F9C49 for ; Fri, 28 Jun 2013 03:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHUIwWbMMQRO for ; Fri, 28 Jun 2013 03:39:21 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B6B1621F9C47 for ; Fri, 28 Jun 2013 03:39:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A43D162114; Fri, 28 Jun 2013 03:36:35 -0700 (PDT) To: yakov@juniper.net, tony.li@tony.li, skh@nexthop.com, stbryant@cisco.com, adrian@olddog.co.uk, shares@ndzh.com, jgs@juniper.net From: RFC Errata System Message-Id: <20130628103635.A43D162114@rfc-editor.org> Date: Fri, 28 Jun 2013 03:36:35 -0700 (PDT) X-Mailman-Approved-At: Mon, 01 Jul 2013 08:10:28 -0700 Cc: idr@ietf.org, william.mccall@gmail.com, rfc-editor@rfc-editor.org Subject: [Idr] [Technical Errata Reported] RFC4271 (3673) 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, 28 Jun 2013 10:39:27 -0000 The following errata report has been submitted for RFC4271, "A Border Gateway Protocol 4 (BGP-4)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=3673 -------------------------------------- Type: Technical Reported by: William McCall Section: 5 Original Text ------------- Path attributes fall into four separate categories: 1. Well-known mandatory. 2. Well-known discretionary. 3. Optional transitive. 4. Optional non-transitive. Corrected Text -------------- Path attributes fall into five separate categories: 1. Well-known mandatory. 2. Well-known discretionary. 3. Well-known. 4. Optional transitive. 5. Optional non-transitive. Notes ----- Local pref is only a "well-known" attribute as it fails the definition for the behavior as a mandatory attribute and it is not exactly discretionary per 5.1.5's definition of local pref and section 5's definition of discretionary which states: "5.1.5. LOCAL_PREF LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers." Section 5's definition of discretionary: " [...]Others are discretionary and MAY or MAY NOT be sent in a particular UPDATE message." As a well-known mandatory attribute would result in a NOTIFICATION per section 6.3, it cannot be well-known mandatory because it is only for internal peers. Thus, it is a separate category. 6.3 " If any of the well-known mandatory attributes are not present, then the Error Subcode MUST be set to Missing Well-known Attribute. The Data field MUST contain the Attribute Type Code of the missing, well-known attribute." In a future revision, a new term would probably be best to describe this. However, the categorization of attributes is misleading for now and the simplest approach is to add the new category already used by 5.1.5. 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. -------------------------------------- RFC4271 (draft-ietf-idr-bgp4-26) -------------------------------------- Title : A Border Gateway Protocol 4 (BGP-4) Publication Date : January 2006 Author(s) : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed. Category : DRAFT STANDARD Source : Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From jgs@juniper.net Mon Jul 1 12:46: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 19BB111E825F for ; Mon, 1 Jul 2013 12:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgBEg2580Qcp for ; Mon, 1 Jul 2013 12:46:31 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id D588B11E826E for ; Mon, 1 Jul 2013 12:46:30 -0700 (PDT) Received: from mail89-db9-R.bigfish.com (10.174.16.230) by DB9EHSOBE034.bigfish.com (10.174.14.97) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Jul 2013 19:46:29 +0000 Received: from mail89-db9 (localhost [127.0.0.1]) by mail89-db9-R.bigfish.com (Postfix) with ESMTP id 9C1A0800C2 for ; Mon, 1 Jul 2013 19:46:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.50; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fh103dKzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2fh2a8h683h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1b2bh1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e23h1e64h1155h) Received-SPF: pass (mail89-db9: domain of juniper.net designates 66.129.224.50 as permitted sender) client-ip=66.129.224.50; envelope-from=jgs@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:132.245.2.21; KIP:(null); UIP:(null); (null); H:BN1PRD0512HT002.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail89-db9 (localhost.localdomain [127.0.0.1]) by mail89-db9 (MessageSwitch) id 1372707988350880_32734; Mon, 1 Jul 2013 19:46:28 +0000 (UTC) Received: from DB9EHSMHS025.bigfish.com (unknown [10.174.16.243]) by mail89-db9.bigfish.com (Postfix) with ESMTP id 50ED62C004B for ; Mon, 1 Jul 2013 19:46:28 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.50) by DB9EHSMHS025.bigfish.com (10.174.14.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 1 Jul 2013 19:46:28 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 1 Jul 2013 12:46:26 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Mon, 1 Jul 2013 12:46:25 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.30) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 1 Jul 2013 12:58:14 -0700 Received: from mail9-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.23; Mon, 1 Jul 2013 19:46:24 +0000 Received: from mail9-va3 (localhost [127.0.0.1]) by mail9-va3-R.bigfish.com (Postfix) with ESMTP id 50B47E00CE for ; Mon, 1 Jul 2013 19:46:24 +0000 (UTC) Received: from mail9-va3 (localhost.localdomain [127.0.0.1]) by mail9-va3 (MessageSwitch) id 1372707982930205_15523; Mon, 1 Jul 2013 19:46:22 +0000 (UTC) Received: from VA3EHSMHS007.bigfish.com (unknown [10.7.14.226]) by mail9-va3.bigfish.com (Postfix) with ESMTP id D550B2C004F for ; Mon, 1 Jul 2013 19:46:22 +0000 (UTC) Received: from BN1PRD0512HT002.namprd05.prod.outlook.com (132.245.2.21) by VA3EHSMHS007.bigfish.com (10.7.99.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 1 Jul 2013 19:46:22 +0000 Received: from [172.28.130.210] (66.129.232.2) by pod51010.outlook.com (10.255.193.35) with Microsoft SMTP Server (TLS) id 14.16.324.0; Mon, 1 Jul 2013 19:46:21 +0000 From: "John G. Scudder" Content-Type: multipart/alternative; boundary="Apple-Mail=_8226C7BA-8589-450E-A481-834EC1850E2D" Message-ID: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> Date: Mon, 1 Jul 2013 15:46:18 -0400 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) 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 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG document 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, 01 Jul 2013 19:46:38 -0000 --Apple-Mail=_8226C7BA-8589-450E-A481-834EC1850E2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Folks, On May 29 the authors requested WG adoption of = draft-jhjm-idr-last-as-reservations-00. There was not much response -- = two supportive replies, not counting authors. This is not enough to = declare "WG consensus" or much of anything else. A short summary for those who aren't familiar with the draft: It = basically says "the last ASNs are already reserved, please be careful = with them". This seems to the chairs to be obviously true and useful to = document, but maybe it's SO obvious that WG members are not bothering to = say anything. It also seems to us that this doesn't demand much work = from the WG and is almost ready for publication as-is -- unless of = course we're wrong and there's controversy about the draft. So let's try this again. Please do reply, by July 8. In particular, if = you feel that we are mistaken and the draft is NOT a "no-brainer" for = the WG, you should say that because in this specific case, we might make = an exception and apply the rule "silence gives consent". Thanks! --John and Sue= --Apple-Mail=_8226C7BA-8589-450E-A481-834EC1850E2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

A short summary for those who aren't = familiar with the draft: It basically says "the last ASNs are = already reserved, please be careful with them". This seems to the chairs = to be obviously true and useful to document, but maybe it's SO obvious = that WG members are not bothering to say anything. It also seems to us = that this doesn't demand much work from the WG and is almost ready for = publication as-is -- unless of course we're wrong and there's = controversy about the draft.

So let's try this = again. Please do reply, by July 8. In particular, if you feel that we = are mistaken and the draft is NOT a "no-brainer" for the WG, you should = say that because in this specific case, we might make an exception and = apply the rule "silence gives = consent".

Thanks!

--John= and Sue
= --Apple-Mail=_8226C7BA-8589-450E-A481-834EC1850E2D-- From bdickson@verisign.com Mon Jul 1 13:37: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 BBCA411E8241 for ; Mon, 1 Jul 2013 13:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5KgauSYevTB for ; Mon, 1 Jul 2013 13:37:27 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id EE19111E8254 for ; Mon, 1 Jul 2013 13:37:24 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUdHogMosX76cnAfUZdoE5zWc15Vqj4M0@postini.com; Mon, 01 Jul 2013 13:37:26 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r61KbH1F031588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Jul 2013 16:37:17 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 1 Jul 2013 16:37:16 -0400 From: "Dickson, Brian" To: "John G. Scudder" , "idr@ietf. org" Thread-Topic: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG document Thread-Index: AQHOdpO4Il71Ro6KSk6ou+xZUNBvuplQSGIA Date: Mon, 1 Jul 2013 20:37:16 +0000 Message-ID: In-Reply-To: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_CDF7608EB60Cbdicksonverisigncom_" MIME-Version: 1.0 Subject: Re: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG document 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, 01 Jul 2013 20:37:32 -0000 --_000_CDF7608EB60Cbdicksonverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In favor, no brainer. Brian From: "John G. Scudder" > Date: Monday, July 1, 2013 3:46 PM To: "idr@ietf. org" > Subject: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG docume= nt Folks, On May 29 the authors requested WG adoption of draft-jhjm-idr-last-as-reser= vations-00. There was not much response -- two supportive replies, not coun= ting authors. This is not enough to declare "WG consensus" or much of anyth= ing else. A short summary for those who aren't familiar with the draft: It basically = says "the last ASNs are already reserved, please be careful with them". Thi= s seems to the chairs to be obviously true and useful to document, but mayb= e it's SO obvious that WG members are not bothering to say anything. It als= o seems to us that this doesn't demand much work from the WG and is almost = ready for publication as-is -- unless of course we're wrong and there's con= troversy about the draft. So let's try this again. Please do reply, by July 8. In particular, if you = feel that we are mistaken and the draft is NOT a "no-brainer" for the WG, y= ou should say that because in this specific case, we might make an exceptio= n and apply the rule "silence gives consent". Thanks! --John and Sue --_000_CDF7608EB60Cbdicksonverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1FE2654F10A0A041B937702E613859D7@verisign.com> Content-Transfer-Encoding: quoted-printable
In favor, no brainer.

Brian

From: "John G. Scudder" &= lt;jgs@juniper.net>
Date: Monday, July 1, 2013 3:46 PM<= br> To: "idr@ietf. org" <<= a href=3D"mailto:idr@ietf.org">idr@ietf.org>
Subject: [Idr] Second Try: draft-jh= jm-idr-last-as-reservations as WG document

Folks,

On May 29 the authors requested WG adoption of draft-jhjm-idr-last-as-= reservations-00. There was not much response -- two supportive replies, not= counting authors. This is not enough to declare "WG consensus" o= r much of anything else.

A short summary for those who aren't familiar with the draft: It = basically says "the last ASNs are already reserved, please be careful = with them". This seems to the chairs to be obviously true and useful t= o document, but maybe it's SO obvious that WG members are not bothering to say anything. It also seems to us that this doesn't d= emand much work from the WG and is almost ready for publication as-is -- un= less of course we're wrong and there's controversy about the draft.

So let's try this again. Please do reply, by July 8. In particular, if= you feel that we are mistaken and the draft is NOT a "no-brainer"= ; for the WG, you should say that because in this specific case, we might m= ake an exception and apply the rule "silence gives consent".

Thanks!

--John and Sue
 --_000_CDF7608EB60Cbdicksonverisigncom_-- From jeff.tantsura@ericsson.com Mon Jul 1 13:51: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 7864221F9C95 for ; Mon, 1 Jul 2013 13:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1q03k8aP-nnu for ; Mon, 1 Jul 2013 13:51:07 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 78B6F21F9C96 for ; Mon, 1 Jul 2013 13:51:07 -0700 (PDT) X-AuditID: c618062d-b7fc36d0000032ea-d9-51d1ebbaebe1 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 0C.3C.13034.ABBE1D15; Mon, 1 Jul 2013 22:51:06 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Mon, 1 Jul 2013 16:51:05 -0400 From: Jeff Tantsura To: "John G. Scudder" , "idr@ietf. org" Thread-Topic: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG document Thread-Index: AQHOdpO9n0Q4m4htXU2ZEXYl5IFAXplQGfAA Date: Mon, 1 Jul 2013 20:51:04 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C748393C5FCF@eusaamb109.ericsson.se> In-Reply-To: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C748393C5FCFeusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXSPn+6u1xcDDZ5uEbV4dfsZk8XMG19Z HZg8liz5yeRxvekqewBTFJdNSmpOZllqkb5dAlfGhifRBR9VK/pfb2BrYFym0MXIySEhYCKx pn01G4QtJnHh3nogm4tDSOAoo8TTr3vZQRJCAssYJQ4cjgax2QQMJP5/O84CYosIuEt0398E ViMsECzxfeJpVoh4iMTp31uhbCOJJR3fmEBsFgEViQfn24B6OTh4Bbwlrj9yADE5Bewl5k7n AalgBDrh+6k1YNXMAuISt57MZ4I4TUBiyZ7zzBC2qMTLx//AposK6Em0HTvDDhFXlvg+5xEL RG++xP/Fv8F6eQUEJU7OfMIygVFkFpKxs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx1C9 1hIzjjUxIatZwMixipGjtDi1LDfdyGATIzCejkmw6e5g3PPS8hCjNAeLkjjvKr0zgUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYjcR4HHhnfTXsPGv+RyrhSZtM3eqJWQ/7Mr+tvHj4eGzQ ZS6naz8luFPvmnw988F7To3Scc7vC6PaV7jrSi47vUkqi/nDeeNJM3b4O7zMvO95MsXbSr7k 7sRZVznZjmuLH2+O//JH+rrZWRMOK4umGWxFezeU7Ql6KRcvoP5Dcv6q/11Ld0a3KbEUZyQa ajEXFScCABSiPHh1AgAA Subject: Re: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG document 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, 01 Jul 2013 20:51:14 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C748393C5FCFeusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support/no-brainer Cheers, Jeff From: "John G. Scudder" > Date: Monday, July 1, 2013 12:46 PM To: "idr@ietf. org" > Subject: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG docume= nt Folks, On May 29 the authors requested WG adoption of draft-jhjm-idr-last-as-reser= vations-00. There was not much response -- two supportive replies, not coun= ting authors. This is not enough to declare "WG consensus" or much of anyth= ing else. A short summary for those who aren't familiar with the draft: It basically = says "the last ASNs are already reserved, please be careful with them". Thi= s seems to the chairs to be obviously true and useful to document, but mayb= e it's SO obvious that WG members are not bothering to say anything. It als= o seems to us that this doesn't demand much work from the WG and is almost = ready for publication as-is -- unless of course we're wrong and there's con= troversy about the draft. So let's try this again. Please do reply, by July 8. In particular, if you = feel that we are mistaken and the draft is NOT a "no-brainer" for the WG, y= ou should say that because in this specific case, we might make an exceptio= n and apply the rule "silence gives consent". Thanks! --John and Sue --_000_60DEDD93F5E54B4AB55647B8B6C748393C5FCFeusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <1E84AB7AB8185D4890C8DDBC34306A3B@ericsson.com> Content-Transfer-Encoding: quoted-printable
Support/no-brainer

Cheers,
Jeff

From: "John G. Scudder" &= lt;jgs@juniper.net>
Date: Monday, July 1, 2013 12:46 PM=
To: "idr@ietf. org" <<= a href=3D"mailto:idr@ietf.org">idr@ietf.org>
Subject: [Idr] Second Try: draft-jh= jm-idr-last-as-reservations as WG document

Folks,

On May 29 the authors requested WG adoption of draft-jhjm-idr-last-as-= reservations-00. There was not much response -- two supportive replies, not= counting authors. This is not enough to declare "WG consensus" o= r much of anything else.

A short summary for those who aren't familiar with the draft: It = basically says "the last ASNs are already reserved, please be careful = with them". This seems to the chairs to be obviously true and useful t= o document, but maybe it's SO obvious that WG members are not bothering to say anything. It also seems to us that this doesn't d= emand much work from the WG and is almost ready for publication as-is -- un= less of course we're wrong and there's controversy about the draft.

So let's try this again. Please do reply, by July 8. In particular, if= you feel that we are mistaken and the draft is NOT a "no-brainer"= ; for the WG, you should say that because in this specific case, we might m= ake an exception and apply the rule "silence gives consent".

Thanks!

--John and Sue
 --_000_60DEDD93F5E54B4AB55647B8B6C748393C5FCFeusaamb109ericsso_-- From farmer@umn.edu Mon Jul 1 14:16: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 64F4F11E8295 for ; Mon, 1 Jul 2013 14:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAMJpImQfT0B for ; Mon, 1 Jul 2013 14:16:41 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA0511E8292 for ; Mon, 1 Jul 2013 14:16:40 -0700 (PDT) Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 1 Jul 2013 16:16:28 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f170.google.com [209.85.223.170] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f170.google.com with SMTP id e11so10648862iej.29 for ; Mon, 01 Jul 2013 14:16:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=7LaqdgUQgjo+bre/Pvf7hUtAaZjZcr2TDTnnEKMbLtg=; b=m07LKtQDkCL/Zly5Bn3JfoUw8Hwb86S3zVJin7hLYKUejsyJz9IPovx4480NEtvJJe keeChKEyUQ3sj5VpruogkZnYll+yT+aL9/sSOa9BrOqcQTezy2mvD+C6qWpcEIcJm1Sw soX3fClxRbjn5qjqR7iW3fBbHiVcpZdzXLg2jJf3eivgaiGKUj1G8jov6DT+WBSB32Mf Laxg4eXD/J38xsG6EEIOPriPHDDb3tBoTNswd9KizRy/u00prV5XLfTm5615hyz7nqLC 6sAi6mKsQ++4TTihIcwXU2SnTSrYTgUbqcWW3q1WEJSKwtygKpF7v9ASVdnMOstl3wVn 38lg== X-Received: by 10.50.136.230 with SMTP id qd6mr17239241igb.4.1372713387921; Mon, 01 Jul 2013 14:16:27 -0700 (PDT) X-Received: by 10.50.136.230 with SMTP id qd6mr17239167igb.4.1372713386872; Mon, 01 Jul 2013 14:16:26 -0700 (PDT) Received: from x-128-101-232-25.uofm-secure.wireless.umn.edu (x-128-101-232-25.uofm-secure.wireless.umn.edu. [128.101.232.25]) by mx.google.com with ESMTPSA id ff19sm15013970igb.0.2013.07.01.14.16.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 01 Jul 2013 14:16:26 -0700 (PDT) Message-ID: <51D1F1A8.2080903@umn.edu> Date: Mon, 01 Jul 2013 16:16:24 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "John G. Scudder" References: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> In-Reply-To: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk92lfzNr+8Sx2xzjlLLv6+3++2fk729KxeSA0ugkyoJXXFAg0IrmQlshfCfQcgpuxWAkAFxK30B6L/TBP5V2UhYmHt/Fbv2SXhzWbByewd1AgpWWdH8mmi+taUUiQ3qICU7TM1 Cc: "idr@ietf. org" Subject: Re: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG document 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: Mon, 01 Jul 2013 21:16:46 -0000 I was one of the original two supporters, but will reaffirm my support of it as WG item and I believe it is a "no-brainer". I'll go further and say it provides important clarifications that need to be said authoritatively preferably by this WG or maybe GROW. I'd agree that with one good round of comments and a revision incorporating them, then it is probably ready to go. On 7/1/13 14:46 , John G. Scudder wrote: > Folks, > > On May 29 the authors requested WG adoption of > draft-jhjm-idr-last-as-reservations-00. There was not much response -- > two supportive replies, not counting authors. This is not enough to > declare "WG consensus" or much of anything else. > > A short summary for those who aren't familiar with the draft: > It basically says "the last ASNs are already reserved, please be careful > with them". This seems to the chairs to be obviously true and useful to > document, but maybe it's SO obvious that WG members are not bothering to > say anything. It also seems to us that this doesn't demand much work > from the WG and is almost ready for publication as-is -- unless of > course we're wrong and there's controversy about the draft. > > So let's try this again. Please do reply, by July 8. In particular, if > you feel that we are mistaken and the draft is NOT a "no-brainer" for > the WG, you should say that because in this specific case, we might make > an exception and apply the rule "silence gives consent". > > Thanks! > > --John and Sue > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- ================================================ 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 aservin@lacnic.net Tue Jul 2 03:06: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 B526F11E8461 for ; Tue, 2 Jul 2013 03:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSgeN-cjXM26 for ; Tue, 2 Jul 2013 03:06:52 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 4A62911E845D for ; Tue, 2 Jul 2013 03:06:52 -0700 (PDT) Received: from [192.168.0.5] (unknown [90.213.241.219]) by mail.lacnic.net.uy (Postfix) with ESMTP id AED61308446 for ; Tue, 2 Jul 2013 07:06:27 -0300 (UYT) Message-ID: <51D2A631.5080805@lacnic.net> Date: Tue, 02 Jul 2013 11:06:41 +0100 From: Arturo Servin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: idr@ietf.org References: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> In-Reply-To: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------080807060603070003000406" X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Subject: Re: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG document 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, 02 Jul 2013 10:06:56 -0000 This is a multi-part message in MIME format. --------------080807060603070003000406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In favor. .as On 7/1/13 8:46 PM, John G. Scudder wrote: > Folks, > > On May 29 the authors requested WG adoption of > draft-jhjm-idr-last-as-reservations-00. There was not much response -- > two supportive replies, not counting authors. This is not enough to > declare "WG consensus" or much of anything else. > > A short summary for those who aren't familiar with the draft: > It basically says "the last ASNs are already reserved, please be > careful with them". This seems to the chairs to be obviously true and > useful to document, but maybe it's SO obvious that WG members are not > bothering to say anything. It also seems to us that this doesn't > demand much work from the WG and is almost ready for publication as-is > -- unless of course we're wrong and there's controversy about the draft. > > So let's try this again. Please do reply, by July 8. In particular, if > you feel that we are mistaken and the draft is NOT a "no-brainer" for > the WG, you should say that because in this specific case, we might > make an exception and apply the rule "silence gives consent". > > Thanks! > > --John and Sue > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --------------080807060603070003000406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    In favor.

.as

On 7/1/13 8:46 PM, John G. Scudder wrote:
Folks,

On May 29 the authors requested WG adoption of draft-jhjm-idr-last-as-reservations-00. There was not much response -- two supportive replies, not counting authors. This is not enough to declare "WG consensus" or much of anything else.

A short summary for those who aren't familiar with the draft: It basically says "the last ASNs are already reserved, please be careful with them". This seems to the chairs to be obviously true and useful to document, but maybe it's SO obvious that WG members are not bothering to say anything. It also seems to us that this doesn't demand much work from the WG and is almost ready for publication as-is -- unless of course we're wrong and there's controversy about the draft.

So let's try this again. Please do reply, by July 8. In particular, if you feel that we are mistaken and the draft is NOT a "no-brainer" for the WG, you should say that because in this specific case, we might make an exception and apply the rule "silence gives consent".

Thanks!

--John and Sue


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

--------------080807060603070003000406-- From moulton@ons.com Sat Jul 6 05:20: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 3063E21F9BAA for ; Sat, 6 Jul 2013 05:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oye02j3heWrl for ; Sat, 6 Jul 2013 05:20:45 -0700 (PDT) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id B94C421F9A37 for ; Sat, 6 Jul 2013 05:20:45 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so7170552ief.12 for ; Sat, 06 Jul 2013 05:20:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type:x-gm-message-state; bh=wuJOK6HidfHClG0VdUkntonTKQQ/RWSDPA5ofVH8cP4=; b=jQ/n1ZOS3vKJVGz7kGdUK1/7whCgwK4/B//UWKI7SENGjKKzKx7uALBBM0RAl5k3pw XwgddzeGyq14SejrgwcncZmsnueqXrvtQ5UnpqqLJlEU8PJLupWgUMyBjqcQES3szw8H qwZJqKctG3iMuDhuAQV7BW+e4FxzyAn/l2hkUFvF76niwxyhnN1f3H3K2skYLSrLLruC EOfdzLuEDCMwXQyrtuI1up8uYDkqwxZAc6tSR/fp6bf8SgT5Qt8lE1tGmuxFm8bZE9o2 QWGJAsGcjmfxBs5dY6GhHZNaeWuUC0ugarI9G3DZF3Aj1EGWtQPp7MKYu4esphEcjRyr jHBw== MIME-Version: 1.0 X-Received: by 10.42.196.129 with SMTP id eg1mr5231821icb.62.1373113245260; Sat, 06 Jul 2013 05:20:45 -0700 (PDT) Received: by 10.64.14.51 with HTTP; Sat, 6 Jul 2013 05:20:45 -0700 (PDT) In-Reply-To: <51D2A631.5080805@lacnic.net> References: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> <51D2A631.5080805@lacnic.net> Date: Sat, 6 Jul 2013 08:20:45 -0400 Message-ID: From: James Moulton Cc: idr@ietf.org Content-Type: multipart/alternative; boundary=20cf303bff8a38785204e0d6d791 X-Gm-Message-State: ALoCoQkdXKauGU8sKjogtpfURB/T1aZ520S2GPvidhedFftiKo9fCYdOysPJIBrA2Uog1b8Rxnqd Subject: Re: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG document 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, 06 Jul 2013 12:20:58 -0000 --20cf303bff8a38785204e0d6d791 Content-Type: text/plain; charset=ISO-8859-1 In favor, Jim Moulton On Tue, Jul 2, 2013 at 6:06 AM, Arturo Servin wrote: > > In favor. > > .as > > > On 7/1/13 8:46 PM, John G. Scudder wrote: > > Folks, > > On May 29 the authors requested WG adoption of > draft-jhjm-idr-last-as-reservations-00. There was not much response -- two > supportive replies, not counting authors. This is not enough to declare "WG > consensus" or much of anything else. > > A short summary for those who aren't familiar with the draft: > It basically says "the last ASNs are already reserved, please be careful > with them". This seems to the chairs to be obviously true and useful to > document, but maybe it's SO obvious that WG members are not bothering to > say anything. It also seems to us that this doesn't demand much work from > the WG and is almost ready for publication as-is -- unless of course we're > wrong and there's controversy about the draft. > > So let's try this again. Please do reply, by July 8. In particular, if > you feel that we are mistaken and the draft is NOT a "no-brainer" for the > WG, you should say that because in this specific case, we might make an > exception and apply the rule "silence gives consent". > > Thanks! > > --John and Sue > > > _______________________________________________ > Idr mailing listIdr@ietf.orghttps://www.ietf.org/mailman/listinfo/idr > > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > --20cf303bff8a38785204e0d6d791 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In favor, =A0Jim Moulton
<= br>
On Tue, Jul 2, 2013 at 6:06 AM, Arturo Se= rvin <aservin@lacnic.net> wrote:
=20 =20 =20

=A0=A0=A0 In favor.

.as


On 7/1/13 8:46 PM, John G. Scudder wrote:
=20
Folks,

On May 29 the authors requested WG adoption of draft-jhjm-idr-last-as-reservations-00. There was not much response -- two supportive replies, not counting authors. This is not enough to declare "WG consensus" or much of anythi= ng else.

A short summary for those who aren't familiar with the draft= : It=A0basically says "the last ASNs are already reserved, pleas= e be careful with them". This seems to the chairs to be obviously true and useful to document, but maybe it's SO obvious that WG members are not bothering to say anything. It also seems to us that this doesn't demand much work from the WG and is almost ready for publication as-is -- unless of course we're wrong and there's controversy about the draft.

So let's try this again. Please do reply, by July 8. In particular, if you feel that we are mistaken and the draft is NOT a "no-brainer" for the WG, you should say that becaus= e in this specific case, we might make an exception and apply the rule "silence gives consent".

Thanks!

--John and Sue


__________________________________=
_____________
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


--20cf303bff8a38785204e0d6d791-- From russw@riw.us Sat Jul 6 05:37:31 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 A1B6C21F9BD5 for ; Sat, 6 Jul 2013 05:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BKJWtGa+0Ao for ; Sat, 6 Jul 2013 05:37:27 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id EF06B21F9C11 for ; Sat, 6 Jul 2013 05:37:26 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=USCSWHITER10L1C) by da31.namelessnet.net with esmtpa (Exim 4.80.1) (envelope-from ) id 1UvRjy-0008S7-Bu; Sat, 06 Jul 2013 05:37:26 -0700 From: "Russ White" To: "'James Moulton'" References: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> <51D2A631.5080805@lacnic.net> In-Reply-To: Date: Sat, 6 Jul 2013 08:37:35 -0400 Message-ID: <012d01ce7a45$981db960$c8592c20$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFUYq37H7ADT5x9Iqr4X9xjN64rrgHRlVpYA6HZpYiaICpRcA== Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: idr@ietf.org Subject: Re: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG document 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, 06 Jul 2013 12:37:31 -0000 Support. Russ > -----Original Message----- > From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of > James Moulton > Sent: Saturday, July 06, 2013 8:21 AM > Cc: idr@ietf.org > Subject: Re: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG > document > > In favor, Jim Moulton > > > On Tue, Jul 2, 2013 at 6:06 AM, Arturo Servin > wrote: > > > > In favor. > > .as > > > On 7/1/13 8:46 PM, John G. Scudder wrote: > > > Folks, > > On May 29 the authors requested WG adoption of draft- > jhjm-idr-last-as-reservations-00. There was not much response -- two > supportive replies, not counting authors. This is not enough to declare "WG > consensus" or much of anything else. > > A short summary for those who aren't familiar with the > draft: It basically says "the last ASNs are already reserved, please be careful > with them". This seems to the chairs to be obviously true and useful to > document, but maybe it's SO obvious that WG members are not bothering to > say anything. It also seems to us that this doesn't demand much work from > the WG and is almost ready for publication as-is -- unless of course we're > wrong and there's controversy about the draft. > > So let's try this again. Please do reply, by July 8. In particular, > if you feel that we are mistaken and the draft is NOT a "no-brainer" for the > WG, you should say that because in this specific case, we might make an > exception and apply the rule "silence gives consent". > > Thanks! > > --John and Sue > > > > > _______________________________________________ > 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 jgs@juniper.net Mon Jul 8 12:14: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 0A1B021F93B9 for ; Mon, 8 Jul 2013 12:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAGgSAmwhwqL for ; Mon, 8 Jul 2013 12:14:11 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id EAD6F21F924A for ; Mon, 8 Jul 2013 12:14:08 -0700 (PDT) Received: from mail76-am1-R.bigfish.com (10.3.201.231) by AM1EHSOBE018.bigfish.com (10.3.207.140) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:13:53 +0000 Received: from mail76-am1 (localhost [127.0.0.1]) by mail76-am1-R.bigfish.com (Postfix) with ESMTP id BE684E00F0 for ; Mon, 8 Jul 2013 19:13:53 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB03-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zzc85fh1519M4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz18c673hz2fh2a8h683h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h14ddh1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1b2bh1bceh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1e23h1e64h1155h) Received-SPF: pass (mail76-am1: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=jgs@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail76-am1 (localhost.localdomain [127.0.0.1]) by mail76-am1 (MessageSwitch) id 1373310831517352_16613; Mon, 8 Jul 2013 19:13:51 +0000 (UTC) Received: from AM1EHSMHS019.bigfish.com (unknown [10.3.201.253]) by mail76-am1.bigfish.com (Postfix) with ESMTP id 79C222A0048 for ; Mon, 8 Jul 2013 19:13:51 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.51) by AM1EHSMHS019.bigfish.com (10.3.207.157) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 8 Jul 2013 19:13:48 +0000 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; Mon, 8 Jul 2013 12:13:46 -0700 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; Mon, 8 Jul 2013 12:13:45 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 8 Jul 2013 12:17:32 -0700 Received: from mail95-ch1-R.bigfish.com (10.43.68.229) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Mon, 8 Jul 2013 19:13:45 +0000 Received: from mail95-ch1 (localhost [127.0.0.1]) by mail95-ch1-R.bigfish.com (Postfix) with ESMTP id CD07D480145 for ; Mon, 8 Jul 2013 19:13:44 +0000 (UTC) Received: from mail95-ch1 (localhost.localdomain [127.0.0.1]) by mail95-ch1 (MessageSwitch) id 137331078620001_19621; Mon, 8 Jul 2013 19:13:06 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail95-ch1.bigfish.com (Postfix) with ESMTP id EC2B64E0063 for ; Mon, 8 Jul 2013 19:13:05 +0000 (UTC) Received: from BLUPRD0512HT001.namprd05.prod.outlook.com (132.245.1.149) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 8 Jul 2013 19:13:04 +0000 Received: from dhazel-sslvpn-nc.jnpr.net (66.129.232.2) by pod51010.outlook.com (10.255.215.162) with Microsoft SMTP Server (TLS) id 14.16.329.3; Mon, 8 Jul 2013 19:13:03 +0000 From: John Scudder Content-Type: multipart/alternative; boundary="Apple-Mail=_D1EF4A74-AAFF-4231-B074-FCE75AE50AF5" Message-ID: Date: Mon, 8 Jul 2013 15:13:00 -0400 To: "idr@ietf.org List" MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) 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 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Idr] IETF-87 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: Mon, 08 Jul 2013 19:14:18 -0000 --Apple-Mail=_D1EF4A74-AAFF-4231-B074-FCE75AE50AF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Folks, We're planning to meet at IETF-87 on Thursday, August 1 from 15:20 to = 16:50. Please forward any IDR agenda items you might have to Sue and = myself. The deadline is July 16 by 10: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=_D1EF4A74-AAFF-4231-B074-FCE75AE50AF5 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=_D1EF4A74-AAFF-4231-B074-FCE75AE50AF5-- From wesley.george@twcable.com Wed Jul 10 09:57: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 48F2121F9D98 for ; Wed, 10 Jul 2013 09:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTSsVT55+IO5 for ; Wed, 10 Jul 2013 09:57:38 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 85FBC21F9D96 for ; Wed, 10 Jul 2013 09:57:24 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.87,1037,1363147200"; d="scan'208";a="31720062" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 10 Jul 2013 12:57:18 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Wed, 10 Jul 2013 12:57:23 -0400 From: "George, Wes" To: "idr@ietf.org" Date: Wed, 10 Jul 2013 12:57:22 -0400 Thread-Topic: New Version Notification for draft-ga-idr-as-migration-02.txt Thread-Index: Ac59hjAA+vXyMuImTSG5/0Njbq1IfQAB0eCg Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592304370D869C@PRVPEXVS15.corp.twcable.com> References: <20130710155708.11175.9693.idtracker@ietfa.amsl.com> In-Reply-To: <20130710155708.11175.9693.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "draft-ga-idr-as-migration@tools.ietf.org" Subject: [Idr] FW: New Version Notification for draft-ga-idr-as-migration-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: Wed, 10 Jul 2013 16:57:42 -0000 SGkgYWxsIC0NCg0KT25seSBtaW5vciBjaGFuZ2VzIGluIHRoaXMgdmVyc2lvbiwgbWFpbmx5IHRv IHVwZGF0ZSB0aGUgQVMgTnVtYmVycyB1c2VkIGluIHRoZSBleGFtcGxlcyB0byByZWZsZWN0IHRo ZSBkb2N1bWVudGF0aW9uIEFTTiwgYW5kIGFkZCBhIGRpYWdyYW0gcmVjb21tZW5kZWQgYnkgU3Rl cGhhbmUgTGl0a293c2tpLiBXZSdkIGxpa2UgdG8gaGF2ZSB0aGlzIGNvbnNpZGVyZWQgZm9yIFdH IGFkb3B0aW9uLg0KDQpUaGFua3MsDQoNCldlcyBHZW9yZ2UgYW5kIFNoYW5lIEFtYW50ZQ0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5 IDEwLCAyMDEzIDExOjU3IEFNDQpUbzogR2VvcmdlLCBXZXM7IFNoYW5lIEFtYW50ZQ0KU3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1nYS1pZHItYXMtbWlncmF0aW9u LTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1nYS1pZHItYXMtbWlncmF0 aW9uLTAyLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBXZXNsZXkgR2Vv cmdlIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAg ICAgZHJhZnQtZ2EtaWRyLWFzLW1pZ3JhdGlvbg0KUmV2aXNpb246ICAgICAgICAwMg0KVGl0bGU6 ICAgICAgICAgICBBdXRvbm9tb3VzIFN5c3RlbSAoQVMpIE1pZ3JhdGlvbiBGZWF0dXJlcyBhbmQg VGhlaXIgRWZmZWN0cyBvbiB0aGUgQkdQIEFTX1BBVEggQXR0cmlidXRlDQpDcmVhdGlvbiBkYXRl OiAgIDIwMTMtMDctMTANCkdyb3VwOiAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpO dW1iZXIgb2YgcGFnZXM6IDE0DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWdhLWlkci1hcy1taWdyYXRpb24tMDIudHh0DQpTdGF0dXM6 ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2EtaWRyLWFz LW1pZ3JhdGlvbg0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1nYS1pZHItYXMtbWlncmF0aW9uLTAyDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWdhLWlkci1hcy1taWdyYXRpb24tMDINCg0KQWJz dHJhY3Q6DQogICBUaGlzIGRyYWZ0IGRpc2N1c3NlcyBjb21tb24gbWV0aG9kcyBvZiBtYW5hZ2lu ZyBhbiBBU04gbWlncmF0aW9uDQogICB1c2luZyBzb21lIEJHUCBmZWF1cmVzIHRoYXQgd2hpbGUg Y29tbW9ubHktdXNlZCBhcmUgbm90IGZvcm1hbGx5IHBhcnQNCiAgIG9mIHRoZSBCR1A0IHByb3Rv Y29sIHNwZWNpZmljYXRpb24gYW5kIG1heSBiZSB2ZW5kb3Itc3BlY2lmaWMgaW4NCiAgIGV4YWN0 IGltcGxlbWVudGF0aW9uLiAgSXQgaXMgbmVjZXNzYXJ5IHRvIGRvY3VtZW50IHRoZXNlIGRlIGZh Y3RvDQogICBzdGFuZGFyZHMgdG8gZW5zdXJlIHRoYXQgdGhleSBhcmUgcHJvcGVybHkgc3VwcG9y dGVkIGluIEJHUFNlYy4NCg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KQW55dGhpbmcg YmVsb3cgdGhpcyBsaW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnnigJlzIG1haWwgc2Vy dmVyLCBJIGhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhp cyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJu ZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNv bmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2Fy bmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5 aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBh dHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkg YmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0 ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRv dXQuDQo= From satoru.matsushima@gmail.com Wed Jul 10 14:07: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 7B5D721F9E9D for ; Wed, 10 Jul 2013 14:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97B1GH1YRFIr for ; Wed, 10 Jul 2013 14:07:44 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1800021F9E7D for ; Wed, 10 Jul 2013 14:07:43 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id fe20so6199428lab.34 for ; Wed, 10 Jul 2013 14:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CP+xqmeywjB8VWr0TLfQ0MgrCQsbU/Mh0AL21gvxKfU=; b=hvKceuSF/9kBOClNTsE6sQ0ZAWFI2wF4cWLSTzh/RysDNJNGio3oGnwf1Ob+7c1JLw hNnlLBum/DDHBmptHQNNoy6WBADtFAfEkCa+h16dtXPgFErA2W4f2gZoGJHPynQ06R2N xTu55nMnA1KqWRLKSwjx2JLxyspEDpkyO2dLml14rei5YK0kHuGsso1nLAliQpIktHim M7y0Ug4PKJ6bq8h/OFf3oGywu3Nyrn2j8nVn5dGkCBY47pRz/GPx4Dm932joV1vfcLJ2 N62VoBzc5Y+2AvDhbDRbmmDpaYrhjBmQicgWZ3ASIEpRiYIeCMU+7dYwYWUZi3n7kZH1 Baaw== MIME-Version: 1.0 X-Received: by 10.112.157.226 with SMTP id wp2mr15724230lbb.65.1373490462995; Wed, 10 Jul 2013 14:07:42 -0700 (PDT) Received: by 10.112.167.169 with HTTP; Wed, 10 Jul 2013 14:07:42 -0700 (PDT) Date: Thu, 11 Jul 2013 06:07:42 +0900 Message-ID: From: Satoru Matsushima To: idr@ietf.org Content-Type: multipart/alternative; boundary=001a11c34772263bd404e12eabdb Subject: [Idr] Fwd: I-D Action: draft-matsushima-stateless-uplane-vepc-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: Wed, 10 Jul 2013 21:07:45 -0000 --001a11c34772263bd404e12eabdb Content-Type: text/plain; charset=ISO-8859-1 Hi, We have submitted an I-D for mobile core user-plane which adopts routing basis architecture. This draft is not submit IDR working group but BGP remote next-hop proposed to IDR helps to realize this architecture. Your comments are welcome. Regards, --satoru ---------- Forwarded message ---------- From: Date: Thu, Jul 11, 2013 at 1:09 AM Subject: I-D Action: draft-matsushima-stateless-uplane-vepc-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Stateless user-plane architecture for virtualized EPC (vEPC) Author(s) : Satoru Matsushima Ryuji Wakikawa Filename : draft-matsushima-stateless-uplane-vepc-00.txt Pages : 19 Date : 2013-07-10 Abstract: We envision a new mobile architecture for the future Evolved Packet Core (EPC). The new architecture is designed to support the virtualization scheme called NFV (Network Function Virtualization). In our architecture, the user plane of EPC is decoupled from the control-plane and uses routing information to forward packets of mobile nodes. Although the EPC control plane will run on hypervisor, our proposal does not modify the signaling of the EPC control plane. The benefits of our architecture are 1) scalability, 2) flexibility and 3) Manageability. How to run the EPC control plane on NFV is out of our focus in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc There's also a htmlized version available at: http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draftdirectories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11c34772263bd404e12eabdb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

We hav= e submitted an I-D for mobile core user-plane which adopts routing basis ar= chitecture. This draft is not submit IDR working group but BGP remote =A0ne= xt-hop proposed to IDR helps to realize this architecture. Your comments ar= e welcome.

Regards,
--satoru



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Jul 11, 2013 at 1:09 AM
Subject: I-D Action: draft-matsushima= -stateless-uplane-vepc-00.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Stateless user-plane architectu= re for virtualized EPC (vEPC)
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Satoru Matsushima
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ryuji Wakikawa
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-matsushima-stateless-uplane= -vepc-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 19
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-10

Abstract:
=A0 =A0We envision a new mobile architecture for the future Evolved Packet<= br> =A0 =A0Core (EPC). =A0The new architecture is designed to support the
=A0 =A0virtualization scheme called NFV (Network Function Virtualization).<= br> =A0 =A0In our architecture, the user plane of EPC is decoupled from the
=A0 =A0control-plane and uses routing information to forward packets of
=A0 =A0mobile nodes. =A0Although the EPC control plane will run on hypervis= or,
=A0 =A0our proposal does not modify the signaling of the EPC control plane.=
=A0 =A0The benefits of our architecture are 1) scalability, 2) flexibility<= br> =A0 =A0and 3) Manageability. =A0How to run the EPC control plane on NFV is = out
=A0 =A0of our focus in this document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-matsushim= a-stateless-uplane-vepc

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-matsushima-statele= ss-uplane-vepc-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a11c34772263bd404e12eabdb-- From wangdanhua@huawei.com Fri Jul 12 01:30: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 187DE21F9D46 for ; Fri, 12 Jul 2013 01:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.074 X-Spam-Level: X-Spam-Status: No, score=-5.074 tagged_above=-999 required=5 tests=[AWL=1.074, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pbo7195qc5N for ; Fri, 12 Jul 2013 01:30:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB6321F9D45 for ; Fri, 12 Jul 2013 01:30:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUY31216; Fri, 12 Jul 2013 08:30:09 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 09:29:43 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Jul 2013 09:30:07 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Fri, 12 Jul 2013 16:30:01 +0800 From: Wangdanhua To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-wu-idr-te-pm-bgp-00.txt Thread-Index: AQHOftm48zUf6UXwskSEZOg3UwhO/ZlgtdPQ Date: Fri, 12 Jul 2013 08:30:00 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.177] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 12 Jul 2013 08:39:36 -0700 Subject: [Idr] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-wu-idr-te-pm-bgp-00=2Etxt?= 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, 12 Jul 2013 08:30:20 -0000 SGkgYWxsLA0KDQpXZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgbmFtZWQgIkJHUCBhdHRyaWJ1dGUg Zm9yIE5vcnRoLUJvdW5kIERpc3RyaWJ1dGlvbiBvZiBUcmFmZmljIEVuZ2luZWVyaW5nIChURSkg cGVyZm9ybWFuY2UgTWV0cmljIiAoZHJhZnQtd3UtaWRyLXRlLXBtLWJncC0wMCkuIEFueSBjb21t ZW50cyBvciBzdWdnZXN0aW9ucyBhcmUgYXBwcmVjaWF0ZWQuDQoNCg0KQmVzdCB3aXNoZXMsDQpE YW5odWEgV2FuZw0KDQoNCg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K 5Y+R6YCB5pe26Ze0OiAyMDEz5bm0N+aciDEy5pelIDE2OjI3DQrmlLbku7bkuro6IFdhbmdkYW5o dWE7IFFpbiBXdTsgUWluIFd1OyBXYW5nZGFuaHVhDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtd3UtaWRyLXRlLXBtLWJncC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtd3UtaWRyLXRlLXBtLWJncC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgUWluIFd1IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9z aXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtd3UtaWRyLXRlLXBtLWJncA0KUmV2aXNpb246CSAw MA0KVGl0bGU6CQkgQkdQIGF0dHJpYnV0ZSBmb3IgTm9ydGgtQm91bmQgRGlzdHJpYnV0aW9uIG9m IFRyYWZmaWMgRW5naW5lZXJpbmcgKFRFKSBwZXJmb3JtYW5jZSBNZXRyaWMNCkNyZWF0aW9uIGRh dGU6CSAyMDEzLTA3LTEyDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBv ZiBwYWdlczogOQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC13dS1pZHItdGUtcG0tYmdwLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBo dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LWlkci10ZS1wbS1iZ3ANCkh0 bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3UtaWRyLXRl LXBtLWJncC0wMA0KDQoNCkFic3RyYWN0Og0KICAgSW4gb3JkZXIgdG8gcG9wdWxhdGUgbmV0d29y ayBwZXJmb3JtYW5jZSBpbmZvcm1hdGlvbiBsaWtlIGxpbmsNCiAgIGxhdGVuY3ksIGxhdGVuY3kg dmFyaWF0aW9uIGFuZCBwYWNrZXQgbG9zcyBpbnRvIFRFRCBhbmQgQUxUTyBzZXJ2ZXIsDQogICB0 aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBleHRlbnNpb25zIHRvIEJHUCBwcm90b2NvbCwgdGhhdCBj YW4gYmUgdXNlZA0KICAgdG8gZGlzdHJpYnV0ZSBuZXR3b3JrIHBlcmZvcm1hbmNlIGluZm9ybWF0 aW9uIChzdWNoIGFzIGxpbmsgZGVsYXksDQogICBkZWxheSB2YXJpYXRpb24sIHBhY2tldCBsb3Nz LCByZXNpZHVhbCBiYW5kd2lkdGgsIGFuZCBhdmFpbGFibGUNCiAgIGJhbmR3aWR0aCxsaW5rIHV0 aWxpemF0aW9uLCBjaGFubmVsIHRocm91Z2hwdXQpLg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From jgs@juniper.net Sun Jul 14 14:48: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 2BE6521F9BEF for ; Sun, 14 Jul 2013 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dLAyovRfzFP for ; Sun, 14 Jul 2013 14:48:08 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 507CB21F9BE5 for ; Sun, 14 Jul 2013 14:48:08 -0700 (PDT) Received: from mail11-co1-R.bigfish.com (10.243.78.235) by CO1EHSOBE024.bigfish.com (10.243.66.87) with Microsoft SMTP Server id 14.1.225.22; Sun, 14 Jul 2013 21:48:07 +0000 Received: from mail11-co1 (localhost [127.0.0.1]) by mail11-co1-R.bigfish.com (Postfix) with ESMTP id 2F5B1180152 for ; Sun, 14 Jul 2013 21:48:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371Ic85fh103dK1432I4015Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz8275ch1033IL18c673h8275dhz2fh2a8h683h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1b2bh1bceh1d0ch1d2eh1d3fh1dfeh1dffh1e23h1e64h1155h) Received-SPF: pass (mail11-co1: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=jgs@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.242.197; KIP:(null); UIP:(null); (null); H:BL2PRD0512HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail11-co1 (localhost.localdomain [127.0.0.1]) by mail11-co1 (MessageSwitch) id 1373838485947015_5749; Sun, 14 Jul 2013 21:48:05 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.232]) by mail11-co1.bigfish.com (Postfix) with ESMTP id DAF15B0005E for ; Sun, 14 Jul 2013 21:48:05 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.51) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 14 Jul 2013 21:48:05 +0000 Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 14 Jul 2013 14:48:05 -0700 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; Sun, 14 Jul 2013 14:48:04 -0700 Received: from db9outboundpool.messaging.microsoft.com (213.199.154.251) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 14 Jul 2013 14:52:38 -0700 Received: from mail67-db9-R.bigfish.com (10.174.16.244) by DB9EHSOBE013.bigfish.com (10.174.14.76) with Microsoft SMTP Server id 14.1.225.22; Sun, 14 Jul 2013 21:48:02 +0000 Received: from mail67-db9 (localhost [127.0.0.1]) by mail67-db9-R.bigfish.com (Postfix) with ESMTP id 9EA873A00C8 for ; Sun, 14 Jul 2013 21:48:02 +0000 (UTC) Received: from mail67-db9 (localhost.localdomain [127.0.0.1]) by mail67-db9 (MessageSwitch) id 1373838479858696_1186; Sun, 14 Jul 2013 21:47:59 +0000 (UTC) Received: from DB9EHSMHS006.bigfish.com (unknown [10.174.16.235]) by mail67-db9.bigfish.com (Postfix) with ESMTP id CE6B536004D for ; Sun, 14 Jul 2013 21:47:59 +0000 (UTC) Received: from BL2PRD0512HT001.namprd05.prod.outlook.com (157.56.242.197) by DB9EHSMHS006.bigfish.com (10.174.14.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 14 Jul 2013 21:47:59 +0000 Received: from [172.28.131.98] (66.129.232.2) by pod51010.outlook.com (10.255.233.34) with Microsoft SMTP Server (TLS) id 14.16.329.3; Sun, 14 Jul 2013 21:47:58 +0000 From: "John G. Scudder" Content-Type: multipart/alternative; boundary="Apple-Mail=_3701671F-A008-4AA6-9D98-EE31CB112FEE" Message-ID: MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Sun, 14 Jul 2013 17:47:53 -0400 References: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> To: "idr@ietf. org" In-Reply-To: <4B5C8A63-E550-4C49-BE4B-F169A78CF023@juniper.net> X-Mailer: Apple Mail (2.1508) 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 X-OriginatorOrg: juniper.net Subject: Re: [Idr] Second Try: draft-jhjm-idr-last-as-reservations as WG document 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, 14 Jul 2013 21:48:14 -0000 --Apple-Mail=_3701671F-A008-4AA6-9D98-EE31CB112FEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Thanks to those who took the time to respond. The document is adopted as = an IDR WG draft. Authors, please resubmit as draft-ietf-idr- Thanks, --John On Jul 1, 2013, at 3:46 PM, John G. Scudder wrote: > Folks, >=20 > On May 29 the authors requested WG adoption of = draft-jhjm-idr-last-as-reservations-00. There was not much response -- = two supportive replies, not counting authors. This is not enough to = declare "WG consensus" or much of anything else. >=20 > A short summary for those who aren't familiar with the draft: It = basically says "the last ASNs are already reserved, please be careful = with them". This seems to the chairs to be obviously true and useful to = document, but maybe it's SO obvious that WG members are not bothering to = say anything. It also seems to us that this doesn't demand much work = from the WG and is almost ready for publication as-is -- unless of = course we're wrong and there's controversy about the draft. >=20 > So let's try this again. Please do reply, by July 8. In particular, if = you feel that we are mistaken and the draft is NOT a "no-brainer" for = the WG, you should say that because in this specific case, we might make = an exception and apply the rule "silence gives consent". >=20 > Thanks! >=20 > --John and Sue > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_3701671F-A008-4AA6-9D98-EE31CB112FEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" jgs@juniper.net> = wrote:

A short summary for those who aren't = familiar with the draft: It basically says "the last ASNs are = already reserved, please be careful with them". This seems to the chairs = to be obviously true and useful to document, but maybe it's SO obvious = that WG members are not bothering to say anything. It also seems to us = that this doesn't demand much work from the WG and is almost ready for = publication as-is -- unless of course we're wrong and there's = controversy about the draft.

So let's try this = again. Please do reply, by July 8. In particular, if you feel that we = are mistaken and the draft is NOT a "no-brainer" for the WG, you should = say that because in this specific case, we might make an exception and = apply the rule "silence gives = consent".

Thanks!

--John= and = Sue
_______________________________________________
Idr = mailing list
Idr@ietf.org
https://www.ietf.org/mail= man/listinfo/idr

= --Apple-Mail=_3701671F-A008-4AA6-9D98-EE31CB112FEE-- From internet-drafts@ietf.org Sun Jul 14 14:50: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 4436721F9C3D; Sun, 14 Jul 2013 14:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYD89G56OPgI; Sun, 14 Jul 2013 14:50:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F4C21F9BEF; Sun, 14 Jul 2013 14:50:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130714215041.8627.2673.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 14:50:41 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-flowspec-redirect-ip-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: Sun, 14 Jul 2013 21:50:42 -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 Flow-Spec Extended Community for Traffic Redirect to= IP Next Hop Author(s) : James Uttaro Matthieu Texier David Smith Wim Henderickx Adam Simpson Filename : draft-ietf-idr-flowspec-redirect-ip-00.txt Pages : 7 Date : 2013-07-04 Abstract: Flow-spec is an extension to BGP that allows for the dissemination of traffic flow specification rules. This has many possible applications but the primary one for many network operators is the distribution of traffic filtering actions for DDoS mitigation. The flow-spec standard [RFC 5575] defines a redirect-to-VRF action for policy-based forwarding but this mechanism can be difficult to use, particularly in networks without L3 VPNs. This draft proposes a new redirect-to-IP flow-spec action that provides a simpler method of policy-based forwarding. This action is indicated by the presence of a new BGP extended community in the flow-spec route. Many routers already support a redirect-to-IP filter action and, in this case, the only new functionality implied by this draft is the ability to signal the action using flow-spec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-redirect-ip There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-ip-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jul 14 16:41:00 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 11A3221F9C53; Sun, 14 Jul 2013 16:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWTyPP1VZLQS; Sun, 14 Jul 2013 16:40:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A9E21F9C19; Sun, 14 Jul 2013 16:40:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130714234059.20357.53196.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 16:40:59 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp4-mibv2-14.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: Sun, 14 Jul 2013 23:41:00 -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 : Definitions of Managed Objects for the Fourth Version of= Border Gateway Protocol (BGP-4), Second Version Author(s) : Jeffrey Haas Filename : draft-ietf-idr-bgp4-mibv2-14.txt Pages : 45 Date : 2013-07-14 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol, Version 4. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp4-mibv2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp4-mibv2-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jul 14 16:43:31 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 EC8B521F9294; Sun, 14 Jul 2013 16:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3Jvk8RnmdVi; Sun, 14 Jul 2013 16:43:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6463721F944F; Sun, 14 Jul 2013 16:43:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130714234329.13561.50754.idtracker@ietfa.amsl.com> Date: Sun, 14 Jul 2013 16:43:29 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-bgp4-mibv2-tc-mib-04.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: Sun, 14 Jul 2013 23:43:32 -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 : Definitions of Textual Conventions for the Management of= the Fourth Version of Border Gateway Protocol (BGP-4) Author(s) : Jeffrey Haas Filename : draft-ietf-idr-bgp4-mibv2-tc-mib-04.txt Pages : 6 Date : 2013-07-14 Abstract: This memo defines a portion of the Management Information Base (MIB) which defines Textual Conventions for the management of BGP-4. The intent is that these textual conventions will be used in BGP-related MIB modules that would otherwise define their own representations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp4-mibv2-tc-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-tc-mib-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp4-mibv2-tc-mib-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jhaas@slice.pfrc.org Sun Jul 14 16:45: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 5B65A21F9294; Sun, 14 Jul 2013 16:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBW0Zr+IN2j2; Sun, 14 Jul 2013 16:45:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 031E221F9339; Sun, 14 Jul 2013 16:45:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 6E683C633; Sun, 14 Jul 2013 19:45:18 -0400 (EDT) Date: Sun, 14 Jul 2013 19:45:18 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20130714234518.GA6523@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130714234329.13561.50754.idtracker@ietfa.amsl.com> <20130714234059.20357.53196.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr@ietf.org, i-d-announce@ietf.org Subject: [Idr] BGP MIBv2 uploads 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, 14 Jul 2013 23:45:26 -0000 Working Group, The following simply refreshes the existing MIB documents. -- Jeff On Sun, Jul 14, 2013 at 04:40:59PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > Title : Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), Second Version > Author(s) : Jeffrey Haas > Filename : draft-ietf-idr-bgp4-mibv2-14.txt > Pages : 45 > Date : 2013-07-14 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols. In particular it defines > objects for managing the Border Gateway Protocol, Version 4. > On Sun, Jul 14, 2013 at 04:43:29PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > Title : Definitions of Textual Conventions for the Management of the Fourth Version of Border Gateway Protocol (BGP-4) > Author(s) : Jeffrey Haas > Filename : draft-ietf-idr-bgp4-mibv2-tc-mib-04.txt > Pages : 6 > Date : 2013-07-14 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > which defines Textual Conventions for the management of BGP-4. The > intent is that these textual conventions will be used in BGP-related > MIB modules that would otherwise define their own representations. > From mach.chen@huawei.com Sun Jul 14 20:10: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 C3BCD21F9D8E for ; Sun, 14 Jul 2013 20:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Yja6aZW+kbF for ; Sun, 14 Jul 2013 20:10:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 03B0B21F9262 for ; Sun, 14 Jul 2013 20:10:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATK98762; Mon, 15 Jul 2013 03:10:39 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 04:09:47 +0100 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 04:10:33 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 11:10:28 +0800 From: Mach Chen To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-chen-idr-rr-based-traffic-steering-usecase-00.txt Thread-Index: AQHOfhj+FnvKSB7NeUeqVKH/F4yEbpllFDOw Date: Mon, 15 Jul 2013 03:10:27 +0000 Message-ID: References: <20130711092804.12329.42413.idtracker@ietfa.amsl.com> In-Reply-To: <20130711092804.12329.42413.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Idr] New Version Notification for draft-chen-idr-rr-based-traffic-steering-usecase-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: Mon, 15 Jul 2013 03:10:45 -0000 SGkgRm9sa3MsDQoNCldlIGp1c3QgdXBsb2FkZWQgYSBuZXcgZHJhZnQgdGhhdCBpbnRyb2R1Y2Vz IHRoZSBjb25jZXB0IG9mIFJvdXRlIFJlZmxlY3Rpb24gYmFzZWQgVHJhZmZpYyBTdGVlcmluZyBh bmQgc29tZSB1c2UgY2FzZXMgYW5kIHJlcXVpcmVtZW50cy4gDQoNCldlJ2QgbGlrZSB5b3UgY291 bGQgc3BlbmQgc29tZSB0aW1lIHRvIHJldmlldywgYW5kIGFueSBjb21tZW50cyBhbmQgc3VnZ2Vz dGlvbiBhcmUgd2VsY29tZSEgDQoNCkJlc3QgcmVnYXJkcywNCk1hY2gNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDExLCAy MDEzIDU6MjggUE0NCj4gVG86IE1hY2ggQ2hlbjsgWmh1YW5nc2h1bndhbjsgU3ViaW4gV2FuZzsg TWFjaCBDaGVuOyBZb25ncWluZyBaaHUNCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvcg0KPiBkcmFmdC1jaGVuLWlkci1yci1iYXNlZC10cmFmZmljLXN0ZWVyaW5nLXVzZWNh c2UtMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWNoZW4taWRy LXJyLWJhc2VkLXRyYWZmaWMtc3RlZXJpbmctdXNlY2FzZS0wMC50eHQNCj4gaGFzIGJlZW4gc3Vj Y2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNYWNoKEd1b3lpKSBDaGVuIGFuZCBwb3N0ZWQgdG8gdGhl DQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtY2hlbi1pZHItcnIt YmFzZWQtdHJhZmZpYy1zdGVlcmluZy11c2VjYXNlDQo+IFJldmlzaW9uOgkgMDANCj4gVGl0bGU6 CQkgVXNlIENhc2VzIG9mIFJvdXRlIFJlZmxlY3Rpb24gYmFzZWQgVHJhZmZpYyBTdGVlcmluZw0K PiBDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0xMQ0KPiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1p c3Npb24NCj4gTnVtYmVyIG9mIHBhZ2VzOiAxMQ0KPiBVUkw6DQo+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNoZW4taWRyLXJyLWJhc2VkLXRyYWZmaWMtc3RlZXJp bmctdXNlDQo+IGNhc2UtMDAudHh0DQo+IFN0YXR1czoNCj4gaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1jaGVuLWlkci1yci1iYXNlZC10cmFmZmljLXN0ZWVyaW5nLXVzZWNh c2UNCj4gSHRtbGl6ZWQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNoZW4t aWRyLXJyLWJhc2VkLXRyYWZmaWMtc3RlZXJpbmctdXNlY2FzZS0wMA0KPiANCj4gDQo+IEFic3Ry YWN0Og0KPiAgICBSb3V0ZSBSZWZsZWN0aW9uIGJhc2VkIFRyYWZmaWMgU3RlZXJpbmcgKFJSVFMp IGlzIGFuIGlkZWEgdGhhdA0KPiAgICBsZXZlcmFnZXMgdGhlIEJHUCByb3V0ZSByZWZsZWN0aW9u IG1lY2hhbmlzbSB0byByZWFsaXplIHRyYWZmaWMNCj4gICAgc3RlZXJpbmcgaW4gdGhlIG5ldHdv cmssIHRoZXJlZm9yZSB0aGUgb3BlcmF0b3JzIGNhbiBjb25kdWN0IHRoZWlyDQo+ICAgIHRyYWZm aWMgdG8gdHJhbnNtaXQvcmVjZWl2ZSB0aHJvdWdoIHNwZWNpZmljIG5vZGVzLCBkb21haW5zIGFu ZC9vcg0KPiAgICBwbGFuZXMgYXMgZGVtYW5kLiAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIHRo ZSByZXF1aXJlbWVudHMgYW5kIHVzZQ0KPiAgICBjYXNlcyBvZiBSUlRTLg0KPiANCj4gDQo+IA0K PiANCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From jhaas@slice.pfrc.org Tue Jul 16 08:20:26 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 2ADA821F9B2A for ; Tue, 16 Jul 2013 08:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zG034OiRrKhT for ; Tue, 16 Jul 2013 08:20:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2B221F9AF5 for ; Tue, 16 Jul 2013 08:20:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9B193C256; Tue, 16 Jul 2013 11:20:21 -0400 (EDT) Date: Tue, 16 Jul 2013 11:20:21 -0400 From: Jeffrey Haas To: idr@ietf.org Message-ID: <20130716152021.GA23506@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: zzhang@juniper.net, yakov@juniper.net, hj2387@att.com Subject: [Idr] Multicast Geo-distribution features for BGP 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, 16 Jul 2013 15:20:27 -0000 IDR, The authors of Multicast Geo-Distribution Control would like to draw your attention to the following drafts. The base geo distribution draft was presented a few IETFs ago in GROW and MBONED. In very brief summary, for multicast capable networks, there is need to be able to determine if subscribers are capable of receiving content via multicast. When they are capable of receiving it via multicast, there are situations where subscribers may subvert access control mechanisms for content. The geo-distribution draft covers the operational scenario. The BGP signaling components of this draft have been separately split into two drafts to cover their functionality: Multicast Distribution Reachability Signaling to determine if a subscriber can receive content via multicast, and Multicast Distribution Control Signaling to provide filtering mechanisms for multicast signaling protocols. While these mechanisms can be run in a network along with traditional BGP forwarding applications (Internet, VPN, etc.), this application may also run in a separate multicast network-specific context potentially on different peering sessions. Hopefully this alleviates the usual concern about "overloading the BGP control plane". One thing these drafts also do that requires no changes to specification but is a somewhat unusual application is making use of Constrained Route-target distribution (RT-C) for non-VPN NLRI. This is already permitted by the RFC, but as far as I'm aware is not deployed. http://tools.ietf.org/html/draft-rekhter-geo-distribution-control-03 http://tools.ietf.org/html/draft-rekhter-mdrs-00 http://tools.ietf.org/html/draft-rekhter-mdcs-00 We would like to request a brief (15 minute maximum) timeslot in IDR to cover the BGP specific changes. Our goal is to request adoption of MDRS and MDCS in IDR. We will likely request adoption of geo-distribution in MBONED. This is consistent with the funtionality split that was suggested as part of our feedback in GROW and MBONED. -- Jeff From mach.chen@huawei.com Wed Jul 17 03:00: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 C86EF21F9A8F; Wed, 17 Jul 2013 03:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhe-XGGrHwGS; Wed, 17 Jul 2013 03:00:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 934E321F9A81; Wed, 17 Jul 2013 03:00:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN22972; Wed, 17 Jul 2013 10:00:45 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 10:59:44 +0100 Received: from SZXEML454-HUB.china.huawei.com (10.82.67.197) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 11:00:18 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by SZXEML454-HUB.china.huawei.com ([10.82.67.197]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 17:59:49 +0800 From: Mach Chen To: Russ White , "i2rs@ietf.org" Thread-Topic: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case Thread-Index: Ac6BV9mxNi7PyssnRIGt/4lbCgtdGgBZMkLg Date: Wed, 17 Jul 2013 09:59:48 +0000 Message-ID: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> In-Reply-To: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "idr@ietf.org" , "zhuyq@gsta.com" Subject: Re: [Idr] [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case 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, 17 Jul 2013 10:00:51 -0000 Hi Russ, Thanks for bringing up this discussion! Please see my reply inline... Best regards, Mach > -----Original Message----- > From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of R= uss > White > Sent: Monday, July 15, 2013 8:45 PM > To: i2rs@ietf.org > Cc: zhuyq@gsta.com > Subject: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usec= ase as an > I2RS Use Case >=20 > Y'all: >=20 > It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecase mi= ght > provide a solid use case to add to one of our use case drafts in I2RS. Th= e > basic idea is this: >=20 > Rather than advertising multiple routes using something like add-paths to > optimize traffic flow between eBGP edges, why not just have the RR advert= ise > only the route that's best from each eBGP speaker's perspective? Now, I h= ave > a long standing desire to see it implemented. OTOH, even if add-paths is > implemented, there is the issue of which set of paths to send to the RR > clients in any given situation. So I don't see > draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to > add-paths, but rather a complimentary idea. I agree if the RR wants to advertise more than one routes to the clients.=20 >=20 > But how is the RR to know which path to send to which RR client? This is > where i2rs seems to fit. If the RR was attached to a controller that had > visibility into the layer 3 routing table at each RR client, that > information could be used to determine which path to send where. The RR > could also calculate the best path from the perspective of each RR client Yes, this is one possible way to achieve it. Alternate way is that the RR i= s the "controller" or part of a controller, it has not only the visibility = into the layer 3 routing table at each client, but the topology and other r= elated information of the network. Then the RR can compute a path for a spe= cific source and destination pair, just like the traffic engineering, and t= hen it advertises the relevant routes to clients though the existing route = reflection mechanisms.=20 > --but even though SPF is trivial to run, there are still problems with th= is > solution. First, you can't run SPF for a router that's not in your floodi= ng > domain. Second, you can't take into account any local policies configured= on > the router you're running SPF from the perspective of. The RR and the routers/clients do not have to be in the same flooding domai= n, the RR can establish IGP multiple adjacencies with domains (per adjacenc= y per domain) or use BGP-LS to collect the topology information. =20 Regarding to the local policies, if want the RR the consider the local poli= cies, there have to be some mechanisms to collect the local policies and ju= st configure it on the RR.=20 >=20 > Hence --just use i2rs to peek into the RR clients local routing table, an= d > send the client the right BGP route(s) as indicated (using add-paths to > include more than one path if needed, for load sharing or the like). >=20 > This would probably fit better into the BGP use cases draft, rather than = the > one I'm co-authoring --OTOH, I thought we were merging these two into a > single use cases draft covering all the "first line" use cases i2rs would > like to cover. >=20 > Thoughts? >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From internet-drafts@ietf.org Wed Jul 17 06:55: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 1562F11E80D9; Wed, 17 Jul 2013 06:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRk0Ov7j4-Pr; Wed, 17 Jul 2013 06:55:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 206C411E80A5; Wed, 17 Jul 2013 06:55:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.53 Message-ID: <20130717135445.22008.42400.idtracker@ietfa.amsl.com> Date: Wed, 17 Jul 2013 06:54:45 -0700 Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-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: Wed, 17 Jul 2013 13:55:30 -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 : Reservation of Last Autonomous System (AS) Numbers Author(s) : Jeffrey Haas Jon Mitchell Filename : draft-ietf-idr-last-as-reservation-00.txt Pages : 4 Date : 2013-07-15 Abstract: This document reserves two Autonomous System numbers (ASNs) at the end of the 16 bit and 32 bit ranges, described in this document as "Last ASNs" and provides guidance to implementers and operators on their use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From randy@psg.com Wed Jul 17 10:13: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 31CB521F9EEC for ; Wed, 17 Jul 2013 10:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSwpUMQcvKuM for ; Wed, 17 Jul 2013 10:13:53 -0700 (PDT) Received: from ran.psg.com (unknown [IPv6:2001:418:8006::19]) by ietfa.amsl.com (Postfix) with ESMTP id 68EB121F9D9A for ; Wed, 17 Jul 2013 10:13:53 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1UzVIW-0006dT-Hn for idr@ietf.org; Wed, 17 Jul 2013 17:13:52 +0000 Date: Wed, 17 Jul 2013 10:13:52 -0700 Message-ID: From: Randy Bush To: idr wg In-Reply-To: <20130717135445.22008.42400.idtracker@ietfa.amsl.com> References: <20130717135445.22008.42400.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 Subject: Re: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-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: Wed, 17 Jul 2013 17:13:54 -0000 while i think this draft is not dangerous, it strikes me as somewhat silly. creating standards attempting to preempt stupid programming errors has neither proof of termination or of effectiveness. randy From jhaas@slice.pfrc.org Wed Jul 17 10:30:47 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 EC32321F9D0E for ; Wed, 17 Jul 2013 10:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdqWqCXMxKTK for ; Wed, 17 Jul 2013 10:30:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EA7E321F9371 for ; Wed, 17 Jul 2013 10:30:42 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 866F9C395; Wed, 17 Jul 2013 13:30:42 -0400 (EDT) Date: Wed, 17 Jul 2013 13:30:42 -0400 From: Jeffrey Haas To: Randy Bush Message-ID: <20130717173042.GA9935@pfrc> References: <20130717135445.22008.42400.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: idr wg Subject: Re: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-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: Wed, 17 Jul 2013 17:30:48 -0000 Randy, On Wed, Jul 17, 2013 at 10:13:52AM -0700, Randy Bush wrote: > while i think this draft is not dangerous, it strikes me as somewhat > silly. creating standards attempting to preempt stupid programming > errors has neither proof of termination or of effectiveness. The primary purpose of this draft is bookkeeping for IANA to say why the last AS numbers are reserved and why it should be treated somewhat distinctly from private AS numbers. The main comment about "use of 65535 would cause issues with well known communities" is a core one for that AS. Wanting to leave the top 4-byte AS reserved for similiar reasons seems wise. But if your objection is to get rid of the section about bugs, that's fine and we can probably do that. I've just had too many conversations in the last decade with people who've had stupid bugs along those lines and thought it was a nice to have to document that. -- Jeff From randy@psg.com Wed Jul 17 10:49: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 0307821E8056 for ; Wed, 17 Jul 2013 10:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8FemFf6sHlV for ; Wed, 17 Jul 2013 10:49:01 -0700 (PDT) Received: from ran.psg.com (unknown [IPv6:2001:418:8006::19]) by ietfa.amsl.com (Postfix) with ESMTP id A2F4021E8055 for ; Wed, 17 Jul 2013 10:49:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1UzVqW-0006i1-12; Wed, 17 Jul 2013 17:49:00 +0000 Date: Wed, 17 Jul 2013 10:48:59 -0700 Message-ID: From: Randy Bush To: Jeffrey Haas In-Reply-To: <20130717173042.GA9935@pfrc> References: <20130717135445.22008.42400.idtracker@ietfa.amsl.com> <20130717173042.GA9935@pfrc> 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] I-D Action: draft-ietf-idr-last-as-reservation-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: Wed, 17 Jul 2013 17:49:02 -0000 as i said, not obviously harmful. From rraszuk@gmail.com Fri Jul 19 06:56: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 D929021E80C0; Fri, 19 Jul 2013 06:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6jGLZO8UgdK; Fri, 19 Jul 2013 06:56:24 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 28EF811E8139; Fri, 19 Jul 2013 06:56:24 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id 9so9450036iec.19 for ; Fri, 19 Jul 2013 06:56:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=C5hLGGo5gIuRfINfFi6LdkifxhnqHhVBTzAIDFciXFs=; b=cMivnBjVuA2ruciKE/w+qHjQiPVj/M22m1kz6fc8LfIjdb7+TYVwxwXNN4flaoDZcj smTYBwkOPWksJBUHdzwnqd8tArw26Y7tVFt3eKMPX7t/sdLhAu2BmDyO0emMkxtPfYDS YDMhDWnm4e6no6ZqpDdUtq/AVBl5bWZzgz/kR55sKSW9wAXCR1Vn19oVG+L/RRY2Wujz 0+gIGGaOPJYmtrPFZzr6fxCWwi+CMTwYKs5b2ife0QJ0VIbBS5FowrWYIxDs/qWj6eej 0DYTpDRo9KGF1M3DMB0kTX4oRO52v+gjOPrO/1DH8EDb61Hwqwg/p9D60bevUJeTwCkN V8og== MIME-Version: 1.0 X-Received: by 10.43.88.3 with SMTP id ay3mr10238335icc.61.1374242176055; Fri, 19 Jul 2013 06:56:16 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.28.168 with HTTP; Fri, 19 Jul 2013 06:56:16 -0700 (PDT) In-Reply-To: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> Date: Fri, 19 Jul 2013 15:56:16 +0200 X-Google-Sender-Auth: -Avsn4XceTy-nDjLOtLcdEKcQA0 Message-ID: From: Robert Raszuk To: Mach Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "i2rs@ietf.org" , "zhuyq@gsta.com" , "idr@ietf.org" Subject: Re: [Idr] [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case 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, 19 Jul 2013 13:56:25 -0000 Hi Mach, I have read your draft. I find nothing there which is not already solved by IDR WG document http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-05 The status of this WG document is pending two implementations. If you see anything technically missing in this draft possibly along with draft-varlashkin-bgp-nh-cost-02 let's discuss. Best regards, R. On Wed, Jul 17, 2013 at 11:59 AM, Mach Chen wrote: > Hi Russ, > > Thanks for bringing up this discussion! > > Please see my reply inline... > > Best regards, > Mach > >> -----Original Message----- >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf Of = Russ >> White >> Sent: Monday, July 15, 2013 8:45 PM >> To: i2rs@ietf.org >> Cc: zhuyq@gsta.com >> Subject: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-use= case as an >> I2RS Use Case >> >> Y'all: >> >> It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecase m= ight >> provide a solid use case to add to one of our use case drafts in I2RS. T= he >> basic idea is this: >> >> Rather than advertising multiple routes using something like add-paths t= o >> optimize traffic flow between eBGP edges, why not just have the RR adver= tise >> only the route that's best from each eBGP speaker's perspective? Now, I = have >> a long standing desire to see it implemented. OTOH, even if add-paths is >> implemented, there is the issue of which set of paths to send to the RR >> clients in any given situation. So I don't see >> draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to >> add-paths, but rather a complimentary idea. > > I agree if the RR wants to advertise more than one routes to the clients. > >> >> But how is the RR to know which path to send to which RR client? This is >> where i2rs seems to fit. If the RR was attached to a controller that had >> visibility into the layer 3 routing table at each RR client, that >> information could be used to determine which path to send where. The RR >> could also calculate the best path from the perspective of each RR clien= t > > Yes, this is one possible way to achieve it. Alternate way is that the RR= is the "controller" or part of a controller, it has not only the visibilit= y into the layer 3 routing table at each client, but the topology and other= related information of the network. Then the RR can compute a path for a s= pecific source and destination pair, just like the traffic engineering, and= then it advertises the relevant routes to clients though the existing rout= e reflection mechanisms. > >> --but even though SPF is trivial to run, there are still problems with t= his >> solution. First, you can't run SPF for a router that's not in your flood= ing >> domain. Second, you can't take into account any local policies configure= d on >> the router you're running SPF from the perspective of. > > The RR and the routers/clients do not have to be in the same flooding dom= ain, the RR can establish IGP multiple adjacencies with domains (per adjace= ncy per domain) or use BGP-LS to collect the topology information. > > Regarding to the local policies, if want the RR the consider the local po= licies, there have to be some mechanisms to collect the local policies and = just configure it on the RR. > >> >> Hence --just use i2rs to peek into the RR clients local routing table, a= nd >> send the client the right BGP route(s) as indicated (using add-paths to >> include more than one path if needed, for load sharing or the like). >> >> This would probably fit better into the BGP use cases draft, rather than= the >> one I'm co-authoring --OTOH, I thought we were merging these two into a >> single use cases draft covering all the "first line" use cases i2rs woul= d >> like to cover. >> >> Thoughts? >> >> :-) >> >> Russ >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From mach.chen@huawei.com Sun Jul 21 23:21:22 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 6827421E804D; Sun, 21 Jul 2013 23:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co93qCXnyxzf; Sun, 21 Jul 2013 23:21:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3083F21E8064; Sun, 21 Jul 2013 23:21:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATQ82456; Mon, 22 Jul 2013 06:20:43 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 07:19:52 +0100 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Jul 2013 07:20:42 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id 14.01.0323.007; Mon, 22 Jul 2013 14:20:37 +0800 From: Mach Chen To: Robert Raszuk Thread-Topic: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case Thread-Index: AQHOhIe/1DV2tpe+J0edLtmbNRgGA5lwODAQ Date: Mon, 22 Jul 2013 06:20:36 +0000 Message-ID: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "i2rs@ietf.org" , "zhuyq@gsta.com" , wangsb , "idr@ietf.org" Subject: Re: [Idr] [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case 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, 22 Jul 2013 06:21:23 -0000 Hi Robert, Many thanks for spending time to read the draft and your comments! If I understand the ORR and draft-varlashkin correctly, they both try to ca= lculate (from the client's perspective) the best route that is from the cli= ent to destination/nexthop.=20 But, just as Russ summarized, the use cases introduced in this draft (use c= ase 1 and 2) require to calculate the route from the eBGP peer's perspectiv= e, hence to optimize the traffic flow between eBGP peers (between MANs). Th= is seems not be solved by the ORR and draft-varlashkin.=20 Best regards, Mach > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Friday, July 19, 2013 9:56 PM > To: Mach Chen > Cc: Russ White; i2rs@ietf.org; idr@ietf.org; zhuyq@gsta.com > Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-= usecase > as an I2RS Use Case >=20 > Hi Mach, >=20 > I have read your draft. I find nothing there which is not already > solved by IDR WG document > http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-05 >=20 > The status of this WG document is pending two implementations. >=20 > If you see anything technically missing in this draft possibly along > with draft-varlashkin-bgp-nh-cost-02 let's discuss. >=20 > Best regards, > R. >=20 >=20 > On Wed, Jul 17, 2013 at 11:59 AM, Mach Chen wrote: > > Hi Russ, > > > > Thanks for bringing up this discussion! > > > > Please see my reply inline... > > > > Best regards, > > Mach > > > >> -----Original Message----- > >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf O= f Russ > >> White > >> Sent: Monday, July 15, 2013 8:45 PM > >> To: i2rs@ietf.org > >> Cc: zhuyq@gsta.com > >> Subject: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-u= secase as > an > >> I2RS Use Case > >> > >> Y'all: > >> > >> It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecase= might > >> provide a solid use case to add to one of our use case drafts in I2RS.= The > >> basic idea is this: > >> > >> Rather than advertising multiple routes using something like add-paths= to > >> optimize traffic flow between eBGP edges, why not just have the RR > advertise > >> only the route that's best from each eBGP speaker's perspective? Now, = I have > >> a long standing desire to see it implemented. OTOH, even if add-paths = is > >> implemented, there is the issue of which set of paths to send to the R= R > >> clients in any given situation. So I don't see > >> draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to > >> add-paths, but rather a complimentary idea. > > > > I agree if the RR wants to advertise more than one routes to the client= s. > > > >> > >> But how is the RR to know which path to send to which RR client? This = is > >> where i2rs seems to fit. If the RR was attached to a controller that h= ad > >> visibility into the layer 3 routing table at each RR client, that > >> information could be used to determine which path to send where. The R= R > >> could also calculate the best path from the perspective of each RR cli= ent > > > > Yes, this is one possible way to achieve it. Alternate way is that the = RR is the > "controller" or part of a controller, it has not only the visibility into= the layer 3 > routing table at each client, but the topology and other related informat= ion of the > network. Then the RR can compute a path for a specific source and destina= tion > pair, just like the traffic engineering, and then it advertises the relev= ant routes to > clients though the existing route reflection mechanisms. > > > >> --but even though SPF is trivial to run, there are still problems with= this > >> solution. First, you can't run SPF for a router that's not in your flo= oding > >> domain. Second, you can't take into account any local policies configu= red on > >> the router you're running SPF from the perspective of. > > > > The RR and the routers/clients do not have to be in the same flooding d= omain, > the RR can establish IGP multiple adjacencies with domains (per adjacency= per > domain) or use BGP-LS to collect the topology information. > > > > Regarding to the local policies, if want the RR the consider the local = policies, > there have to be some mechanisms to collect the local policies and just c= onfigure > it on the RR. > > > >> > >> Hence --just use i2rs to peek into the RR clients local routing table,= and > >> send the client the right BGP route(s) as indicated (using add-paths t= o > >> include more than one path if needed, for load sharing or the like). > >> > >> This would probably fit better into the BGP use cases draft, rather th= an the > >> one I'm co-authoring --OTOH, I thought we were merging these two into = a > >> single use cases draft covering all the "first line" use cases i2rs wo= uld > >> like to cover. > >> > >> Thoughts? > >> > >> :-) > >> > >> Russ > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs From rraszuk@gmail.com Mon Jul 22 03:48: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 9270E11E811D; Mon, 22 Jul 2013 03:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.774 X-Spam-Level: X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejwG1HF78eiR; Mon, 22 Jul 2013 03:48:10 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CBE2011E812D; Mon, 22 Jul 2013 03:42:18 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so14765731iea.18 for ; Mon, 22 Jul 2013 03:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H0krPrIBJfdBepywKah1yaJhVeEXVL+MsUVQ3TfbNOU=; b=c+Aa71LN3kw/9PjmcHej9dA1ntT6mQCOaLQs98lz3HWop+1Buj5GeWH7rGRXZJG5yg itEcCGF1NBqmMILoRW6CjP+SkO0puF9tiUlvSqq93jiIw1s7IIb1q7Rk06iq1Ql7skKO G1YuZ7x4AmJkpKawWgttGzajTky5tMv1DmCpvRgBcD85G657aLR2G7S/k987YletLg5W viLLIHzzQkKb5ovCOX5ozgZAZUtZBcldrP02E0Vabj0VhheL2EznOG45F2KlWKCoH50s isx828wF/9l+1AljY6RQoBacuc8QNcOS1N/QzhpOliAEF2yYuv8zcS6HPgjRTzZUXY4W dEsA== MIME-Version: 1.0 X-Received: by 10.42.43.202 with SMTP id y10mr16706932ice.28.1374489326773; Mon, 22 Jul 2013 03:35:26 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.28.168 with HTTP; Mon, 22 Jul 2013 03:35:26 -0700 (PDT) In-Reply-To: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> Date: Mon, 22 Jul 2013 12:35:26 +0200 X-Google-Sender-Auth: yONinWFOhYHrchY-rIR-l6NzfI4 Message-ID: From: Robert Raszuk To: Mach Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "i2rs@ietf.org" , "zhuyq@gsta.com" , wangsb , "idr@ietf.org" Subject: Re: [Idr] [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case 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, 22 Jul 2013 10:48:27 -0000 Hello Mach, > But, just as Russ summarized, the use cases introduced in this draft (use= case 1 and 2) require to > calculate the route from the eBGP peer's perspective, hence to optimize t= he traffic flow between > eBGP peers (between MANs). This seems not be solved by the ORR and draft-= varlashkin. In the route reflection based networks eBGP peers are also RR clients. The ORR draft allows you to choose the correct exit path for given prefix based on set of criteria. Such criteria can be IGP metric based or any other set of constrain as determined by the operator. Now if your requirement is: The requirement would like this: the traffic between MAN1 and MAN2 is required to follow the path: E-A-B; and the traffic between MAN1 and MAN3 is required to follow the path: E-D-C. then the correct way to solve it is to use either IGP Segment Routing, MPLS-TE or BGP Vector Routing proposals. I am of the strong opinion that the solution proposed in your draft to steer traffic via customized IBGP P router's programming with hop by hop different next hop setting is very problematic. BGP is not a right protocol for IGP traffic steering. In your example: For example, for a path from Source 1 (S1) to Destination 1 (D1), if the computed path is: S1-A-B-C-D1, then the RR will distribute a route (D1) to C with the nexthop set to D1; a route (D1) to B with the nexthop set to C, and a route (D1) to A with the nexthop set to B, and finally the route (D1) will be distributed to S1 by A. you only list steady state. At any IGP P node failure case you are to again depend on your RR reprogramming selective nodes to stop traffic drops and repair the intra-domain path. Btw the difference of the above as compared with BGP Vector Routing proposal http://goo.gl/qutBU is that upon the failure of any Vector Node (signaled via the IGP) such node would not be considered and next Vector Node (or final next hop) would be used as the next encapsulation point. Your proposal does not seem to have such local path repair ability. Btw this is typical illustration where number of "SDN" folks who push for massive centralization of everything do not realize a benefit of having in each domain robust IGP transport and a BGP used as an service overlay on top of it. Best regards, R. > On Mon, Jul 22, 2013 at 8:20 AM, Mach Chen wrote: > > Hi Robert, > > Many thanks for spending time to read the draft and your comments! > > If I understand the ORR and draft-varlashkin correctly, they both try to = calculate (from the client's perspective) the best route that is from the c= lient to destination/nexthop. > > But, just as Russ summarized, the use cases introduced in this draft (use= case 1 and 2) require to calculate the route from the eBGP peer's perspect= ive, hence to optimize the traffic flow between eBGP peers (between MANs). = This seems not be solved by the ORR and draft-varlashkin. > > Best regards, > Mach > >> -----Original Message----- >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert >> Raszuk >> Sent: Friday, July 19, 2013 9:56 PM >> To: Mach Chen >> Cc: Russ White; i2rs@ietf.org; idr@ietf.org; zhuyq@gsta.com >> Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering= -usecase >> as an I2RS Use Case >> >> Hi Mach, >> >> I have read your draft. I find nothing there which is not already >> solved by IDR WG document >> http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection-0= 5 >> >> The status of this WG document is pending two implementations. >> >> If you see anything technically missing in this draft possibly along >> with draft-varlashkin-bgp-nh-cost-02 let's discuss. >> >> Best regards, >> R. >> >> >> On Wed, Jul 17, 2013 at 11:59 AM, Mach Chen wrote= : >> > Hi Russ, >> > >> > Thanks for bringing up this discussion! >> > >> > Please see my reply inline... >> > >> > Best regards, >> > Mach >> > >> >> -----Original Message----- >> >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behalf = Of Russ >> >> White >> >> Sent: Monday, July 15, 2013 8:45 PM >> >> To: i2rs@ietf.org >> >> Cc: zhuyq@gsta.com >> >> Subject: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-= usecase as >> an >> >> I2RS Use Case >> >> >> >> Y'all: >> >> >> >> It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usecas= e might >> >> provide a solid use case to add to one of our use case drafts in I2RS= . The >> >> basic idea is this: >> >> >> >> Rather than advertising multiple routes using something like add-path= s to >> >> optimize traffic flow between eBGP edges, why not just have the RR >> advertise >> >> only the route that's best from each eBGP speaker's perspective? Now,= I have >> >> a long standing desire to see it implemented. OTOH, even if add-paths= is >> >> implemented, there is the issue of which set of paths to send to the = RR >> >> clients in any given situation. So I don't see >> >> draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to >> >> add-paths, but rather a complimentary idea. >> > >> > I agree if the RR wants to advertise more than one routes to the clien= ts. >> > >> >> >> >> But how is the RR to know which path to send to which RR client? This= is >> >> where i2rs seems to fit. If the RR was attached to a controller that = had >> >> visibility into the layer 3 routing table at each RR client, that >> >> information could be used to determine which path to send where. The = RR >> >> could also calculate the best path from the perspective of each RR cl= ient >> > >> > Yes, this is one possible way to achieve it. Alternate way is that the= RR is the >> "controller" or part of a controller, it has not only the visibility int= o the layer 3 >> routing table at each client, but the topology and other related informa= tion of the >> network. Then the RR can compute a path for a specific source and destin= ation >> pair, just like the traffic engineering, and then it advertises the rele= vant routes to >> clients though the existing route reflection mechanisms. >> > >> >> --but even though SPF is trivial to run, there are still problems wit= h this >> >> solution. First, you can't run SPF for a router that's not in your fl= ooding >> >> domain. Second, you can't take into account any local policies config= ured on >> >> the router you're running SPF from the perspective of. >> > >> > The RR and the routers/clients do not have to be in the same flooding = domain, >> the RR can establish IGP multiple adjacencies with domains (per adjacenc= y per >> domain) or use BGP-LS to collect the topology information. >> > >> > Regarding to the local policies, if want the RR the consider the local= policies, >> there have to be some mechanisms to collect the local policies and just = configure >> it on the RR. >> > >> >> >> >> Hence --just use i2rs to peek into the RR clients local routing table= , and >> >> send the client the right BGP route(s) as indicated (using add-paths = to >> >> include more than one path if needed, for load sharing or the like). >> >> >> >> This would probably fit better into the BGP use cases draft, rather t= han the >> >> one I'm co-authoring --OTOH, I thought we were merging these two into= a >> >> single use cases draft covering all the "first line" use cases i2rs w= ould >> >> like to cover. >> >> >> >> Thoughts? >> >> >> >> :-) >> >> >> >> Russ >> >> >> >> _______________________________________________ >> >> i2rs mailing list >> >> i2rs@ietf.org >> >> https://www.ietf.org/mailman/listinfo/i2rs >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs From farmer@umn.edu Mon Jul 22 15:59: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 8574D11E8185 for ; Mon, 22 Jul 2013 15:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cOE+OLkTCz8 for ; Mon, 22 Jul 2013 15:59:45 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 533EF11E8184 for ; Mon, 22 Jul 2013 15:59:45 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 22 Jul 2013 17:59:40 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ie0-f178.google.com [209.85.223.178] #+LO+TR X-Umn-Classification: local Received: by mail-ie0-f178.google.com with SMTP id u16so16727192iet.37 for ; Mon, 22 Jul 2013 15:59:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=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=WrA3u9I5gx88Sbwf85fqVEg5YOURrcy7RqFm/kAtvxg=; b=k1XV2tbukMENWxTRpJTod15WYAlsRVGYrwMB6uD97ShvO870KjsgPqdI8c8aksW1TN eKqiMMC383d3AtsR7z8Cj75KYlAqgsSygmtndnxl18mLsp/lmS6Mcjw3eJ0zBbVEQ0Y1 NIh+xtxSorVA3ivcGhmkQQnn0RyrvVON6EW71duS3UOhxqCQ+Avk2znfwMNrBM+kk7iS oLl2K7LWB7inUuchNyG7Pi5PdyBA8B7RyUXLbgPp5GUllJkUFqjQ2OwZWhfGWHITVtXv WwlWA5JxQYh6K0Z3fwYvzgMBp4zcfWPKqGzWy8I5RDK06eSrXnVZpohHsHSFVQ5srLjd r7jw== X-Received: by 10.42.52.6 with SMTP id h6mr18379167icg.5.1374533980441; Mon, 22 Jul 2013 15:59:40 -0700 (PDT) X-Received: by 10.42.52.6 with SMTP id h6mr18379164icg.5.1374533980365; Mon, 22 Jul 2013 15:59:40 -0700 (PDT) Received: from x-128-101-234-179.uofm-secure.wireless.umn.edu (x-128-101-234-179.uofm-secure.wireless.umn.edu. [128.101.234.179]) by mx.google.com with ESMTPSA id w5sm2129915igz.10.2013.07.22.15.59.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 15:59:39 -0700 (PDT) Message-ID: <51EDB95A.7070400@umn.edu> Date: Mon, 22 Jul 2013 17:59:38 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jon Mitchell References: <20130717135445.22008.42400.idtracker@ietfa.amsl.com> In-Reply-To: <20130717135445.22008.42400.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn4RYxGXBjrdG8CqSUPlS4V0RiknRpwSxK7hUL8/y3SkWJykjkNw7++LjRLodAsN64A8eutcwq9ZNwkf6s5tPjMrZmPTCfxxHtTSxuOH0GGm0ofoxgnIoOnQc+cHeR9TJnDTKX/ Cc: Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-00.txt 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: Mon, 22 Jul 2013 22:59:50 -0000 This looks good to me and I support it continuing to move forward. But, I have a few relatively minor editorial Nits; - There is a Singular/Plural mismatch in the second paragraph of section 3, "last ASN of the 16 bit range, 65535, are reserved", should be "last ASN of the 16 bit range, 65535, is reserved". - There is another Singular/Plural mismatch in the first paragraph of section 4, "a Special Uses", should be ether be either "Special Uses", or "a Special Use". I think either way works fine, it just needs to match. (Sorry about that one, my bad, this was in the text I gave you) - I think the order of the sentences in the second paragraph of section 4 should be reversed. I think it would be better to start with "These last ASNs MUST NOT be advertised ...", then "Operators that choose to filter Private Use ASNs ... SHOULD also filter ...". The "MUST NOT advertise" is the primary requirement, and the "SHOULD filter" is really just a recommended way of achieving it. - I'm not sure, but maybe, the first use of "Private Use ASNs" in section 4 should include a reference to [I-D.ietf-idr-as-private-reservation] and eventually the RFC when published. Maybe the use in section 5 as well, but I'm less concerned about that one. Thanks On 7/17/13 08:54 , internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing Working Group of the IETF. > > Title : Reservation of Last Autonomous System (AS) Numbers > Author(s) : Jeffrey Haas > Jon Mitchell > Filename : draft-ietf-idr-last-as-reservation-00.txt > Pages : 4 > Date : 2013-07-15 > > Abstract: > This document reserves two Autonomous System numbers (ASNs) at the > end of the 16 bit and 32 bit ranges, described in this document as > "Last ASNs" and provides guidance to implementers and operators on > their use. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-last-as-reservation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-idr-last-as-reservation-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > -- ================================================ 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 mach.chen@huawei.com Tue Jul 23 02:13: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 D68B811E8103; Tue, 23 Jul 2013 02:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGqxae0AQcEI; Tue, 23 Jul 2013 02:13:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 130D811E8155; Tue, 23 Jul 2013 02:13:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR95769; Tue, 23 Jul 2013 09:13:42 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 10:13:29 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 23 Jul 2013 10:13:38 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Tue, 23 Jul 2013 17:12:23 +0800 From: Mach Chen To: Robert Raszuk Thread-Topic: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case Thread-Index: AQHOhIe/1DV2tpe+J0edLtmbNRgGA5lwODAQ///G/wCAAe6VIA== Date: Tue, 23 Jul 2013 09:12:22 +0000 Message-ID: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "i2rs@ietf.org" , "zhuyq@gsta.com" , wangsb , "idr@ietf.org" Subject: Re: [Idr] [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case 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, 23 Jul 2013 09:13:52 -0000 Hi Robert, Please see my reply inline... > -----Original Message----- > From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > Raszuk > Sent: Monday, July 22, 2013 6:35 PM > To: Mach Chen > Cc: Russ White; i2rs@ietf.org; idr@ietf.org; zhuyq@gsta.com; wangsb > Subject: Re: [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-= usecase > as an I2RS Use Case >=20 > Hello Mach, >=20 > > But, just as Russ summarized, the use cases introduced in this draft (u= se case 1 > and 2) require to > > calculate the route from the eBGP peer's perspective, hence to optimize= the > traffic flow between > > eBGP peers (between MANs). This seems not be solved by the ORR and > draft-varlashkin. >=20 >=20 > In the route reflection based networks eBGP peers are also RR clients. > The ORR draft allows you to choose the correct exit path for given > prefix based on set of criteria. Such criteria can be IGP metric based > or any other set of constrain as determined by the operator. Here the eBGP peers that I referred to are the eBGP speakers residing in ot= her AS (for example, the eBGP speakers in the MANs other than in the Core n= etwork). So, these eBGP speaker should not be the clients of the RR.=20 >=20 > Now if your requirement is: >=20 > The requirement > would like this: the traffic between MAN1 and MAN2 is required to > follow the path: E-A-B; and the traffic between MAN1 and MAN3 is > required to follow the path: E-D-C. >=20 > then the correct way to solve it is to use either IGP Segment Routing, > MPLS-TE or BGP Vector Routing proposals. You listed solutions are alternative ways to satisfy the above requirement,= we had considered and discussed these potential solutions with some custom= ers. Since these solutions will require either large network update(e.g., S= R) or to totally change to a new deployment solution (e.g, MPLS-TE). To dep= loy these solutions to solve the above issue is not practice, at least for = now or in near term.=20 The idea of the RRTS proposed in the draft is try to avoid large network up= date or bringing significant new solution to the product network, with the = idea of RRTS, most of the devices are not necessary to be updated.=20 >=20 > I am of the strong opinion that the solution proposed in your draft to > steer traffic via customized IBGP P router's programming with hop by > hop different next hop setting is very problematic. BGP is not a right > protocol for IGP traffic steering. In your example: >=20 > For example, for a path from Source 1 (S1) to Destination 1 (D1), if > the computed path is: S1-A-B-C-D1, then the RR will distribute a > route (D1) to C with the nexthop set to D1; a route (D1) to B with > the nexthop set to C, and a route (D1) to A with the nexthop set to > B, and finally the route (D1) will be distributed to S1 by A. >=20 > you only list steady state. At any IGP P node failure case you are to > again depend on your RR reprogramming selective nodes to stop traffic > drops and repair the intra-domain path. The concept of RRTS is similar to MPLS-TE, the path is an End-2-End path, t= he RR is responsible for path calculation and distribute the routes to rele= vant routers. The different is that MPLS-TE uses MPLS label to direct forwa= rding, RRTS uses IP routes to direct forwarding. We just leverage the BGP r= oute reflection mechanism to achieve this. So, for the failure case, RRTS also needs to calculate and "install" backup= path/routes, it also need do RR or FRR as well if needed.=20 >=20 > Btw the difference of the above as compared with BGP Vector Routing > proposal http://goo.gl/qutBU is that upon the failure of any Vector > Node (signaled via the IGP) such node would not be considered and next > Vector Node (or final next hop) would be used as the next > encapsulation point. Your proposal does not seem to have such local > path repair ability. Thanks for pointing out this, I have not read it and will read it later. >=20 > Btw this is typical illustration where number of "SDN" folks who push > for massive centralization of everything do not realize a benefit of > having in each domain robust IGP transport and a BGP used as an > service overlay on top of it. I know what you mean, and I also agree with you that it's not necessary to = centralize everything.=20 The RRTS idea does not intend to control everything, and it is not designed= for any networks, it tries to solve the use cases introduced in the draft = without large network updates.=20 Since the existing tools are limited, especially for the pure IP forwarding= network, it seems this may be the only way to control the forwarding path = in an explicit way.=20 In some customer's network, the IP Core network is not so dynamical as imag= ined. And furthermore, they may think it's better that the core network sho= uld be relatively static and controllable, hence they could conduct the tra= ffic easier. =20 Best regards, Mach >=20 > Best regards, > R. >=20 >=20 > > On Mon, Jul 22, 2013 at 8:20 AM, Mach Chen > wrote: > > > > Hi Robert, > > > > Many thanks for spending time to read the draft and your comments! > > > > If I understand the ORR and draft-varlashkin correctly, they both try t= o calculate > (from the client's perspective) the best route that is from the client to > destination/nexthop. > > > > But, just as Russ summarized, the use cases introduced in this draft (u= se case 1 > and 2) require to calculate the route from the eBGP peer's perspective, h= ence to > optimize the traffic flow between eBGP peers (between MANs). This seems n= ot > be solved by the ORR and draft-varlashkin. > > > > Best regards, > > Mach > > > >> -----Original Message----- > >> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert > >> Raszuk > >> Sent: Friday, July 19, 2013 9:56 PM > >> To: Mach Chen > >> Cc: Russ White; i2rs@ietf.org; idr@ietf.org; zhuyq@gsta.com > >> Subject: Re: [i2rs] Thoughts on > draft-chen-idr-rr-based-traffic-steering-usecase > >> as an I2RS Use Case > >> > >> Hi Mach, > >> > >> I have read your draft. I find nothing there which is not already > >> solved by IDR WG document > >> http://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-route-reflection= -05 > >> > >> The status of this WG document is pending two implementations. > >> > >> If you see anything technically missing in this draft possibly along > >> with draft-varlashkin-bgp-nh-cost-02 let's discuss. > >> > >> Best regards, > >> R. > >> > >> > >> On Wed, Jul 17, 2013 at 11:59 AM, Mach Chen > wrote: > >> > Hi Russ, > >> > > >> > Thanks for bringing up this discussion! > >> > > >> > Please see my reply inline... > >> > > >> > Best regards, > >> > Mach > >> > > >> >> -----Original Message----- > >> >> From: i2rs-bounces@ietf.org [mailto:i2rs-bounces@ietf.org] On Behal= f Of > Russ > >> >> White > >> >> Sent: Monday, July 15, 2013 8:45 PM > >> >> To: i2rs@ietf.org > >> >> Cc: zhuyq@gsta.com > >> >> Subject: [i2rs] Thoughts on > draft-chen-idr-rr-based-traffic-steering-usecase as > >> an > >> >> I2RS Use Case > >> >> > >> >> Y'all: > >> >> > >> >> It seems, to me, that draft-chen-idr-rr-based-traffic-steering-usec= ase > might > >> >> provide a solid use case to add to one of our use case drafts in I2= RS. The > >> >> basic idea is this: > >> >> > >> >> Rather than advertising multiple routes using something like add-pa= ths to > >> >> optimize traffic flow between eBGP edges, why not just have the RR > >> advertise > >> >> only the route that's best from each eBGP speaker's perspective? No= w, I > have > >> >> a long standing desire to see it implemented. OTOH, even if add-pat= hs is > >> >> implemented, there is the issue of which set of paths to send to th= e RR > >> >> clients in any given situation. So I don't see > >> >> draft-chen-idr-rr-based-traffic-steering-usecase as a competitor to > >> >> add-paths, but rather a complimentary idea. > >> > > >> > I agree if the RR wants to advertise more than one routes to the cli= ents. > >> > > >> >> > >> >> But how is the RR to know which path to send to which RR client? Th= is is > >> >> where i2rs seems to fit. If the RR was attached to a controller tha= t had > >> >> visibility into the layer 3 routing table at each RR client, that > >> >> information could be used to determine which path to send where. Th= e RR > >> >> could also calculate the best path from the perspective of each RR = client > >> > > >> > Yes, this is one possible way to achieve it. Alternate way is that t= he RR is the > >> "controller" or part of a controller, it has not only the visibility i= nto the layer 3 > >> routing table at each client, but the topology and other related infor= mation of > the > >> network. Then the RR can compute a path for a specific source and > destination > >> pair, just like the traffic engineering, and then it advertises the re= levant routes > to > >> clients though the existing route reflection mechanisms. > >> > > >> >> --but even though SPF is trivial to run, there are still problems w= ith this > >> >> solution. First, you can't run SPF for a router that's not in your = flooding > >> >> domain. Second, you can't take into account any local policies conf= igured > on > >> >> the router you're running SPF from the perspective of. > >> > > >> > The RR and the routers/clients do not have to be in the same floodin= g > domain, > >> the RR can establish IGP multiple adjacencies with domains (per adjace= ncy per > >> domain) or use BGP-LS to collect the topology information. > >> > > >> > Regarding to the local policies, if want the RR the consider the loc= al policies, > >> there have to be some mechanisms to collect the local policies and jus= t > configure > >> it on the RR. > >> > > >> >> > >> >> Hence --just use i2rs to peek into the RR clients local routing tab= le, and > >> >> send the client the right BGP route(s) as indicated (using add-path= s to > >> >> include more than one path if needed, for load sharing or the like)= . > >> >> > >> >> This would probably fit better into the BGP use cases draft, rather= than the > >> >> one I'm co-authoring --OTOH, I thought we were merging these two in= to a > >> >> single use cases draft covering all the "first line" use cases i2rs= would > >> >> like to cover. > >> >> > >> >> Thoughts? > >> >> > >> >> :-) > >> >> > >> >> Russ > >> >> > >> >> _______________________________________________ > >> >> i2rs mailing list > >> >> i2rs@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/i2rs > >> > _______________________________________________ > >> > i2rs mailing list > >> > i2rs@ietf.org > >> > https://www.ietf.org/mailman/listinfo/i2rs From rraszuk@gmail.com Tue Jul 23 04:28:34 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 C868211E8218; Tue, 23 Jul 2013 04:28:34 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePQYFyb4iHi5; Tue, 23 Jul 2013 04:28:34 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3081211E8204; Tue, 23 Jul 2013 04:28:34 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so9780639obb.8 for ; Tue, 23 Jul 2013 04:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/bGEiZtAxUtbqufCAg2WkA3Dgzck/ZwpZtBEVk9bRQw=; b=RkR++zFGAUGrJbDyZo6XagTw0bjWXXadEekLdt7zoqXiXy6BKH1OFBBtIcQsOnz+hw Q9fd8enr7OaoFmPqEy30+jUtUoJ2q1gLpBL+f9lop9OHuN6uA6I6cl3gWvQ9noIoTT2D +F0kWuXrQw4y9WOlNNIAeDtZAZsMUrEiDXRdmVRPxfDlv+tfqGldsGEvCu5hIUY0GnLE UtXozlh1oFx9so5RD3YSVuBFainHdcjlXNxXLcLf2xNU82nPnHNZmU6Bp8ACA8b7ntu9 EiBWaw9P4SywS8AAyMvwrEMvSQwnrVrRQEsmPrPmtfESq2HEK9TqL5hSNmG60/Bco9pc +UIA== MIME-Version: 1.0 X-Received: by 10.50.107.103 with SMTP id hb7mr21423260igb.25.1374578913677; Tue, 23 Jul 2013 04:28:33 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.64.28.168 with HTTP; Tue, 23 Jul 2013 04:28:33 -0700 (PDT) In-Reply-To: References: <027a01ce8159$0d2f28f0$278d7ad0$@riw.us> Date: Tue, 23 Jul 2013 13:28:33 +0200 X-Google-Sender-Auth: SazOe9rc9nrP20rezTpVJT0kS1A Message-ID: From: Robert Raszuk To: Mach Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "i2rs@ietf.org" , "zhuyq@gsta.com" , wangsb , "idr@ietf.org" Subject: Re: [Idr] [i2rs] Thoughts on draft-chen-idr-rr-based-traffic-steering-usecase as an I2RS Use Case 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, 23 Jul 2013 11:28:34 -0000 Hi Mach, > The concept of RRTS is similar to MPLS-TE, the path is an End-2-End path,= the RR is responsible for path calculation and distribute the routes to re= levant routers. The different is that MPLS-TE uses MPLS label to direct for= warding, RRTS uses IP routes to direct forwarding. We just leverage the BGP= route reflection mechanism to achieve this. > > So, for the failure case, RRTS also needs to calculate and "install" back= up path/routes, it also need do RR or FRR as well if needed. I am afraid that maybe I was not clear. I would like to observe that there is fundamental difference between RRTS and MPLS-TE or any other IGP centric traffic steering solutions. The former works on the basis of all BGP routes (could be millions) while the latter works on the basis of just proper steering via IGP to BGP next hops. Hence the latter allows indirection while the former does not. For me this is the most significant difference of both paradigms. Best regards, R. From jrmitche@puck.nether.net Tue Jul 23 19:09: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 61FE211E81B6 for ; Tue, 23 Jul 2013 19:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qtl7h7E954kb for ; Tue, 23 Jul 2013 19:09:24 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 7C26111E81B5 for ; Tue, 23 Jul 2013 19:09:24 -0700 (PDT) Received: from puck.nether.net (localhost [127.0.0.1]) by puck.nether.net (8.14.7/8.14.5) with ESMTP id r6O29NWd006200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Jul 2013 22:09:23 -0400 Received: (from jrmitche@localhost) by puck.nether.net (8.14.7/8.14.7/Submit) id r6O29MCT006199; Tue, 23 Jul 2013 22:09:22 -0400 Date: Tue, 23 Jul 2013 22:09:22 -0400 From: Jon Mitchell To: David Farmer Message-ID: <20130724020922.GA618@puck.nether.net> References: <20130717135445.22008.42400.idtracker@ietfa.amsl.com> <51EDB95A.7070400@umn.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51EDB95A.7070400@umn.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.1 (puck.nether.net [127.0.0.1]); Tue, 23 Jul 2013 22:09:23 -0400 (EDT) Cc: Jeffrey Haas , idr@ietf.org Subject: Re: [Idr] I-D Action: draft-ietf-idr-last-as-reservation-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: Wed, 24 Jul 2013 02:09:25 -0000 Inline, can pick these up in next (and hopefully final) rev. On 22/07/13 17:59 -0500, David Farmer wrote: > This looks good to me and I support it continuing to move forward. > > But, I have a few relatively minor editorial Nits; > > - There is a Singular/Plural mismatch in the second paragraph of > section 3, "last ASN of the 16 bit range, 65535, are reserved", > should be "last ASN of the 16 bit range, 65535, is reserved". [JM] I will fix the wording to be more clear but this is not a singular/plural mismatch, your snippet missed the subject which was "subset of BGP communities". > - There is another Singular/Plural mismatch in the first paragraph > of section 4, "a Special Uses", should be ether be either "Special > Uses", or "a Special Use". I think either way works fine, it just > needs to match. (Sorry about that one, my bad, this was in the text > I gave you) [JM] Will fix this wording. > > - I think the order of the sentences in the second paragraph of > section 4 should be reversed. I think it would be better to start > with "These last ASNs MUST NOT be advertised ...", then "Operators > that choose to filter Private Use ASNs ... SHOULD also filter ...". > The "MUST NOT advertise" is the primary requirement, and the "SHOULD > filter" is really just a recommended way of achieving it. [JM] Agreed. > > - I'm not sure, but maybe, the first use of "Private Use ASNs" in > section 4 should include a reference to > [I-D.ietf-idr-as-private-reservation] and eventually the RFC when [JM] I don't see anything in the style guide, but I have been assuming like most technical docs only the first mention of a term requires reference unless you are calling out specific terminology or section. This was done in the intro. From david.black@emc.com Sun Jul 28 05:58: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 A8E0321F8F29; Sun, 28 Jul 2013 05:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeKrnovZc9qv; Sun, 28 Jul 2013 05:58:08 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 805FC21F84CD; Sun, 28 Jul 2013 05:58:04 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6SCveiQ011990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jul 2013 08:57:45 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 28 Jul 2013 08:57:31 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6SCvUP4002504; Sun, 28 Jul 2013 08:57:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Sun, 28 Jul 2013 08:57:30 -0400 From: "Black, David" To: "Shitanshu Shah (svshah)" , "idr@ietf.org" , "tsvwg@ietf.org" Date: Sun, 28 Jul 2013 08:57:29 -0400 Thread-Topic: I-D Action: draft-ietf-idr-sla-exchange-01.txt Thread-Index: AQHOc0Ki0np6g8+K9U6RkYxz8y4hCplJf5+AgDC8IgA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712984AD58B@MX15A.corp.emc.com> References: <20130627142833.21297.87327.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [Idr] I-D Action: draft-ietf-idr-sla-exchange-01.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: Sun, 28 Jul 2013 12:58:12 -0000 Shitanshu, The use of the IPFIX IANA registry and the TSpec are significant improvemen= ts. I noticed one more thing: The 0x07 =3D DROP_THRESHOLD Classifier Element value in a Traffic Class ap= pears to allow mixing of different types of drop thresholds. That seems like a b= ad idea, as I would expect most networks to be managed with a single primary t= ype of drop thresholds. I'd suggest one of two approaches: - Put the drop threshold type in the classifier element, and remove it from each drop-priority record. - Leave the type where it is, and state that mixing types SHOULD NOT be done, with a warning that inconsistent and unexpected behavior may result if types are mixed because the mappings between types may vary by network. Thanks, --David > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Shitanshu Shah (svshah) > Sent: Thursday, June 27, 2013 10:37 AM > To: idr@ietf.org; tsvwg@ietf.org > Subject: [tsvwg] FW: I-D Action: draft-ietf-idr-sla-exchange-01.txt >=20 >=20 > Dear WG, >=20 > Following is a revised draft incorporating feed-back/comments from the > last IETF. >=20 > Notable changes from the last revision, > - use of IPFIX IANA registry for Classifier Elements > - use of Tspec for SLA rates > - L2_OVERHEAD attribute to allow SLA advertise L3, L2 or customized L2 > rates >=20 > Please provide comments, >=20 > Regards, > Shitanshu >=20 >=20 > On 6/27/13 7:28 AM, "internet-drafts@ietf.org" > wrote: >=20 > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Inter-Domain Routing Working Group of > >the IETF. > > > > Title : Inter-domain SLA Exchange > > Author(s) : Shitanshu Shah > > Keyur Patel > > Sandeep Bajaj > > Luis Tomotaki > > Mohamed Boucadair > > Filename : draft-ietf-idr-sla-exchange-01.txt > > Pages : 24 > > Date : 2013-06-27 > > > >Abstract: > > Network administrators typically provision QoS (Quality of Service) > > policies for their application traffic (such as voice, video) based > > on SLAs (Service Level Agreements) negotiated with their providers, > > and translate those SLAs to vendor specific configuration language. > > Both learning of SLA, either thru SLA documents or via some other > > out-of-band method, and translating them to vendor specific > > configuration language is a complex, many times manual, process and > > prone to errors. This document proposes an in-band method of SLA > > signaling which can help to simplify some of the complexities. > > > > This document defines an operational transitive attribute to signal > > SLA details in-band, across administrative boundaries (considered as > > Autonomous Systems (AS)), thus simplify and speed-up some of the > > complex provisioning tasks. > > > > Though the use case with the proposed attribute is explicitly defined > > in this document, purpose of this attribute is not limited to this > > use case only. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-01 > > > >A diff from the previous version is available at: > >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sla-exchange-01 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www.ietf.org/mailman/listinfo/i-d-announce > >Internet-Draft directories: http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From wwwrun@rfc-editor.org Mon Jul 29 03:17:26 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 D620821E8098; Mon, 29 Jul 2013 03:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWpHKdJ8m5SB; Mon, 29 Jul 2013 03:17:26 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 4C49821E8097; Mon, 29 Jul 2013 03:17:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2250E6210F; Mon, 29 Jul 2013 03:14:05 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130729101405.2250E6210F@rfc-editor.org> Date: Mon, 29 Jul 2013 03:14:05 -0700 (PDT) Cc: drafts-update-ref@iana.org, idr@ietf.org, rfc-editor@rfc-editor.org Subject: [Idr] BCP 6, RFC 6996 on Autonomous System (AS) Reservation for Private Use 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, 29 Jul 2013 10:17:27 -0000 A new Request for Comments is now available in online RFC libraries. BCP 6 RFC 6996 Title: Autonomous System (AS) Reservation for Private Use Author: J. Mitchell Status: Best Current Practice Stream: IETF Date: July 2013 Mailbox: Jon.Mitchell@microsoft.com Pages: 4 Characters: 8198 Updates: RFC 1930 See Also: BCP 6 I-D Tag: draft-ietf-idr-as-private-reservation-05.txt URL: http://www.rfc-editor.org/rfc/rfc6996.txt This document describes the reservation of Autonomous System Numbers (ASNs) that are for Private Use only, known as Private Use ASNs, and provides operational guidance on their use. 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 of that document. This document is a product of the Inter-Domain Routing Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From svshah@cisco.com Mon Jul 29 07:23:34 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 B1B1711E80D7; Mon, 29 Jul 2013 07:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcN3pQ4g5i7h; Mon, 29 Jul 2013 07:23:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 471D321F9EA7; Mon, 29 Jul 2013 07:23:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4698; q=dns/txt; s=iport; t=1375107806; x=1376317406; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KUy0tsBbTaT1T7ln9JcIZNr8PwVGuGN522gp+MGMmVE=; b=Ak16M3L3fvgx4/uQixDdynyl+0QvyHPAgPAYkfxJeOOom9G0Kyew/7R1 bm/xtcIrNcrz4f905vGMVMUK6AZGy/PAFb45rCUbvx55vSKpvuLCI5HQE VGDXBzlnhmQefTUOfCzCmuSgw02vggktSXJFZyMQ4tR83P6+Q64bZZs0l 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFABd69lGtJXHB/2dsb2JhbABbgwY1Sga9WIEXFnSCJAEBAQQBAQE3MwEXBgEIEQQBAQEKFAkuCxQJCAIEARIIAYgHBwW4HI5IgQQzBQaDEm8DmQiLAIUjgxSBaEI X-IronPort-AV: E=Sophos;i="4.89,769,1367971200"; d="scan'208";a="240824634" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 29 Jul 2013 14:23:24 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6TENOxl013104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 14:23:24 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.98]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 09:23:24 -0500 From: "Shitanshu Shah (svshah)" To: "Black, David" , "idr@ietf.org" , "tsvwg@ietf.org" Thread-Topic: I-D Action: draft-ietf-idr-sla-exchange-01.txt Thread-Index: AQHOc0Ki0np6g8+K9U6RkYxz8y4hCplJf5+AgDC8IgCAAYqMAA== Date: Mon, 29 Jul 2013 14:23:23 +0000 Message-ID: In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712984AD58B@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.6.130613 x-originating-ip: [10.21.148.123] Content-Type: text/plain; charset="us-ascii" Content-ID: <32509D7901595B4490A6EE0990677433@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Idr] I-D Action: draft-ietf-idr-sla-exchange-01.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, 29 Jul 2013 14:23:35 -0000 Thank you David for your review and comments.. Regarding drop thresholds, indeed intention is to provide a facility to take multiple (type-value, burst) pairs but for a single primary type. Agreed, current definition in the draft is loose to interpret eligible use of multiple types for drop thresholds. I'll modify the structure for drop thresholds to take type definition once with multiple (type-value, burst) pairs. Regards, Shitanshu On 7/28/13 5:57 AM, "Black, David" wrote: > >Shitanshu, > >The use of the IPFIX IANA registry and the TSpec are significant >improvements. > >I noticed one more thing: > >The 0x07 =3D DROP_THRESHOLD Classifier Element value in a Traffic Class >appears >to allow mixing of different types of drop thresholds. That seems like a >bad >idea, as I would expect most networks to be managed with a single primary >type >of drop thresholds. I'd suggest one of two approaches: > > - Put the drop threshold type in the classifier element, and remove it > from each drop-priority record. > - Leave the type where it is, and state that mixing types SHOULD NOT be > done, with a warning that inconsistent and unexpected behavior > may result if types are mixed because the mappings between types > may vary by network. > >Thanks, >--David > > >> -----Original Message----- >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf >>Of >> Shitanshu Shah (svshah) >> Sent: Thursday, June 27, 2013 10:37 AM >> To: idr@ietf.org; tsvwg@ietf.org >> Subject: [tsvwg] FW: I-D Action: draft-ietf-idr-sla-exchange-01.txt >>=20 >>=20 >> Dear WG, >>=20 >> Following is a revised draft incorporating feed-back/comments from the >> last IETF. >>=20 >> Notable changes from the last revision, >> - use of IPFIX IANA registry for Classifier Elements >> - use of Tspec for SLA rates >> - L2_OVERHEAD attribute to allow SLA advertise L3, L2 or customized L2 >> rates >>=20 >> Please provide comments, >>=20 >> Regards, >> Shitanshu >>=20 >>=20 >> On 6/27/13 7:28 AM, "internet-drafts@ietf.org" >> >> wrote: >>=20 >> > >> >A New Internet-Draft is available from the on-line Internet-Drafts >> >directories. >> > This draft is a work item of the Inter-Domain Routing Working Group of >> >the IETF. >> > >> > Title : Inter-domain SLA Exchange >> > Author(s) : Shitanshu Shah >> > Keyur Patel >> > Sandeep Bajaj >> > Luis Tomotaki >> > Mohamed Boucadair >> > Filename : draft-ietf-idr-sla-exchange-01.txt >> > Pages : 24 >> > Date : 2013-06-27 >> > >> >Abstract: >> > Network administrators typically provision QoS (Quality of Service) >> > policies for their application traffic (such as voice, video) based >> > on SLAs (Service Level Agreements) negotiated with their providers, >> > and translate those SLAs to vendor specific configuration language. >> > Both learning of SLA, either thru SLA documents or via some other >> > out-of-band method, and translating them to vendor specific >> > configuration language is a complex, many times manual, process and >> > prone to errors. This document proposes an in-band method of SLA >> > signaling which can help to simplify some of the complexities. >> > >> > This document defines an operational transitive attribute to signal >> > SLA details in-band, across administrative boundaries (considered as >> > Autonomous Systems (AS)), thus simplify and speed-up some of the >> > complex provisioning tasks. >> > >> > Though the use case with the proposed attribute is explicitly >>defined >> > in this document, purpose of this attribute is not limited to this >> > use case only. >> > >> > >> >The IETF datatracker status page for this draft is: >> >https://datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange >> > >> >There's also a htmlized version available at: >> >http://tools.ietf.org/html/draft-ietf-idr-sla-exchange-01 >> > >> >A diff from the previous version is available at: >> >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-sla-exchange-01 >> > >> > >> >Internet-Drafts are also available by anonymous FTP at: >> >ftp://ftp.ietf.org/internet-drafts/ >> > >> >_______________________________________________ >> >I-D-Announce mailing list >> >I-D-Announce@ietf.org >> >https://www.ietf.org/mailman/listinfo/i-d-announce >> >Internet-Draft directories: http://www.ietf.org/shadow.html >> >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 > From jgs@juniper.net Wed Jul 31 09:22:01 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 8FA8821F9EF0 for ; Wed, 31 Jul 2013 09:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acWoBlWK05Rq for ; Wed, 31 Jul 2013 09:21:53 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id CDBDF21F9EDB for ; Wed, 31 Jul 2013 09:21:52 -0700 (PDT) Received: from mail192-db9-R.bigfish.com (10.174.16.242) by DB9EHSOBE033.bigfish.com (10.174.14.96) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 16:21:52 +0000 Received: from mail192-db9 (localhost [127.0.0.1]) by mail192-db9-R.bigfish.com (Postfix) with ESMTP id 056415001E5 for ; Wed, 31 Jul 2013 16:21:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VPS-19(zzc85fh1443I1453Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h1033IL8275dh1de097hz2fh2a8h683h839hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1b2bh1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e23h1e64h1155h) Received-SPF: pass (mail192-db9: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=jgs@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:132.245.1.149; KIP:(null); UIP:(null); (null); H:BLUPRD0512HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail192-db9 (localhost.localdomain [127.0.0.1]) by mail192-db9 (MessageSwitch) id 137528771014285_24657; Wed, 31 Jul 2013 16:21:50 +0000 (UTC) Received: from DB9EHSMHS022.bigfish.com (unknown [10.174.16.252]) by mail192-db9.bigfish.com (Postfix) with ESMTP id E93853C0069 for ; Wed, 31 Jul 2013 16:21:49 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.54) by DB9EHSMHS022.bigfish.com (10.174.14.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 16:21:44 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 09:21:42 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Wed, 31 Jul 2013 09:21:42 -0700 Received: from CO9EHSOBE026.bigfish.com (207.46.163.27) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Wed, 31 Jul 2013 09:34:39 -0700 Received: from mail3-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE026.bigfish.com (10.236.130.89) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 16:21:41 +0000 Received: from mail3-co9 (localhost [127.0.0.1]) by mail3-co9-R.bigfish.com (Postfix) with ESMTP id B106740201 for ; Wed, 31 Jul 2013 16:21:40 +0000 (UTC) Received: from mail3-co9 (localhost.localdomain [127.0.0.1]) by mail3-co9 (MessageSwitch) id 13752876341023_5647; Wed, 31 Jul 2013 16:20:34 +0000 (UTC) Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.251]) by mail3-co9.bigfish.com (Postfix) with ESMTP id 815A3C80075 for ; Wed, 31 Jul 2013 16:20:24 +0000 (UTC) Received: from BLUPRD0512HT003.namprd05.prod.outlook.com (132.245.1.149) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 16:20:22 +0000 Received: from [172.26.205.153] (193.110.54.36) by pod51010.outlook.com (10.255.215.164) with Microsoft SMTP Server (TLS) id 14.16.341.1; Wed, 31 Jul 2013 16:20:21 +0000 From: John Scudder Content-Type: multipart/alternative; boundary="Apple-Mail=_3F5A4ED7-C481-4474-B616-E8DAF4D9ADC4" Message-ID: <73C5C8E0-A9EC-407F-926C-48EDA228E58F@juniper.net> Date: Wed, 31 Jul 2013 18:20:18 +0200 To: "idr@ietf. org" MIME-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Originating-IP: [193.110.54.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 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Idr] need volunteers for jabber and notes for idr 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, 31 Jul 2013 16:22:01 -0000 --Apple-Mail=_3F5A4ED7-C481-4474-B616-E8DAF4D9ADC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Dear IDR Folks, Since Sue is unable to be at the meeting tomorrow, I will be chairing = single-handed. This means that unlike the last few meetings, it won't be = possible for one of the chairs to cover any of the note/jabber duties, = and we won't be able to start until we have a volunteer for each. Since = we have limited time and a lot of material to cover, it would really = help to have this sorted out before we get into the meeting room. Will someone please volunteer as the jabber scribe? This entails joining = the jabber room (xmpp:idr@jabber.ietf.org), keeping the jabber room up = to date regarding the slide we're on, and relaying any = questions/comments from the jabber room to the mic during Q/A. Anything = more than that (such as summarizing in-room discussion to the jabber = room) is optional. (For those who are willing but unfamiliar with = jabber, if you use a GTalk account I believe that should be sufficient = for you to connect.) Will someone please volunteer to take notes? By the way, if you do, I'd = find it useful if you inserted timestamps into the notes periodically, = as it helps with reviewing the audio recording if needed. It would be OK = to volunteer for just part of the meeting if you need to (but we will = need coverage for the whole meeting). Assuming we have volunteers before hand, we will start the meeting at = 15:20 sharp. Thanks in advance, --John= --Apple-Mail=_3F5A4ED7-C481-4474-B616-E8DAF4D9ADC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Dear = IDR Folks,

Since Sue is unable to be at the meeting = tomorrow, I will be chairing single-handed. This means that unlike the = last few meetings, it won't be possible for one of the chairs to cover = any of the note/jabber duties, and we won't be able to start until we = have a volunteer for each. Since we have limited time and a lot of = material to cover, it would really help to have this sorted out before = we get into the meeting room.

Will someone = please volunteer as the jabber scribe? This entails joining the jabber = room (xmpp:idr@jabber.ietf.org), = keeping the jabber room up to date regarding the slide we're on, and = relaying any questions/comments from the jabber room to the mic during = Q/A. Anything more than that (such as summarizing in-room discussion to = the jabber room) is optional. (For those who are willing but unfamiliar = with jabber, if you use a GTalk account I believe that should be = sufficient for you to connect.)

Will someone = please volunteer to take notes? By the way, if you do, I'd find it = useful if you inserted timestamps into the notes periodically, as it = helps with reviewing the audio recording if needed. It would be OK to = volunteer for just part of the meeting if you need to (but we will need = coverage for the whole meeting).

Assuming we = have volunteers before hand, we will start the meeting at 15:20 = sharp.

Thanks in = advance,

--John
= --Apple-Mail=_3F5A4ED7-C481-4474-B616-E8DAF4D9ADC4--