From martin.vigoureux@alcatel-lucent.com Tue Jun 4 10:15:09 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5891E21F9349 for ; Tue, 4 Jun 2013 10:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03zsAXoxOC6Q for ; Tue, 4 Jun 2013 10:15:02 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDF321F8F2F for ; Tue, 4 Jun 2013 08:14:55 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r54FEsFo006600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Jun 2013 10:14:54 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r54FElq8022343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Jun 2013 11:14:53 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Jun 2013 11:14:53 -0400 Received: from [172.27.205.109] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 4 Jun 2013 17:14:39 +0200 Message-ID: <51AE045E.8090005@alcatel-lucent.com> Date: Tue, 4 Jun 2013 17:14:38 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Subject: Fwd: Nomcom 2013-14 Volunteering - 2nd Call References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 17:15:09 -0000 all, please consider volunteering for this. Thank you. martin -------- Message original -------- Sujet: Nomcom 2013-14 Volunteering - 2nd Call Date : Wed, 29 May 2013 21:04:51 +0000 De : Mankin, Allison Répondre à : Pour : ietf-announce@ietf.org Copie à : Hi, everyone, Remember that I'm challenging the IETF to come up with 200 volunteers for the upcoming nomcom. You can volunteer just by hitting Reply to this email. What are you waiting for?? The more volunteers we get, the better chance we have of choosing a random yet representative cross section of the IETF population. Respond to the 200-volunteer challenge and hit Reply right now. (Well, much as I want you to do this, please look below at the posts being filled and be sure you are willing to forgo trying for any of them this year). The official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The details of the selection and operation of the nomcom can be found in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, reply to this email and volunteer. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. Being a nomcom member will require some time commitment - there will be interviews with candidates at meetings, regularly scheduled conference calls to ensure progress, collection and review of requirements from the commitment, review of candidate questionnaires and of community feedback. A more detailed timetable for the nomcom tasks will appear soon. Please respond to this email before 11:59 pm EDT (UTC -4 hours) June 16, 2013. In the body include: 1. your Given Name as you enter it when you register for the IETF 2. your Family Name as you enter it when you register for the IETF 3. your current primary affilation (the information you enter into the Company field) 4. any/all email addresses you've used to register for IETF meetings 5. which email address you prefer 6. your phone number (for our use in confirming you if selected). You should expect an email response from me within 3 business days stating whether or not you are qualified (and added to the list). If you don't receive this response, please re-send your email adding the tag "RESEND" to the subject line. Participating in the IETF nomcom is a meaningful and fun way to contribute to the IETF. Please help us meet the 200-volunteer challenge by hitting Reply to this message today. Allison Allison Mankin Nomcom Chair 2013-2014 From zzhang@juniper.net Wed Jun 5 12:45:15 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5096121F882A for ; Wed, 5 Jun 2013 12:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.202 X-Spam-Level: ** X-Spam-Status: No, score=2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FS_REPLICA=0.994, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_LOW=-1, SARE_URI_REPLICA=1.634, 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 hexJ+uHzvFey for ; Wed, 5 Jun 2013 12:45:09 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0886E21F86AE for ; Wed, 5 Jun 2013 12:45:08 -0700 (PDT) Received: from mail146-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Jun 2013 19:45:08 +0000 Received: from mail146-ch1 (localhost [127.0.0.1]) by mail146-ch1-R.bigfish.com (Postfix) with ESMTP id 59CBD60212 for ; Wed, 5 Jun 2013 19:45:08 +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: -24 X-BigFish: PS-24(zz9371I936eI1b0bI542Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz31h2a8h683h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: softfail (mail146-ch1: transitioning domain of juniper.net does not designate 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=zzhang@juniper.net; helo=P-EMHUB03-HQ.jnpr.net ; -HQ.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail146-ch1 (localhost.localdomain [127.0.0.1]) by mail146-ch1 (MessageSwitch) id 1370461505729399_26402; Wed, 5 Jun 2013 19:45:05 +0000 (UTC) Received: from CH1EHSMHS014.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail146-ch1.bigfish.com (Postfix) with ESMTP id B045F2C00B6 for ; Wed, 5 Jun 2013 19:45:05 +0000 (UTC) Received: from P-EMHUB03-HQ.jnpr.net (66.129.224.51) by CH1EHSMHS014.bigfish.com (10.43.70.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Jun 2013 19:45:05 +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; Wed, 5 Jun 2013 12:44:56 -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; Wed, 5 Jun 2013 12:44:55 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 5 Jun 2013 12:48:01 -0700 Received: from mail204-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Jun 2013 19:44:54 +0000 Received: from mail204-ch1 (localhost [127.0.0.1]) by mail204-ch1-R.bigfish.com (Postfix) with ESMTP id B448220242 for ; Wed, 5 Jun 2013 19:44:54 +0000 (UTC) Received: from mail204-ch1 (localhost.localdomain [127.0.0.1]) by mail204-ch1 (MessageSwitch) id 1370461492504199_905; Wed, 5 Jun 2013 19:44:52 +0000 (UTC) Received: from CH1EHSMHS030.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail204-ch1.bigfish.com (Postfix) with ESMTP id 78D0A40012D for ; Wed, 5 Jun 2013 19:44:52 +0000 (UTC) Received: from BY2PRD0510HT001.namprd05.prod.outlook.com (157.56.236.101) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Jun 2013 19:44:51 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.87]) by BY2PRD0510HT001.namprd05.prod.outlook.com ([10.255.84.36]) with mapi id 14.16.0311.000; Wed, 5 Jun 2013 19:44:51 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "l3vpn@ietf.org" Subject: FW: New Version Notification for draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00.txt Thread-Topic: New Version Notification for draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00.txt Thread-Index: AQHOYKSydEOZqoWNFkOhqsCArj2OzZkniGlw Date: Wed, 5 Jun 2013 19:44:50 +0000 Message-ID: <0BF0FCC78340F147BE76A6F5762318A835F21096@BY2PRD0510MB389.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 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-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:45:15 -0000 RllJDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5 LCBKdW5lIDAzLCAyMDEzIDU6NDkgUE0NClRvOiBZYWtvdiBSZWtodGVyOyBBbmRyZXcgRG9sZ2Fu b3c7IEplZmZyZXkgKFpoYW9odWkpIFpoYW5nDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LXp6aGFuZy1sM3Zwbi1tdnBuLWJpZGlyLWluZ3Jlc3MtcmVwbGljYXRp b24tMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXp6aGFuZy1sM3Zwbi1t dnBuLWJpZGlyLWluZ3Jlc3MtcmVwbGljYXRpb24tMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IEplZmZyZXkgWmhhbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVw b3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC16emhhbmctbDN2cG4tbXZwbi1iaWRpci1pbmdy ZXNzLXJlcGxpY2F0aW9uDQpSZXZpc2lvbjoJIDAwDQpUaXRsZToJCSBTaW11bGF0aW5nICJQYXJ0 aWFsIE1lc2ggb2YgTVAyTVAgUC1UdW5uZWxzIiB3aXRoIEluZ3Jlc3MgUmVwbGljYXRpb24NCkNy ZWF0aW9uIGRhdGU6CSAyMDEzLTA2LTAzDQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Ck51bWJlciBvZiBwYWdlczogMTMNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtenpoYW5nLWwzdnBuLW12cG4tYmlkaXItaW5ncmVzcy1y ZXBsaWNhdGlvbi0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC16emhhbmctbDN2cG4tbXZwbi1iaWRpci1pbmdyZXNzLXJlcGxpY2F0 aW9uDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXp6 aGFuZy1sM3Zwbi1tdnBuLWJpZGlyLWluZ3Jlc3MtcmVwbGljYXRpb24tMDANCg0KDQpBYnN0cmFj dDoNCiAgIFJGQyA2NTEzIGRlc2NyaWJlZCBhIG1ldGhvZCB0byBzdXBwb3J0IGJpZGlyZWN0aW9u YWwgQy1mbG93IHVzaW5nDQogICAiUGFydGlhbCBNZXNoIG9mIE1QMk1QIFAtVHVubmVscyIuICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cNCiAgIHBhcnRpYWwgbWVzaCBvZiBNUDJNUCBQLVR1 bm5lbHMgY2FuIGJlIHNpbXVsYXRlZCB3aXRoIEluZ3Jlc3MNCiAgIFJlcGxpY2F0aW9uLCBpbnN0 ZWFkIG9mIGEgcmVhbCBNUDJNUCB0dW5uZWwuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN Cg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0K From adrian@olddog.co.uk Fri Jun 7 07:31:28 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B3121F9843; Fri, 7 Jun 2013 07:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 WZgvF+m97hSY; Fri, 7 Jun 2013 07:31:23 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 2548021F9920; Fri, 7 Jun 2013 07:31:10 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57EV6D2007140; Fri, 7 Jun 2013 15:31:06 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r57EV5Kk007127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Jun 2013 15:31:06 +0100 From: "Adrian Farrel" To: , , , , Subject: Heads up : IETF Last Call on "Auto Discovery VPN Problem Statement and Requirements" Date: Fri, 7 Jun 2013 15:30:59 +0100 Message-ID: <0afa01ce638b$a2067820$e6136860$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5ji41bX64WTevZT8eVu8We0gvrYQ== Content-Language: en-gb Cc: draft-ietf-ipsecme-ad-vpn-problem.all@tools.ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 14:31:28 -0000 Hi VPN-related working groups, Please be aware of this document that is in IETF last call. Comments should be sent following the instructions in the email below and *not* to the mailing lists I have spammed. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 07 June 2013 15:00 > To: IETF-Announce > Cc: ipsec@ietf.org > Subject: Last Call: (Auto Discovery > VPN Problem Statement and Requirements) to Informational RFC > > > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > - 'Auto Discovery VPN Problem Statement and Requirements' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-06-21. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes the problem of enabling a large number of > systems to communicate directly using IPsec to protect the traffic > between them. It then expands on the requirements, for such a > solution. > > Manual configuration of all possible tunnels is too cumbersome in > many such cases. In other cases the IP address of endpoints change > or the endpoints may be behind NAT gateways, making static > configuration impossible. The Auto Discovery VPN solution will > address these requirements. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem/ballot/ > > > No IPR declarations have been submitted directly on this I-D. From wwwrun@rfc-editor.org Wed Jun 12 01:58:46 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D8421F9C15 for ; Wed, 12 Jun 2013 01:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, 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 SJ1qxN3bpzdJ for ; Wed, 12 Jun 2013 01:58:45 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8005621F9BF4 for ; Wed, 12 Jun 2013 01:58:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 39DF062114; Wed, 12 Jun 2013 01:56:58 -0700 (PDT) To: erosen@cisco.com, yakov@juniper.net, brian@innovationslab.net, ted.lemon@nominum.com, martin.vigoureux@alcatel-lucent.com, thomas.morin@orange.com Subject: [Editorial Errata Reported] RFC4364 (3647) From: RFC Errata System Message-Id: <20130612085658.39DF062114@rfc-editor.org> Date: Wed, 12 Jun 2013 01:56:58 -0700 (PDT) Cc: l3vpn@ietf.org, bharat_joshi@infosys.com, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 08:58:46 -0000 The following errata report has been submitted for RFC4364, "BGP/MPLS IP Virtual Private Networks (VPNs)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4364&eid=3647 -------------------------------------- Type: Editorial Reported by: Bharat Joshi Section: 3.2 Original Text ------------- If it is desired to have a particular host be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with. Corrected Text -------------- If it is desired to have a particular host to be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with. Notes ----- 'host be' should be 'host to be' 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. -------------------------------------- RFC4364 (draft-ietf-l3vpn-rfc2547bis-03) -------------------------------------- Title : BGP/MPLS IP Virtual Private Networks (VPNs) Publication Date : February 2006 Author(s) : E. Rosen, Y. Rekhter Category : PROPOSED STANDARD Source : Layer 3 Virtual Private Networks INT Area : Internet Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Jun 12 02:00:03 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B15221F9BF4 for ; Wed, 12 Jun 2013 02:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=0.285, 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 xxYTG0KNwfjL for ; Wed, 12 Jun 2013 02:00:02 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9929621F9BF1 for ; Wed, 12 Jun 2013 02:00:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 70A8E62114; Wed, 12 Jun 2013 01:58:07 -0700 (PDT) To: erosen@cisco.com, yakov@juniper.net, brian@innovationslab.net, ted.lemon@nominum.com, martin.vigoureux@alcatel-lucent.com, thomas.morin@orange.com Subject: [Editorial Errata Reported] RFC4364 (3648) From: RFC Errata System Message-Id: <20130612085810.70A8E62114@rfc-editor.org> Date: Wed, 12 Jun 2013 01:58:07 -0700 (PDT) Cc: l3vpn@ietf.org, bharat_joshi@infosys.com, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 09:00:03 -0000 The following errata report has been submitted for RFC4364, "BGP/MPLS IP Virtual Private Networks (VPNs)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4364&eid=3648 -------------------------------------- Type: Editorial Reported by: Bharat Joshi Section: 4 Original Text ------------- If two routes to the same IP address prefix are actually routes to different systems, it is important to ensure that BGP not treat them as comparable. Corrected Text -------------- If two routes to the same IP address prefix are actually routes to two different systems, it is important to ensure that BGP not treat them as comparable. Notes ----- 'routes to different system' should be 'routes to two different system' 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. -------------------------------------- RFC4364 (draft-ietf-l3vpn-rfc2547bis-03) -------------------------------------- Title : BGP/MPLS IP Virtual Private Networks (VPNs) Publication Date : February 2006 Author(s) : E. Rosen, Y. Rekhter Category : PROPOSED STANDARD Source : Layer 3 Virtual Private Networks INT Area : Internet Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Wed Jun 12 02:00:55 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B3721F9C19 for ; Wed, 12 Jun 2013 02:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.329 X-Spam-Level: X-Spam-Status: No, score=-102.329 tagged_above=-999 required=5 tests=[AWL=0.271, 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 scfo+7vkKA+P for ; Wed, 12 Jun 2013 02:00:55 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 49FBA21F9C15 for ; Wed, 12 Jun 2013 02:00:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C3A8E6211A; Wed, 12 Jun 2013 01:59:06 -0700 (PDT) To: erosen@cisco.com, yakov@juniper.net, brian@innovationslab.net, ted.lemon@nominum.com, martin.vigoureux@alcatel-lucent.com, thomas.morin@orange.com Subject: [Editorial Errata Reported] RFC4364 (3649) From: RFC Errata System Message-Id: <20130612085907.C3A8E6211A@rfc-editor.org> Date: Wed, 12 Jun 2013 01:59:06 -0700 (PDT) Cc: l3vpn@ietf.org, bharat_joshi@infosys.com, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 09:00:56 -0000 The following errata report has been submitted for RFC4364, "BGP/MPLS IP Virtual Private Networks (VPNs)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4364&eid=3649 -------------------------------------- Type: Editorial Reported by: Bharat Joshi Section: 4.3.2 Original Text ------------- Then if a route is potentially reachable over more than one attachment circuit, the PE/CE routing can switch the preferred path for a route from one attachment circuit to another, without there being any need to distribute new a label for that route Corrected Text -------------- Then if a route is potentially reachable over more than one attachment circuit, the PE/CE routing can switch the preferred path for a route from one attachment circuit to another, without there being any need to distribute a new label for that route Notes ----- 'distribute new a label' should be 'distribute a new label'. 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. -------------------------------------- RFC4364 (draft-ietf-l3vpn-rfc2547bis-03) -------------------------------------- Title : BGP/MPLS IP Virtual Private Networks (VPNs) Publication Date : February 2006 Author(s) : E. Rosen, Y. Rekhter Category : PROPOSED STANDARD Source : Layer 3 Virtual Private Networks INT Area : Internet Stream : IETF Verifying Party : IESG From prvs=68753ead19=jakob.heitz@ericsson.com Wed Jun 12 06:48:14 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A3721F9B42 for ; Wed, 12 Jun 2013 06:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 cS1jXCyKHpxD for ; Wed, 12 Jun 2013 06:48:08 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 48DA021F9BAF for ; Wed, 12 Jun 2013 06:48:04 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-1f-51b87c120c79 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 61.FA.17537.21C78B15; Wed, 12 Jun 2013 15:48:03 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 09:48:02 -0400 From: Jakob Heitz To: RFC Errata System Subject: Re: [Editorial Errata Reported] RFC4364 (3647) Thread-Topic: [Editorial Errata Reported] RFC4364 (3647) Thread-Index: AQHOZ0sO8xTieSiCH0OflOSMLCND85kyGFPB Date: Wed, 12 Jun 2013 13:48:01 +0000 Message-ID: <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> References: <20130612085658.39DF062114@rfc-editor.org> In-Reply-To: <20130612085658.39DF062114@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonQVe4ZkegwYMfghY/Tj9nt5jZ84/R Yt3dSSwWZ+f7W9zZ9YXVomn/VzaLrd2xFhv2HWWzOP7jG7sDp0frs72sHlN+b2T1WLLkJ5PH gklt7B4zj39h8bjedJXd4/WB+aweLc9Osnk0tB1jDeCM4rZJSiwpC85Mz9O3S+DOaOnbwVyw XaDizUS3BsY3PF2MnBwSAiYSzXf62CFsMYkL99azdTFycQgJHGWUmP73FjOEs5xRYs/uH2BV bAI6Et+udzGD2CIChhIHF71lByliFrjNLHF/zyUWkISwgLnEny/97BBFFhJNe+5D2UYSe49c ZAWxWQRUJc7tu8kIYvMK2EtsbNsMZgsJmEks3vQHrIYTaM6DOf/A4oxA530/tYYJxGYWEJe4 9WQ+E8TZAhJL9pxnhrBFJV4+/scKUaMjsWD3JzYIW1ti2cLXzBC7BCVOznzCMoFRdBaSUbOQ tMxC0jILScsCRpZVjBylxalluelGBpsYgZF5TIJNdwfjnpeWhxilOViUxHkjVHcECgmkJ5ak ZqemFqQWxReV5qQWH2Jk4uAEEVxSDYwzy4JPf5zvYW9zJ6ti4p8THTfzDxns3Pjq7KeXjiZF QTreDHwm+cUx/J1p6zbuTd4zb+Z9NdekVEdugSsMe3RZXMLVD/1zd7po6uDy+/sWWdPOV4cF gpIqdvbeW5or9c2GPdn1U5vU3rcHeaZcmG5xRvbTqvV/QjtOTl6lddgygvW/QdiFoGlKLMUZ iYZazEXFiQCtqQp5nwIAAA== Cc: "brian@innovationslab.net" , "l3vpn@ietf.org" , "yakov@juniper.net" , "ted.lemon@nominum.com" , "bharat_joshi@infosys.com" , "erosen@cisco.com" , "thomas.morin@orange.com" , "rfc-editor@rfc-editor.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 13:48:14 -0000 This is not necessary. The original is correct grammar. "be" is being used in the subjunctive form. A more modern alternative might be "If a particular host is desired to be i= n multiple virtual sites,", but the original is correct, so why bother? -- Jakob Heitz. On Jun 12, 2013, at 1:58 AM, "RFC Errata System" wrote: > The following errata report has been submitted for RFC4364, > "BGP/MPLS IP Virtual Private Networks (VPNs)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4364&eid=3D3647 >=20 > -------------------------------------- > Type: Editorial > Reported by: Bharat Joshi >=20 > Section: 3.2 >=20 > Original Text > ------------- > If it is desired to have a particular host be in multiple virtual sites, = then that host must determine, for each packet, which virtual site the pack= et is associated with.=20 >=20 >=20 > Corrected Text > -------------- > If it is desired to have a particular host to be in multiple virtual site= s, then that host must determine, for each packet, which virtual site the p= acket is associated with. >=20 > Notes > ----- > 'host be' should be 'host to be' >=20 > 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.=20 >=20 > -------------------------------------- > RFC4364 (draft-ietf-l3vpn-rfc2547bis-03) > -------------------------------------- > Title : BGP/MPLS IP Virtual Private Networks (VPNs) > Publication Date : February 2006 > Author(s) : E. Rosen, Y. Rekhter > Category : PROPOSED STANDARD > Source : Layer 3 Virtual Private Networks INT > Area : Internet > Stream : IETF > Verifying Party : IESG From prvs=9875a6b67b=acee.lindem@ericsson.com Wed Jun 12 07:00:14 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2527221F9AF7 for ; Wed, 12 Jun 2013 07:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 MVKkjPK2Odjg for ; Wed, 12 Jun 2013 07:00:08 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA5821F9B27 for ; Wed, 12 Jun 2013 07:00:05 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-ae-51b87ee5173f Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 70.E7.05617.5EE78B15; Wed, 12 Jun 2013 16:00:05 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 10:00:04 -0400 From: Acee Lindem To: Jakob Heitz Subject: Re: [Editorial Errata Reported] RFC4364 (3647) Thread-Topic: [Editorial Errata Reported] RFC4364 (3647) Thread-Index: AQHOZ0sOPd/OrRsHM0aZga92q8e5MJkyW2CAgAADXYA= Date: Wed, 12 Jun 2013 14:00:04 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE471651ED@eusaamb101.ericsson.se> References: <20130612085658.39DF062114@rfc-editor.org> <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> In-Reply-To: <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <847CF110599841408D4E6FF8B30BC650@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyuXSPn+7Tuh2BBlPapS1+nH7ObjGz5x+j xbq7k1gszs73t2ja/5XNYmt3rMWGfUfZLI7/+MbuwOEx5fdGVo8lS34yeSyY1MbuMfP4FxaP 601X2T1eH5jP6tHy7CSbR0PbMdYAjihum6TEkrLgzPQ8fbsE7ozGpgNMBdeFK6a0rmRtYNzL 38XIySEhYCJx69V7JghbTOLCvfVsXYxcHEICRxklLl74wgThLGeUuHfoOFgVm4COxPNH/5i7 GDk4RAS0JE4eYAepYRZoYpb4sGgrG0iNsIC5xJ8v/ewgtoiAhUTTnvtQtpXEo2/LwOawCKhK /Jj4gxnE5hXwluhevIEVxBYSyJGY9LAbzOYUcJBo6lgANpMR6Lrvp9aA9TILiEvcejIf6moB iSV7zjND2KISLx//Y4WwlSWWPNnPAlGvI7Fg9yc2CNtaoufPTlYIW1ti2cLXUDcISpyc+YRl AqP4LCQrZiFpn4WkfRaS9llI2hcwsq5i5CgtTi3LTTcy3MQIjOZjEmyOOxgXfLI8xCjNwaIk zhuruiNQSCA9sSQ1OzW1ILUovqg0J7X4ECMTByeI4JJqYAx6PfXQdXdNSwee4tTY/yEWq70a zvsprwv6xKPxq33a8u6ONlffiHkdab02rtzrfF8uXmZVOst/kqHgwf2VrS+vH7j19OjDzKML ctpm/w47FDu7YbXPKoPQFO/lRz0cy7QmvlwhrxqbFP/Jd5vyccmYpp2nitdE9x67VTHtYvDt lgbVnULnDZVYijMSDbWYi4oTAS86EbK5AgAA Cc: "brian@innovationslab.net" , "l3vpn@ietf.org" , "yakov@juniper.net" , "ted.lemon@nominum.com" , "bharat_joshi@infosys.com" , "erosen@cisco.com" , "thomas.morin@orange.com" , RFC Errata System X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 14:00:14 -0000 I think one problem with the errata process is that the you have to be an A= D in order to validate or reject them. The WG chairs should also have the a= uthority to summarily reject errata - especially the nuisance errata that a= re being submitted these days.=20 Thanks, Acee=20 On Jun 12, 2013, at 9:48 AM, Jakob Heitz wrote: > This is not necessary. The original is correct grammar. > "be" is being used in the subjunctive form. >=20 > A more modern alternative might be "If a particular host is desired to be= in multiple virtual sites,", but the original is correct, so why bother? >=20 > -- > Jakob Heitz. >=20 >=20 > On Jun 12, 2013, at 1:58 AM, "RFC Errata System" wrote: >=20 >> The following errata report has been submitted for RFC4364, >> "BGP/MPLS IP Virtual Private Networks (VPNs)". >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D4364&eid=3D3647 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Bharat Joshi >>=20 >> Section: 3.2 >>=20 >> Original Text >> ------------- >> If it is desired to have a particular host be in multiple virtual sites,= then that host must determine, for each packet, which virtual site the pac= ket is associated with.=20 >>=20 >>=20 >> Corrected Text >> -------------- >> If it is desired to have a particular host to be in multiple virtual sit= es, then that host must determine, for each packet, which virtual site the = packet is associated with. >>=20 >> Notes >> ----- >> 'host be' should be 'host to be' >>=20 >> 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.=20 >>=20 >> -------------------------------------- >> RFC4364 (draft-ietf-l3vpn-rfc2547bis-03) >> -------------------------------------- >> Title : BGP/MPLS IP Virtual Private Networks (VPNs) >> Publication Date : February 2006 >> Author(s) : E. Rosen, Y. Rekhter >> Category : PROPOSED STANDARD >> Source : Layer 3 Virtual Private Networks INT >> Area : Internet >> Stream : IETF >> Verifying Party : IESG From Ted.Lemon@nominum.com Wed Jun 12 07:10:41 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB1E21F9942 for ; Wed, 12 Jun 2013 07:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.611 X-Spam-Level: X-Spam-Status: No, score=-106.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rAwT4IrIwKvN for ; Wed, 12 Jun 2013 07:10:35 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 80F8221F9BC1 for ; Wed, 12 Jun 2013 07:10:33 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUbiBWdfA9ecD4xXTzyb8ZMY2zUtbNk+D@postini.com; Wed, 12 Jun 2013 07:10:33 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0CB6A1B81D1 for ; Wed, 12 Jun 2013 07:10:33 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0580D19005D; Wed, 12 Jun 2013 07:10:33 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 07:10:33 -0700 From: Ted Lemon To: Acee Lindem Subject: Re: [Editorial Errata Reported] RFC4364 (3647) Thread-Topic: [Editorial Errata Reported] RFC4364 (3647) Thread-Index: AQHOZ0sMFcZcbmvbMEGi5O0V6rfSKpkyjauAgAADXgCAAALrgA== Date: Wed, 12 Jun 2013 14:10:32 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D2F85@mbx-01.win.nominum.com> References: <20130612085658.39DF062114@rfc-editor.org> <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> <94A203EA12AECE4BA92D42DBFFE0AE471651ED@eusaamb101.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE471651ED@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "brian@innovationslab.net" , "l3vpn@ietf.org" , "yakov@juniper.net" , "bharat_joshi@infosys.com" , "erosen@cisco.com" , "thomas.morin@orange.com" , RFC Errata System X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 14:10:41 -0000 On Jun 12, 2013, at 10:00 AM, Acee Lindem wrote: > I think one problem with the errata process is that the you have to be an= AD in order to validate or reject them. The WG chairs should also have the= authority to summarily reject errata - especially the nuisance errata that= are being submitted these days.=20 That sounds great in theory, but I think it would be difficult to write the= code that decided which working group chairs got to modify which errata. = We recently got a typo erratum on RFC 917. From bharat_joshi@infosys.com Wed Jun 12 08:07:26 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E22721F99A5 for ; Wed, 12 Jun 2013 08:07:26 -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 i2VCeuzXV1+H for ; Wed, 12 Jun 2013 08:07:21 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5636F21F9952 for ; Wed, 12 Jun 2013 08:07:20 -0700 (PDT) X-TM-IMSS-Message-ID: <4f131ca2000cf0af@infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 4f131ca2000cf0af ; Wed, 12 Jun 2013 20:35:45 +0530 Received: from BLRKECHUB08.ad.infosys.com (10.66.236.138) by blrkechub03.ad.infosys.com (10.66.236.43) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Jun 2013 20:36:41 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB08.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 20:36:40 +0530 From: Bharat Joshi To: Jakob Heitz , RFC Errata System Subject: RE: [Editorial Errata Reported] RFC4364 (3647) Thread-Topic: [Editorial Errata Reported] RFC4364 (3647) Thread-Index: AQHOZ0sGttydbyf7J0yB1Ona9nBXFZkxvB+AgABxWQk= Date: Wed, 12 Jun 2013 15:06:40 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E66F8D@BLRKECMBX13.ad.infosys.com> References: <20130612085658.39DF062114@rfc-editor.org>, <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> In-Reply-To: <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.37.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 12 Jun 2013 08:16:11 -0700 Cc: "brian@innovationslab.net" , "l3vpn@ietf.org" , "yakov@juniper.net" , "ted.lemon@nominum.com" , "erosen@cisco.com" , "thomas.morin@orange.com" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 15:07:26 -0000 Thanks for your reply. While reading, I felt that adding a 'to' here make things more clearer. As you mentioned that the existing one is correct, so its ok. Regards, Bharat ________________________________________ From: Jakob Heitz [jakob.heitz@ericsson.com] Sent: Wednesday, June 12, 2013 7:18 PM To: RFC Errata System Cc: erosen@cisco.com; yakov@juniper.net; brian@innovationslab.net; ted.le= mon@nominum.com; martin.vigoureux@alcatel-lucent.com; thomas.morin@orange= .com; l3vpn@ietf.org; Bharat Joshi; rfc-editor@rfc-editor.org Subject: Re: [Editorial Errata Reported] RFC4364 (3647) This is not necessary. The original is correct grammar. "be" is being used in the subjunctive form. A more modern alternative might be "If a particular host is desired to be= in multiple virtual sites,", but the original is correct, so why bother? -- Jakob Heitz. On Jun 12, 2013, at 1:58 AM, "RFC Errata System" wrote: > The following errata report has been submitted for RFC4364, > "BGP/MPLS IP Virtual Private Networks (VPNs)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4364&eid=3D3647 > > -------------------------------------- > Type: Editorial > Reported by: Bharat Joshi > > Section: 3.2 > > Original Text > ------------- > If it is desired to have a particular host be in multiple virtual sites= , then that host must determine, for each packet, which virtual site the = packet is associated with. > > > Corrected Text > -------------- > If it is desired to have a particular host to be in multiple virtual si= tes, then that host must determine, for each packet, which virtual site t= he packet is associated with. > > Notes > ----- > 'host be' should be 'host to be' > > 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. > > -------------------------------------- > RFC4364 (draft-ietf-l3vpn-rfc2547bis-03) > -------------------------------------- > Title : BGP/MPLS IP Virtual Private Networks (VPNs) > Publication Date : February 2006 > Author(s) : E. Rosen, Y. Rekhter > Category : PROPOSED STANDARD > Source : Layer 3 Virtual Private Networks INT > Area : Internet > Stream : IETF > Verifying Party : IESG **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From brian@innovationslab.net Wed Jun 12 08:32:22 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEBE111E80D3 for ; Wed, 12 Jun 2013 08:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 5Hz0pSZXXWKH for ; Wed, 12 Jun 2013 08:32:16 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6511611E80A2 for ; Wed, 12 Jun 2013 08:32:13 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 10705880D2; Wed, 12 Jun 2013 08:32:13 -0700 (PDT) Received: from 10252377.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 30257130003; Wed, 12 Jun 2013 08:32:12 -0700 (PDT) Message-ID: <51B8947E.6080200@innovationslab.net> Date: Wed, 12 Jun 2013 11:32:14 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bharat Joshi Subject: Re: [Editorial Errata Reported] RFC4364 (3647) References: <20130612085658.39DF062114@rfc-editor.org>, <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> <35347FBF2796F94E936EE76C0E6047ED32E66F8D@BLRKECMBX13.ad.infosys.com> In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED32E66F8D@BLRKECMBX13.ad.infosys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "l3vpn@ietf.org" , "yakov@juniper.net" , "ted.lemon@nominum.com" , "erosen@cisco.com" , "thomas.morin@orange.com" , RFC Errata System X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 15:32:22 -0000 Hi Bharat, On 6/12/13 11:06 AM, Bharat Joshi wrote: > Thanks for your reply. > > While reading, I felt that adding a 'to' here make things more clearer. It does make things clearer, but the original wording is correct. > > As you mentioned that the existing one is correct, so its ok. > I believe that holds for all three errata opened on this document. Unless someone objects, I will mark all three (3647, 3648, & 3649) as "Rejected". Regards, Brian From thomas.morin@orange.com Wed Jun 12 08:38:55 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2F521E8050 for ; Wed, 12 Jun 2013 08:38:55 -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, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gmVN4hoqUyf for ; Wed, 12 Jun 2013 08:38:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C2EDB21F99AA for ; Wed, 12 Jun 2013 08:38:48 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A7ED73250B9; Wed, 12 Jun 2013 17:38:46 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 61F5F35C065; Wed, 12 Jun 2013 17:38:46 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 17:38:45 +0200 From: To: Brian Haberman Subject: Re: [Editorial Errata Reported] rfc4364 (3647) Thread-Topic: [Editorial Errata Reported] rfc4364 (3647) Thread-Index: AQHOZ0sMiWsknLVYD0ieJC66OqmSNZkx9suAgAAV+QCAAAclAIAAAdKA Date: Wed, 12 Jun 2013 15:38:45 +0000 Message-ID: <29969_1371051526_51B89606_29969_376_1_AC1ADC68A92CF94FA8CFCB406C1CBE3D0745F2FA@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20130612085658.39DF062114@rfc-editor.org>, <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> <35347FBF2796F94E936EE76C0E6047ED32E66F8D@BLRKECMBX13.ad.infosys.com> <51B8947E.6080200@innovationslab.net> In-Reply-To: <51B8947E.6080200@innovationslab.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: "l3vpn@ietf.org" , "yakov@juniper.net" , "ted.lemon@nominum.com" , Bharat Joshi , "erosen@cisco.com" , RFC Errata System X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 15:38:55 -0000 SGkgQnJpYW4sDQoNCjIwMTMtMDYtMTIsIEJyaWFuIEhhYmVybWFuOg0KPj4gVGhhbmtzIGZvciB5 b3VyIHJlcGx5Lg0KPj4NCj4+IFdoaWxlIHJlYWRpbmcsIEkgZmVsdCB0aGF0IGFkZGluZyBhICd0 bycgaGVyZSBtYWtlIHRoaW5ncyBtb3JlIGNsZWFyZXIuDQo+DQo+IEl0IGRvZXMgbWFrZSB0aGlu Z3MgY2xlYXJlciwgYnV0IHRoZSBvcmlnaW5hbCB3b3JkaW5nIGlzIGNvcnJlY3QuDQo+DQo+Pg0K Pj4gQXMgeW91IG1lbnRpb25lZCB0aGF0IHRoZSBleGlzdGluZyBvbmUgaXMgY29ycmVjdCwgc28g aXRzIG9rLg0KPj4NCj4NCj4gSSBiZWxpZXZlIHRoYXQgaG9sZHMgZm9yIGFsbCB0aHJlZSBlcnJh dGEgb3BlbmVkIG9uIHRoaXMgZG9jdW1lbnQuDQo+IFVubGVzcyBzb21lb25lIG9iamVjdHMsIEkg d2lsbCBtYXJrIGFsbCB0aHJlZSAoMzY0NywgMzY0OCwgJiAzNjQ5KSBhcw0KPiAiUmVqZWN0ZWQi Lg0KDQozNjQ5IGlzIGFjdHVhbGx5IGNvcnJlY3RpbmcgYSByZWFsIHR5cG8uDQoNCi1UaG9tYXMN CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBu ZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From touch@isi.edu Wed Jun 12 09:57:17 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745AC21F9B07 for ; Wed, 12 Jun 2013 09:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.004 X-Spam-Level: X-Spam-Status: No, score=-103.004 tagged_above=-999 required=5 tests=[AWL=-0.405, 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 jn5DnLbV7KFe for ; Wed, 12 Jun 2013 09:57:11 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A9A9421F9AF7 for ; Wed, 12 Jun 2013 09:57:11 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CGufGi010767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 09:56:44 -0700 (PDT) Message-ID: <51B8A83B.4030808@isi.edu> Date: Wed, 12 Jun 2013 09:56:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Brian Haberman Subject: Re: [Editorial Errata Reported] RFC4364 (3647) References: <20130612085658.39DF062114@rfc-editor.org>, <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> <35347FBF2796F94E936EE76C0E6047ED32E66F8D@BLRKECMBX13.ad.infosys.com> <51B8947E.6080200@innovationslab.net> In-Reply-To: <51B8947E.6080200@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "l3vpn@ietf.org" , "yakov@juniper.net" , "ted.lemon@nominum.com" , Bharat Joshi , "erosen@cisco.com" , "thomas.morin@orange.com" , RFC Errata System X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 16:57:17 -0000 On 6/12/2013 8:32 AM, Brian Haberman wrote: > Hi Bharat, > > On 6/12/13 11:06 AM, Bharat Joshi wrote: >> Thanks for your reply. >> >> While reading, I felt that adding a 'to' here make things more clearer. > > It does make things clearer, but the original wording is correct. FWIW, I disagree. Original: If it is desired to have a particular host be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with. "to have it be X" != "to have it to be X" The latter could be misinterpreted as: to have it become in a state of X The former means: to have it in a state of X However, the original form is something we should avoid in the future (though I doubt it's worth rewriting). It would have been preferable to say: If a host is a member of multiple virtual sites, then that host must determine which site corresponds to each packet transmitted or received. Joe From touch@isi.edu Wed Jun 12 09:59:38 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F8511E80D5 for ; Wed, 12 Jun 2013 09:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.385, 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 fAofBlWSQPvG for ; Wed, 12 Jun 2013 09:59:33 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6C88221F915B for ; Wed, 12 Jun 2013 09:59:33 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r5CGx4Jg011308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jun 2013 09:59:04 -0700 (PDT) Message-ID: <51B8A8CA.4050302@isi.edu> Date: Wed, 12 Jun 2013 09:58:50 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: RFC Errata System Subject: Re: [Editorial Errata Reported] RFC4364 (3648) References: <20130612085810.70A8E62114@rfc-editor.org> In-Reply-To: <20130612085810.70A8E62114@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: brian@innovationslab.net, l3vpn@ietf.org, yakov@juniper.net, ted.lemon@nominum.com, bharat_joshi@infosys.com, erosen@cisco.com, thomas.morin@orange.com X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 16:59:38 -0000 FWIW, this should be rejected. The original text is correct and more than sufficient. Bharat - you might want to check these with others in advance of issuing them as errata. Joe On 6/12/2013 1:58 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC4364, > "BGP/MPLS IP Virtual Private Networks (VPNs)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4364&eid=3648 > > -------------------------------------- > Type: Editorial > Reported by: Bharat Joshi > > Section: 4 > > Original Text > ------------- > If two routes to the same IP address prefix are actually routes to different systems, it is important to ensure that BGP not treat them as comparable. > > > Corrected Text > -------------- > If two routes to the same IP address prefix are actually routes to two different systems, it is important to ensure that BGP not treat them as comparable. > > Notes > ----- > 'routes to different system' should be 'routes to two different system' > > 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. > > -------------------------------------- > RFC4364 (draft-ietf-l3vpn-rfc2547bis-03) > -------------------------------------- > Title : BGP/MPLS IP Virtual Private Networks (VPNs) > Publication Date : February 2006 > Author(s) : E. Rosen, Y. Rekhter > Category : PROPOSED STANDARD > Source : Layer 3 Virtual Private Networks INT > Area : Internet > Stream : IETF > Verifying Party : IESG > From Ted.Lemon@nominum.com Wed Jun 12 10:31:44 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330E321F8EEA for ; Wed, 12 Jun 2013 10:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.61 X-Spam-Level: X-Spam-Status: No, score=-106.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 3b0dMxtinE55 for ; Wed, 12 Jun 2013 10:31:37 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 01F4621F94D3 for ; Wed, 12 Jun 2013 10:31:35 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUbiwdyHjFgsTar3mjjz2zjHfbUQNjgjF@postini.com; Wed, 12 Jun 2013 10:31:36 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 689A31B81E3 for ; Wed, 12 Jun 2013 10:31:35 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 4738B19005D; Wed, 12 Jun 2013 10:31:35 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 10:31:35 -0700 From: Ted Lemon To: Bharat Joshi Subject: Re: [Editorial Errata Reported] RFC4364 (3648) Thread-Topic: [Editorial Errata Reported] RFC4364 (3648) Thread-Index: AQHOZ0s6PTgW0abpP0OepYl53eTM6JkywvsAgAAEBgCAAAUfAA== Date: Wed, 12 Jun 2013 17:31:34 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751D382A@mbx-01.win.nominum.com> References: <20130612085810.70A8E62114@rfc-editor.org>, <51B8A8CA.4050302@isi.edu> <35347FBF2796F94E936EE76C0E6047ED32E67058@BLRKECMBX13.ad.infosys.com> In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED32E67058@BLRKECMBX13.ad.infosys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "brian@innovationslab.net" , "l3vpn@ietf.org" , Joe Touch , "yakov@juniper.net" , "erosen@cisco.com" , "thomas.morin@orange.com" , RFC Errata System X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:31:44 -0000 On Jun 12, 2013, at 1:13 PM, Bharat Joshi wrote: > I think I made a mistake by submitting them as Errata without checki= ng with others. I completely agree that I should have first send out a mail= on the mailing list to ask the wider audience about this. As a general rule, I think (this is my personal opinion, not any kind of of= ficial statement) that it's pretty useless to submit errata for typos or sp= elling errors unless the typo or spelling error changes the meaning of the = document in a way that would actually cause the reader to read something ot= her than what the author(s) intended. Someone has to look at these errata= ; before spending someone's time, it's worth asking yourself if there is so= me benefit to doing so. I think errata can be really useful, and even typ= os sometimes do change the meaning of documents, but definitely do a little= mental cost-benefit analysis before submitting one! Also, verb tenses are hard. :) From prvs=68753ead19=jakob.heitz@ericsson.com Wed Jun 12 10:45:32 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA56421E808C for ; Wed, 12 Jun 2013 10:45:31 -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 xn+N6usPLL4T for ; Wed, 12 Jun 2013 10:45:25 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5884A11E80F7 for ; Wed, 12 Jun 2013 10:45:13 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-93-51b8b3a8b051 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 40.EA.17537.8A3B8B15; Wed, 12 Jun 2013 19:45:13 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 13:45:12 -0400 From: Jakob Heitz To: Joe Touch , Brian Haberman Subject: RE: [Editorial Errata Reported] RFC4364 (3647) Thread-Topic: [Editorial Errata Reported] RFC4364 (3647) Thread-Index: AQHOZ0sO8xTieSiCH0OflOSMLCND85kyGFPBgABZBwCAAAckAIAAF4iA///KPqA= Date: Wed, 12 Jun 2013 17:45:12 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E23F2C5@eusaamb109.ericsson.se> References: <20130612085658.39DF062114@rfc-editor.org>, <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> <35347FBF2796F94E936EE76C0E6047ED32E66F8D@BLRKECMBX13.ad.infosys.com> <51B8947E.6080200@innovationslab.net> <51B8A83B.4030808@isi.edu> In-Reply-To: <51B8A83B.4030808@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyuXRPlO7KzTsCDd7P4LP4cfo5u8XMnn+M FuvuTmKxODvf36Jp/1c2i63dsRYb9h1ls1j3Zy6LxfEf39gdOD2m/N7I6rFkyU8mjwWT2tg9 Zh7/wuKx+/1WFo/rTVfZPV4fmM/q0fLsJJtHQ9sx1gDOKG6bpMSSsuDM9Dx9uwTujC6g7oKH nBXfp65kbWA8xt7FyMEhIWAica/Vv4uRE8gUk7hwbz1bFyMXh5DAUUaJfctnskM4yxklZn1a zQRSxSagI/HtehcziC0i4CGx7MZbVpAiZoG9TBI73nxjBpkqLGAucf+VD0SNhUTTnvvsELaf xPzlO1hBbBYBVYn7L/aBxXkFvCV+vT3JArHsB6PE812bWUASnALqEv/OnQQrYgQ67/upNWBH MAuIS9x6Mp8J4mwBiSV7zjND2KISLx//Y4WwlSWWPNnPAlGvI7Fg9yc2CFtbYtnC18wQiwUl Ts58wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYwcpcWpZbnpRgabGIERe0yCTXcH456XlocYpTlY lMR5I1R3BAoJpCeWpGanphakFsUXleakFh9iZOLgBBFcUg2MMrcKNeZ4Xc06ezLFR2LjgXb5 63Gvvy69uLBZ5FKxpnpqzc5XThXvWu7ZnpxoJhdSxu7NrxGkFTg1PEmP4eqd2lVb37MK3rpq x/9hsfuMOWmLui17PoY3y59a0NL2Iu7L9mOnvsiaJ/dcZlHnWaR64HRe79QeBk23W90+x/cs YBC1N3SIuG6uxFKckWioxVxUnAgAl7Y/sasCAAA= Cc: "l3vpn@ietf.org" , "yakov@juniper.net" , "ted.lemon@nominum.com" , Bharat Joshi , "erosen@cisco.com" , "thomas.morin@orange.com" , RFC Errata System X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:45:32 -0000 On , Joe Touch <> wrote: > On 6/12/2013 8:32 AM, Brian Haberman wrote: >> Hi Bharat, >>=20 >> On 6/12/13 11:06 AM, Bharat Joshi wrote: >>> Thanks for your reply. >>>=20 >>> While reading, I felt that adding a 'to' here make things more >>> clearer.=20 >>=20 >> It does make things clearer, but the original wording is correct. >=20 > FWIW, I disagree. >=20 > Original: >=20 > If it is desired to have a particular host be in multiple > virtual sites, > then that host must determine, for each packet, which virtual > site the > packet is associated with. >=20 > "to have it be X" !=3D "to have it to be X" >=20 > The latter could be misinterpreted as: >=20 > to have it become in a state of X >=20 > The former means: >=20 > to have it in a state of X >=20 >=20 > However, the original form is something we should avoid in the future > (though I doubt it's worth rewriting). >=20 > It would have been preferable to say: >=20 > If a host is a member of multiple virtual sites, then > that host must determine which site corresponds to > each packet transmitted or received. >=20 > Joe The subjunctive is explained well in http://en.wikipedia.org/wiki/Subjuncti= ve_mood --=20 Jakob Heitz.=20 From prvs=68753ead19=jakob.heitz@ericsson.com Wed Jun 12 10:49:14 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BE811E80F7 for ; Wed, 12 Jun 2013 10:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8pRmda2+Kyzh for ; Wed, 12 Jun 2013 10:49:07 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A24C211E80E6 for ; Wed, 12 Jun 2013 10:49:05 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-b6-51b8b49029aa Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F1.2B.17537.194B8B15; Wed, 12 Jun 2013 19:49:05 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Wed, 12 Jun 2013 13:49:04 -0400 From: Jakob Heitz To: Ted Lemon , Bharat Joshi Subject: RE: [Editorial Errata Reported] RFC4364 (3648) Thread-Topic: [Editorial Errata Reported] RFC4364 (3648) Thread-Index: AQHOZ0s9xQg4TvX5HUOYHUKE5NdPDJkywvsAgAAEBgCAAAUfAP//j1Tw Date: Wed, 12 Jun 2013 17:49:03 +0000 Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E23F304@eusaamb109.ericsson.se> References: <20130612085810.70A8E62114@rfc-editor.org>, <51B8A8CA.4050302@isi.edu> <35347FBF2796F94E936EE76C0E6047ED32E67058@BLRKECMBX13.ad.infosys.com> <8D23D4052ABE7A4490E77B1A012B6307751D382A@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D382A@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyuXRPuO7ELTsCDU5fEbP4cfo5u8XMnn+M FuvuTmKxODvf36Jp/1c2i63dsRYb9h1ls1j3Zy6LxfEf39gdOD2m/N7I6rFkyU8mjwWT2tg9 Zh7/wuKx+/1WFo/rTVfZPV4fmM/q0fLsJJtHQ9sx1gDOKG6bpMSSsuDM9Dx9uwTujPXftzIW FFVM2/2RsYExuIuRk0NCwESibcZ7RghbTOLCvfVsXYxcHEICRxkl5p7dxw7hLGeU2L1iHRNI FZuAjsS3613MXYwcHCICfhILuv1BapgFNjNJtJ2exwZSIyxgLnHi2BJmEFtEwEKi4fZvNgjb TaLtwQV2EJtFQFXi6OqTYHFeAW+J7ceugs0XEnjAKHFyojiIzQk0v//9ZrAaRqDrvp9aA1bD LCAucevJfCaIqwUkluw5zwxhi0q8fPyPFcJWlljyZD8LRL2OxILdn9ggbG2JZQtfM0PsFZQ4 OfMJywRGsVlIxs5C0jILScssJC0LGFlWMXKUFqeW5aYbGWxiBEbrMQk23R2Me15aHmKU5mBR EueNUN0RKCSQnliSmp2aWpBaFF9UmpNafIiRiYMTRHBJNTAuOau85/fZw7kWhznVuz8t1WT5 uGKtqd1y6wCLRK3d5d3FZ/smuIRc39ucmrKBhUm1SMm2RiuhQ7TtyNQ2MY4fibu/Rj3lCN1W r39+auAE9z/zo1VcTBsfn2bydjx+6MOc8JCiXaISfgmMAldjn55YI2emHfHpo2iZj8NT/jld O26HTHbalaPEUpyRaKjFXFScCAAgxJOAqQIAAA== Cc: "brian@innovationslab.net" , "l3vpn@ietf.org" , Joe Touch , "yakov@juniper.net" , "erosen@cisco.com" , "thomas.morin@orange.com" , RFC Errata System X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:49:14 -0000 On , Ted Lemon <> wrote: > Also, verb tenses are hard. :) You wish that they be easy. --=20 Jakob Heitz. From erosen@cisco.com Wed Jun 12 10:53:50 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029EB11E80E0 for ; Wed, 12 Jun 2013 10:53:50 -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 932dKb3C6OyH for ; Wed, 12 Jun 2013 10:53:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3B221E809C for ; Wed, 12 Jun 2013 10:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1792; q=dns/txt; s=iport; t=1371059604; x=1372269204; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=utfZkMnX0Utc9UBiTA+Rz7FyN2kPqMERGyPVaR/OAyI=; b=e3UkFkWjgMkbDhofyhme2qD++KVtq/EEBfcLlJYdGRAHFRrS+k1DU1tN tdVHbIC9cM8Zw28Yy7j3FowZYATo86j0wqtqylwUXgIwbxNQDQSgbMR2o vy/n8eUzof9Ug+XpZ+RmHZPwxSuAaZxv+tb5pAddS1WD7vzIPIp3zZU5X o=; X-IronPort-AV: E=Sophos;i="4.87,853,1363132800"; d="scan'208";a="219025072" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 12 Jun 2013 17:53:24 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5CHrN2R007603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 17:53:24 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r5CHrMw8031341; Wed, 12 Jun 2013 13:53:22 -0400 From: Eric Rosen To: "Jeffrey (Zhaohui) Zhang" Subject: Re: Comments on draft-jain-mvpn-bgp-sitetype-attribute-00.txt In-reply-to: Your message of Thu, 30 May 2013 18:35:47 -0000. <0BF0FCC78340F147BE76A6F5762318A835F0F8DE@BY2PRD0510MB389.namprd05.prod.outlook.com> Date: Wed, 12 Jun 2013 13:53:22 -0400 Message-ID: <31340.1371059602@erosen-linux> Cc: "l3vpn@ietf.org" , "'Birajdar, Girish \(Girish\)'" , "'Rema devi, Geetha \(Geetha\)'" , erosen@cisco.com, "'Kotalwar, Jayant \(Jayant\)'" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:53:50 -0000 Jeffrey> In case of Ingress Replication, there is no core state anyway and Jeffrey> the saving is on the (C-*,C-*) S-PMSI AD and corresponding Leaf-AD Jeffrey> route In the case of Ingress Replication, the Leaf A-D routes are very useful, as they allow an egress PE to assign distinct MPLS labels for each ingress PE. This in turn allows the egress PE to apply the "discard packets from the wrong PE" procedure of RFC6513 section 9.1.1. So the draft should point out that the sender-only attribute is only useful with Ingress Replication in deployments where Single Forwarder Selection is used. Jeffrey> In case of Ingress Replication, there is no core state Section 3 of the draft talks about P-tunnels causing "unnecessary control plane states in the core", and doesn't make clear that that applies only to RSVP-TE P2MP P-tunnels. Eric> Note that if VRF2 is attached to a site with senders, the procedures Eric> in the draft will add VRF1 to the P-tunnel rooted at VRF2 even if VRF1 Eric> does not have interest in any C-flow from any of VRF2's senders. Jeffrey> That's a argument for I-PMSI vs. (C-*,C-*) S-PMSI. The context of Jeffrey> this proposal is that I-PMSI is used anyway The draft (in section 1) provides two reasons for using the sender-only attribute: o to reduce unnecessary RSVP control plane states in the network o to reduce inefficient network resource utilization. The (C-*,C-*) S-PMSI scheme does a better job of addressing these issues. By the criteria that the draft itself sets out, the solution proposed in the draft is not as good as the existing (C-*,C-*) S-PMSI solution. Perhaps the draft should just position itself as a simpler but less optimal technique that might be useful in certain deployments. From erosen@cisco.com Wed Jun 12 12:17:58 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13321F9988 for ; Wed, 12 Jun 2013 12:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.102 X-Spam-Level: X-Spam-Status: No, score=-10.102 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, FS_REPLICA=0.994, 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 OaxIslWHRr+3 for ; Wed, 12 Jun 2013 12:17:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8722021F9952 for ; Wed, 12 Jun 2013 12:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14137; q=dns/txt; s=iport; t=1371064672; x=1372274272; h=from:to:cc:subject:reply-to:date:message-id; bh=/wJ+EGIGkkqqyM0MUk3B2mILdSL3OAUtO7r1nja8YD8=; b=m6SFA8FEvnFShUab4h+lJad39gL7PpZxakPw2NLHxfVPHMv2XFjuPha8 9M1NuLhK1TkdP+Xtc/qHzEO0EtqNcKt/pzViXyjPtOWsxJ3NJ+ogIOMAe o8EGLFu9uI+Q2QDG9DfEnk1loyJ93f8/LwYzqT/H2UGaVhiTp5tFrkTyi o=; X-IronPort-AV: E=Sophos;i="4.87,854,1363132800"; d="scan'208";a="221839991" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 12 Jun 2013 19:17:52 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5CJHp2d024742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jun 2013 19:17:52 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r5CJHoTA002450; Wed, 12 Jun 2013 15:17:50 -0400 From: Eric Rosen To: "Jeffrey (Zhaohui) Zhang" Subject: Comments on draft-zzhang-l3vpn-mvpn-bidir-ingress-replication-00.txt Date: Wed, 12 Jun 2013 15:17:50 -0400 Message-ID: <2449.1371064670@erosen-linux> Cc: "l3vpn@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 19:17:58 -0000 This is an interesting and potentially useful draft. The major issue I see is that while the draft does not say that it is applicable only to non-segmented IR P-tunnels, I don't see how it will work if IR P-tunnels are segmented at ASBRs or ABRs. The draft seems to use the term "Upstream Multicast Hop" (UMH) to mean "Upstream PE", which would be okay only if non-segmented IR P-tunnels are out of scope. Comments in-line, look for ****. Abstract RFC 6513 described a method to support bidirectional C-flow using "Partial Mesh of MP2MP P-Tunnels". This document describes how partial mesh of MP2MP P-Tunnels can be simulated with Ingress Replication, instead of a real MP2MP tunnel. **** I'd add to the abstract that this enables a Service Provider to use **** Ingress Replication to offer transparent BIDIR-PIM service to its VPN **** customers. 1. Introduction Section 11.2 of RFC 6513, "Partitioned Sets of PEs", describes two methods of carrying bidirectional C-flow traffic over a provider core without using the core as RPL or requiring Designated Forwarder election. With these two methods, all PEs of a particular VPN are separated into partitions, with each partition being all the PEs that elect the same PE as the UMH wrt the C-RPA. A PE must discard bidirectional C-flow traffic from PEs that are not in the same partition as the PE itself. In particular, Section 11.2.3 of RFC 6513, "Partial Mesh of MP2MP P-Tunnels", guarantees the above discard havavior without using an extra PE Distinguisher label by having all PEs in the same partition join a single MP2MP tunnel dedicated to that partition and use it to transmit traffic. All traffic arriving on the tunnel will be from PEs in the same partition, so it will be always accepted. RFC 6514 specifies BGP encodings and procedures used to implement MVPN as specified in RFC 6513, while the details related to MP2MP tunnels are specified in [draft-ietf-l3vpn-mvpn-bidir-05]. [draft-ietf-l3vpn-mvpn-bidir-05] assumes that an MP2MP P-tunnel is realized either via PIM-Bidir, or via MP2MP mLDP. Each of them would require signaling and state not just on PEs, but on the P routers as well. This document describes how the MP2MP tunnel can be simulated with a mesh of P2P or MP2P LSPs, i.e. Ingress Replication. **** What is really being proposed is to simulate a MP2MP P-tunnel with a **** set of P2MP P-tunnels, and then to use Ingress Replication to **** instantiate each such P-tunnel. The trick is how to get all the PEs to **** join all the necessary P2MP P-tunnels without requiring each PE to send **** a Leaf A-D route for each MP2MP P-tunnel to each other PE. The advantage is that existing P2P/MP2P LSPs created for unicast can be used for multicast as well w/o introducing additional signaling or state in the core. While there may be concerns with traffic replication in the core, in many situations the traffic could be low- rate and/or sporadic and the advantage of signaling and state savings will outweight the concerns with traffic replication, making Ingress Replication an applicable and attractive alternative. **** It might be better simply to say that this scheme has both the **** advantages and the disadvantages of Ingress Replication in general. This documentation specifies the BGP signaling and procedures used to simulate "Partial Mesh of MP2MP P-Tunnels" with Ingress Replication. ... 3. Operation 3.1. Control State If a PE, say PEx, is connected to a site of a given VPN, and that site hosts the C-RPA for some Bidir-PIM groups, i.e., the route to the C-RPA is through a local PE-CE interface, **** I think the actual condition is that PEx's next hop interface to some **** C-RPA is a VRF interface. This is not exactly the same thing as being **** connected to a site that "hosts a C-RPA". then PEx MUST advertises a (C-*,C-BIDIR) S-PMSI A-D route, regardless of whether it has any local Bidir-PIM join states corresponding to the C-RPA learned from its CEs. It MAY also advertise a (C-*,C-G-BIDIR) S-PMSI **** "advertise a" --> "advertise one or more" A-D route, just like how any other S-PMSI A-D routes are triggered (e.g, when the (C-*,C-G-BIDIR) traffic rate goes above a threshold). **** It's worth pointing out that applying a traffic rate threshold to a **** (C-*,C-G-BIDIR) state would require measuring the traffic in both **** directions, as the sources are not necessarily local. For IR **** P-tunnels, it might also be necessary to take the fanout into account. Here the C-G-BIDIR refers to a C-G where G is a Bidir-PIM group, and the corresponding C-RPA is in the site that the PEx connects to. The S-PMSI A-D routes include a Provider Tunnel Attribute (PTA) with **** "PMSI Tunnel attribute" tunnel type set to Ingress Replication, with Leaf Information Required flag set, and with a downstream allocated MPLS label that other PEs in the same partition MUST use when sending relevant C-bidir flows to this PE. **** and with the Tunnel Identifier field in the PTA set to a routable **** address of the originator? **** Can the MPLS label be shared with any other P-tunnels? Perhaps all **** the (C-*,C-BIDIR) and (C-*,C-G-BIDIR) S-PMSI A-D routes originated by a **** given PE can (optionally) share a label? If some other PE, PEy, receives and imports into one of its VRFs such a (C-*,C-BIDIR) S-PMSI A-D route, **** I'm not sure just what is mean by "such a (C-*,C-BIDIR) S-PMSI A-D **** route". Does this mean "any (C-*,C-BIDIR) S-PMSI A-D route whose PTA **** specifies an IR P-tunnel"? and the VRF has any local Bidir-PIM join state that PEy has received from its CEs, and if PEy chooses PEx as its UMH wrt the C-RPA for those states, PEy MUST advertise a Leaf A-D route in response. Or, if PEy has received and imported into one of its VRFs a (C-*,C-BIDIR) S-PMSI A-D route from PEx before, then upon receiving in the VRF any local Bidir-PIM join state from its CEs with PEx being the UMH for those states' C-RPA, PEy MUST advertise a Leaf A-D route. The encoding of the Leaf A-D route is as specified in RFC 6514, except that the Route Targets are set to the same value as in the corresponding S-PMSI A-D route so that the Leaf A-D route will be imported by all VRFs that import the corresponding S-PMSI A-D route. **** I take the "except" clause to mean that RFC 6514's rules for setting **** the Leaf A-D route's RTs are not followed, and that the RTs are instead **** just copied from the S-PMSI A-D route. Is that the intention? **** This means that the Leaf A-D route will not have an RT that is created **** from the Next Hop or P2MP Segmented Next Hop EC, which essentially **** means that all the P-tunnels will be non-segmented. Is that the **** intention? **** RFC 6514 says that a PE/ASBR should take no action with regard to a **** Leaf A-D route unless that Leaf A-D route carries an IP Address **** Specific RT identifying the PE/ASBR. This draft should make it very **** clear that it is changing the RFC6514 procedures for the case where the **** route key of a Leaf A-D route identifies a (C-*,C-BIDIR) or a **** (C-*,C-G-BIDIR) S-PMSI. **** It's not clear to me how these procedures would coexist with the **** segmentation procedures that ordinarily occur at ABRs or ASBRs. Are **** ABRs/ASBRs supposed to modify the next hop and/or segmented next hop **** extended communities of the S-PMSI A-D routes that are about BIDIR **** groups? If not, but if segmentation is to be applied to S-PMSI A-D **** routes that are not about BIDIR groups, how will the ABRs/ASBRS know **** which are which? I.e., how exactly do the procedures of this draft **** coexist with the ABR/ASBR segmentation procedures that apply to **** non-BIDIR S-PMSIs? **** Note that there is up to now no requirement that an S-PMSI A-D route **** originated from a particular VRF carry any of that VRF's import RTs. I **** think that requirement needs to be added to this draft; otherwise the **** Leaf A-D routes originated in response to an S-PMSI A-D route won't **** necessarily be imported into the originating VRF of the S-PMSI A-D **** route. Alternatively, one could require that the Leaf A-D route carry **** an IP Address Specific RT identifying the S-PMSI route's originator (as **** learned from the NLRI) in its Global Administrator field. This is irrespective of whether from a receiving PE, PEz's perspective PEx (oiginator of the S-PMSI A-D route) is the UMH PE or **** Is "PEz" supposed to be "PEy"? **** It would be better to say "Upstream PE" than "UMH" or "UMH PE", as the **** UMH could presumably be an ABR or ASBR. not. The label in the PTA of the Leaf A-D route originated by PEy MUST be allocated specifically for PEx, so that when traffic arrives with that label, the traffic can associated with the partition (represented by the PEx). **** This doesn't make it clear whether the label can be shared with other **** S-PMSIs (e.g., P2MP S-PMSIs) that originate from PEx. I think the **** answer is yes, at least in non-extranet cases. **** I think the draft should specify that the originator (the upstream PE) **** is identified from the "originating router's IP address" field of the **** NLRI of the S-PMSI A-D route. With PEy advertising Leaf A-D route only if it chooses the originator of the S-PMSI A-D route as its UMH, it won't receive traffic from PEs **** "UMH" vs. "Upstream PE" again. in other partitions, so the label is actually useful only when PEy switches to a different UMH - it will stop accepting traffic before sending PEs stop sending it traffic (upon the receipt of its Leaf A-D route withdrawl). **** I don't see why it is said that "PEy ... won't receive traffic from PEs **** in other partitions". PE1, for example, may choose PE2 as the Upstream **** PE for (C-*,C-G1-BIDIR) while choosing PE3 as the Upstream PE for **** (C-*,C-G2-BIDIR). PE4 may make the opposite choices. In that case PE1 **** and PE4 may both originate Leaf A-D routes with NLRI **** and . As a result, PE2 and PE3 would get the **** (C-*,C-G1-BIDIR) and (C-*,C-G2-BIDIR) flows from both partitions, and **** they would need to use the label to determine which copy of each C-flow **** to drop. To speed up convergency (so that PEy starts receiving traffic from its new UMH immediately instead of waiting until the new Leaf A-D route corresponding to the new UMH is received by sending PEs), PEy MAY advertise a Leaf A-D route even if does not choose PEx as its UMH wrt the C-RPA. With that, it will receive traffic from all PEs, but some will arrive with the label corresponding to its choice of UMH while some will arrive with a different label, and the traffic in the latter case will be discarded. **** This might be useful as a form of live-live redundancy, but I don't **** think it is a very efficient way to speed up convergence when a **** receiving PE decides to switch the partition over which it receives a **** particular C-flow. When the receiving PE originates the Leaf A-D route **** for the new partition, it just has to keep forwarding the C-flow **** received from the old partition for a certain period of time, while **** discarding that C-flow when received from the new partition; when that **** period of time is up, can start discarding the C-flow when received **** from the old partition and start forwarding it when received from the **** new. (A larger delay should be imposed on transmitters, so they **** continue transmitting to a particular receiver for a period of time **** after that receiver withdraws its Leaf A-D route.) This would provide **** a more efficient "make before break" type of procedure. Similar to the (C-*,C-BIDIR) case, if PEy receives and imports into one of its VRFs such a (C-*,C-G-BIDIR) S-PMSI A-D route, and PEy chooses PEx as its UMH wrt the C-RPA, and it has corresponding local (C-*,C-G-BIDIR) join state that it has received from its CEs in the VRF, PEy MUST advertise a Leaf A-D route in response. Or, if PEy has received and imported into one of its VRFs a (C-*,C-G-BIDIR) S-PMSI A-D route before, then upon receiving its local (C-*,C-G-BIDIR) join state from its CEs in the VRF, it MUST advertise a Leaf A-D route. The encoding of the Leaf A-D route is as specified in RFC 6514, except that the Route Targets are set to the same as in the corresponding S-PMSI A-D route so that the Leaf A-D route will be imported by all VRFs that import the corresponding S-PMSI A-D route. **** See prior comment re RTs. This is irrespective of whether from the receiving PE, PEz's **** PEz? Is that supposed to be PEy? perspective PEx (oiginator of the S-PMSI A-D route) is the UMH PE or not. The label in the PTA of the Leaf A-D route originated by PEy MUST be allocated specifically for PEx, so that when traffic arrives with that label, the traffic can associated with the partition (represented by the PEx). **** See prior comment on label granularity. Whenever the (C-*,C-BIDIR) or (C-*,C-G-BIDIR) S-PMSI A-D route is withdrawn, or if PEy no longer chooses the originator PEx as its UMH wrt C-RPA and PEy only advertises Leaf A-D routes in response to its UMH's S-PMSI A-D route, or if relevant local join state is pruned, PEy MUST withdraw the corresponding Leaf A-D route. **** I think this "MUST" is too strong, and in fact it contradicts what is **** said above "PEy MAY advertise a Leaf A-D route even if does not **** choose PEx as its UMH wrt the C-RPA". From Alexander.Vainshtein@ecitele.com Wed Jun 12 22:08:34 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EABA21F999A for ; Wed, 12 Jun 2013 22:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.371 X-Spam-Level: X-Spam-Status: No, score=0.371 tagged_above=-999 required=5 tests=[AWL=1.573, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5Pk5baTLav7 for ; Wed, 12 Jun 2013 22:08:27 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) by ietfa.amsl.com (Postfix) with ESMTP id 2376B21F9997 for ; Wed, 12 Jun 2013 22:08:25 -0700 (PDT) Received: from [85.158.139.211:40994] by server-1.bemta-5.messagelabs.com id FB/A4-01720-8C359B15; Thu, 13 Jun 2013 05:08:24 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1371100099!18499727!2 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24511 invoked from network); 13 Jun 2013 05:08:23 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Jun 2013 05:08:23 -0000 X-AuditID: 93eaf2e7-b7fe56d000003680-82-51b953c7b033 Received: from ILPTWPVEXCA02.ecitele.com ( [172.31.244.232]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id AF.53.13952.7C359B15; Thu, 13 Jun 2013 08:08:23 +0300 (IDT) Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Thu, 13 Jun 2013 08:08:22 +0300 From: Alexander Vainshtein To: Ted Lemon Subject: RE: [Editorial Errata Reported] RFC4364 (3648) Thread-Topic: [Editorial Errata Reported] RFC4364 (3648) Thread-Index: AQHOZ0s9buBkqLgw60++92dTxZZh6pkywvsAgAAEBgCAAAUfAIAASuWM Date: Thu, 13 Jun 2013 05:08:21 +0000 Message-ID: References: <20130612085810.70A8E62114@rfc-editor.org>, <51B8A8CA.4050302@isi.edu> <35347FBF2796F94E936EE76C0E6047ED32E67058@BLRKECMBX13.ad.infosys.com>, <8D23D4052ABE7A4490E77B1A012B6307751D382A@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751D382A@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKKsWRmVeSWpSXmKPExsUy+dWnL7rHg3cGGlxeI2bx4/RzdouZPf8Y Lc7O97fY2h1rsWHfUTYHVo8lS34yeSyY1MbuMfP4FxaP1wfms3q0PDvJFsAa1cBok5iXl1+S WJKqkJJanGyrFFCUWZaYXKmkkJliq2SopFCQk5icmpuaV2KrlFhQkJqXomTHpYABbIDKMvMU UvOS81My89JtlTyD/XUtLEwtdQ2V7NSUDY2tuUIyMosVUnVzEzNzFHJTi4sT01MVgCIJW5gz 3t5oZSnYzV/xYPMetgbG4zxdjJwcEgImEo+XdDFC2GISF+6tZ+ti5OIQEjjIKDH5z0xmCOco o8TBlRtZQarYBGwlNq2+ywZiiwioSvw4+YkFpIhZYAqzxJnny5lAEsIC5hInji1hhiiykGi4 /RuogQPIdpP4118JEmYB6t156SYjSJhXIEBi8uoIiF33GCVOPX3NDlLDKeAn0f9+M9guRqDr vp9aAzaeWUBc4taT+UwQVwtILNlznhnCFpV4+fgfK4QtL7F562NWiHodiQW7P7FB2NoSyxa+ BqvnFRCUODnzCQtEvaTEwRU3WCYwis9CsmIWkvZZSNpnIWlfwMiyilE0M6egJCk33cBQLzU5 syQ1J1UvOT93EyMkAT3fwfhrvsohRlegvycyS3En5wMTWF5JvLGBAW6Okjjv8oZwfyGBdGDC yU5NLUgtii8qzUktPsTIxMEp1cAY3nv/1Zd7krvj6lPXbNWp36S6hmvPwiVcohadLZuMjt20 urpFQ39q7E+xE2vUdd7/iDf4oZOtNf/w+6/Xp8ZOSpecE9Lud8uC5U34MZcfWvZ8qgv3tlzq /qKwUWhm2rdDH9atLl1yVDj7UqzF3VYugRNmbk6HAtew/n/Ae+582CfRjrlpPesilFiKMxIN tZiLihMBMCawTDgDAAA= Cc: "brian@innovationslab.net" , "Yaakov Stein \(yaakov_s@rad.com\)" , "l3vpn@ietf.org" , Joe Touch , "yakov@juniper.net" , Bharat Joshi , "erosen@cisco.com" , "thomas.morin@orange.com" , RFC Errata System X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 05:08:34 -0000 Ted, and all, I tend to agree with your statement that errata on typos should be rejected= unless the typo changes the meaning of the document. I remember an erratum filed on RFC where FEC has been erroneously exploded (= presumably by the RFC Editor) as "Forward Error Correction" instead of "Forw= arding Equivalence Class". The general feeling has been that an reader with minimal basic background kn= owledge required for understanding the document would not run to learn about= Reed-Solomon codes based on this error. My 2c, Sasha ________________________________________ From: l3vpn-bounces@ietf.org [l3vpn-bounces@ietf.org] on behalf of Ted Lemon= [Ted.Lemon@nominum.com] Sent: Wednesday, June 12, 2013 7:31 PM To: Bharat Joshi Cc: brian@innovationslab.net; l3vpn@ietf.org; Joe Touch; yakov@juniper.net;= erosen@cisco.com; thomas.morin@orange.com; RFC Errata System Subject: Re: [Editorial Errata Reported] RFC4364 (3648) On Jun 12, 2013, at 1:13 PM, Bharat Joshi wrote: > I think I made a mistake by submitting them as Errata without checkin= g with others. I completely agree that I should have first send out a mail o= n the mailing list to ask the wider audience about this. As a general rule, I think (this is my personal opinion, not any kind of off= icial statement) that it's pretty useless to submit errata for typos or spel= ling errors unless the typo or spelling error changes the meaning of the doc= ument in a way that would actually cause the reader to read something other= than what the author(s) intended. Someone has to look at these errata; be= fore spending someone's time, it's worth asking yourself if there is some be= nefit to doing so. I think errata can be really useful, and even typos som= etimes do change the meaning of documents, but definitely do a little mental= cost-benefit analysis before submitting one! Also, verb tenses are hard. :) This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From bharat_joshi@infosys.com Wed Jun 12 08:43:39 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482DE21E8087 for ; Wed, 12 Jun 2013 08:43:39 -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 NtWinH7B9XSD for ; Wed, 12 Jun 2013 08:43:34 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6393021E805F for ; Wed, 12 Jun 2013 08:43:33 -0700 (PDT) X-TM-IMSS-Message-ID: <4eff522a00004250@infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 4eff522a00004250 ; Wed, 12 Jun 2013 21:20:24 +0530 Received: from BLRKECHUB08.ad.infosys.com (10.66.236.138) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Jun 2013 21:12:56 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB08.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 21:12:56 +0530 From: Bharat Joshi To: Brian Haberman Subject: RE: [Editorial Errata Reported] RFC4364 (3647) Thread-Topic: [Editorial Errata Reported] RFC4364 (3647) Thread-Index: AQHOZ0sGttydbyf7J0yB1Ona9nBXFZkxvB+AgABxWQn//6vFAIAAXbtc Date: Wed, 12 Jun 2013 15:42:55 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E66FBD@BLRKECMBX13.ad.infosys.com> References: <20130612085658.39DF062114@rfc-editor.org>, <72797F37-92E8-4320-BEB1-9D9EC5A3621D@ericsson.com> <35347FBF2796F94E936EE76C0E6047ED32E66F8D@BLRKECMBX13.ad.infosys.com>, <51B8947E.6080200@innovationslab.net> In-Reply-To: <51B8947E.6080200@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.37.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 13 Jun 2013 00:44:49 -0700 Cc: "l3vpn@ietf.org" , "yakov@juniper.net" , "ted.lemon@nominum.com" , "erosen@cisco.com" , "thomas.morin@orange.com" , RFC Errata System X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 15:43:39 -0000 Hi Brain, >> Thanks for your reply. >> >> While reading, I felt that adding a 'to' here make things more clearer= . > >It does make things clearer, but the original wording is correct. > >> >> As you mentioned that the existing one is correct, so its ok. >> > >I believe that holds for all three errata opened on this document. >Unless someone objects, I will mark all three (3647, 3648, & 3649) as >"Rejected". I think Errata 3647 and 3648 are making things more readable so if you th= ink that the current text is ok then may be you can reject them. Errata 3= 649 is more of a typo which I think should be fixed. Regards, Bharat **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From bharat_joshi@infosys.com Wed Jun 12 10:14:31 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E740B21F96F5 for ; Wed, 12 Jun 2013 10:14:30 -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 iRd0+kPdP2IX for ; Wed, 12 Jun 2013 10:14:26 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id DB83221F8233 for ; Wed, 12 Jun 2013 10:14:04 -0700 (PDT) X-TM-IMSS-Message-ID: <4f87006b000d019b@infosys.com> Received: from BLRKECHUB05.ad.infosys.com ([10.66.236.45]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 4f87006b000d019b ; Wed, 12 Jun 2013 22:42:20 +0530 Received: from BLRKECHUB10.ad.infosys.com (10.66.236.120) by BLRKECHUB05.ad.infosys.com (10.66.236.45) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Jun 2013 22:43:16 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by blrkechub10.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Wed, 12 Jun 2013 22:43:15 +0530 From: Bharat Joshi To: Joe Touch , RFC Errata System Subject: RE: [Editorial Errata Reported] RFC4364 (3648) Thread-Topic: [Editorial Errata Reported] RFC4364 (3648) Thread-Index: AQHOZ0s5e2OhhzWal0O4Y5Qkj2J/qJkx8W4AgABfugc= Date: Wed, 12 Jun 2013 17:13:14 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E67058@BLRKECMBX13.ad.infosys.com> References: <20130612085810.70A8E62114@rfc-editor.org>, <51B8A8CA.4050302@isi.edu> In-Reply-To: <51B8A8CA.4050302@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.37.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 13 Jun 2013 00:44:49 -0700 Cc: "brian@innovationslab.net" , "l3vpn@ietf.org" , "yakov@juniper.net" , "ted.lemon@nominum.com" , "erosen@cisco.com" , "thomas.morin@orange.com" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:14:31 -0000 Joe, I think I made a mistake by submitting them as Errata without check= ing with others. I completely agree that I should have first send out a m= ail on the mailing list to ask the wider audience about this. I will surely not skip this step in future. Thanks for your kind reply. Regards, Bharat ________________________________________ From: Joe Touch [touch@isi.edu] Sent: Wednesday, June 12, 2013 10:28 PM To: RFC Errata System Cc: erosen@cisco.com; yakov@juniper.net; brian@innovationslab.net; ted.le= mon@nominum.com; martin.vigoureux@alcatel-lucent.com; thomas.morin@orange= .com; l3vpn@ietf.org; Bharat Joshi Subject: Re: [Editorial Errata Reported] RFC4364 (3648) FWIW, this should be rejected. The original text is correct and more than sufficient. Bharat - you might want to check these with others in advance of issuing them as errata. Joe On 6/12/2013 1:58 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC4364, > "BGP/MPLS IP Virtual Private Networks (VPNs)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4364&eid=3D3648 > > -------------------------------------- > Type: Editorial > Reported by: Bharat Joshi > > Section: 4 > > Original Text > ------------- > If two routes to the same IP address prefix are actually routes to diff= erent systems, it is important to ensure that BGP not treat them as compa= rable. > > > Corrected Text > -------------- > If two routes to the same IP address prefix are actually routes to two = different systems, it is important to ensure that BGP not treat them as c= omparable. > > Notes > ----- > 'routes to different system' should be 'routes to two different system' > > 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. > > -------------------------------------- > RFC4364 (draft-ietf-l3vpn-rfc2547bis-03) > -------------------------------------- > Title : BGP/MPLS IP Virtual Private Networks (VPNs) > Publication Date : February 2006 > Author(s) : E. Rosen, Y. Rekhter > Category : PROPOSED STANDARD > Source : Layer 3 Virtual Private Networks INT > Area : Internet > Stream : IETF > Verifying Party : IESG > **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended sol= ely for the use of the addressee(s). If you are not the intended recipient, p= lease notify the sender by e-mail and delete the original message. Further, you= are not to copy, disclose, or distribute this e-mail or its contents to any other= person and any such actions are unlawful. This e-mail may contain viruses. Infosys h= as taken every reasonable precaution to minimize this risk, but is not liable for = any damage you may sustain as a result of any virus in this e-mail. You should carry= out your own virus checks before opening the e-mail or attachment. Infosys reserve= s the right to monitor and review the content of all messages sent to or from t= his e-mail address. Messages sent to or from this e-mail address may be stored on th= e Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From wwwrun@rfc-editor.org Mon Jun 17 07:18:03 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D842621F9C23 for ; Mon, 17 Jun 2013 07:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 we1WSxJR7A5M for ; Mon, 17 Jun 2013 07:18:03 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0E56621F9AAA for ; Mon, 17 Jun 2013 07:18:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CDB7162113; Mon, 17 Jun 2013 07:15:56 -0700 (PDT) To: erosen@cisco.com, raggarwa_1@yahoo.com, stbryant@cisco.com, adrian@olddog.co.uk, martin.vigoureux@alcatel-lucent.com, thomas.morin@orange.com Subject: [Editorial Errata Reported] RFC6513 (3658) From: RFC Errata System Message-Id: <20130617141556.CDB7162113@rfc-editor.org> Date: Mon, 17 Jun 2013 07:15:56 -0700 (PDT) Cc: joelrepiquet@gmail.com, l3vpn@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 14:18:04 -0000 The following errata report has been submitted for RFC6513, "Multicast in MPLS/BGP IP VPNs". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6513&eid=3658 -------------------------------------- Type: Editorial Reported by: Joël Repiquet Section: 5.3.1 Original Text ------------- Whenever a C-multicast route is sent, it must also carry the Selected Upstream Multicast Hop corresponding to the C-root address (determined by the procedures of Section 5.1). The Selected Upstream Multicast Hop must be encoded as part of a Route Target Extended Community to facilitate the optional use of filters that can prevent the distribution of the update to BGP speakers other than the Upstream Multicast Hop. See Section 10.1.3 of [MVPN-BGP] for the details. Corrected Text -------------- Whenever a C-multicast route is sent, it must also carry the Selected Upstream Multicast Hop corresponding to the C-root address (determined by the procedures of Section 5.1). The Selected Upstream Multicast Hop must be encoded as part of a Route Target Extended Community to facilitate the optional use of filters that can prevent the distribution of the update to BGP speakers other than the Upstream Multicast Hop. See Section 11.1.3 of [MVPN-BGP] for the details. Notes ----- 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. -------------------------------------- RFC6513 (draft-ietf-l3vpn-2547bis-mcast-10) -------------------------------------- Title : Multicast in MPLS/BGP IP VPNs Publication Date : February 2012 Author(s) : E. Rosen, Ed., R. Aggarwal, Ed. Category : PROPOSED STANDARD Source : Layer 3 Virtual Private Networks Area : Routing Stream : IETF Verifying Party : IESG From thomas.morin@orange.com Mon Jun 17 08:09:33 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DD921F9D20 for ; Mon, 17 Jun 2013 08:09:33 -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, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQTK7YCffL6w for ; Mon, 17 Jun 2013 08:09:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7721F9D3B for ; Mon, 17 Jun 2013 08:09:20 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 1516922D0A6; Mon, 17 Jun 2013 17:09:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D2BF027C053; Mon, 17 Jun 2013 17:09:18 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 17 Jun 2013 17:09:18 +0200 From: To: RFC Errata System Subject: Re: [Editorial Errata Reported] RFC6513 (3658) Thread-Topic: [Editorial Errata Reported] RFC6513 (3658) Thread-Index: AQHOa2V7GiZEYDfT1UuAbTvPowTWwJk54PIA Date: Mon, 17 Jun 2013 15:09:18 +0000 Message-ID: <30214_1371481759_51BF269E_30214_2659_6_AC1ADC68A92CF94FA8CFCB406C1CBE3D07474C57@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20130617141556.CDB7162113@rfc-editor.org> In-Reply-To: <20130617141556.CDB7162113@rfc-editor.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.17.142422 Cc: "l3vpn@ietf.org" , "joelrepiquet@gmail.com" , "adrian@olddog.co.uk" , "raggarwa_1@yahoo.com" , "erosen@cisco.com" , "stbryant@cisco.com" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 15:09:33 -0000 VGhlIGVycmF0YSByZWxhdGVzIHRvIGEgd3JvbmcgcmVmZXJlbmNlIChSRkM2NTEzIHJlZmVycmlu ZyB0byANCm5vbi1leGlzdGluZyBzZWN0aW9uIDEwLjEuMyBvZiBSRkM2NTE0IGluc3RlYWQgb2Yg c2VjdGlvbiAxMS4xLjMpLg0KDQpBbHRob3VnaCB0aGUgZXJyb3Igc2VlbXMgbW9zdGx5IGhhcm1s ZXNzLCB0aGUgZXJyYXRhIGlzIHN0cmljdGx5IA0Kc3BlYWtpbmcgdmFsaWQuDQoNCi1UaG9tYXMN Cg0KMjAxMy0wNi0xNywgUkZDIEVycmF0YSBTeXN0ZW06DQo+IFRoZSBmb2xsb3dpbmcgZXJyYXRh IHJlcG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzY1MTMsDQo+ICJNdWx0aWNhc3QgaW4g TVBMUy9CR1AgSVAgVlBOcyIuDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0Og0KPiBodHRw Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFyY2gucGhwP3JmYz02NTEzJmVpZD0zNjU4 DQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFR5cGU6IEVk aXRvcmlhbA0KPiBSZXBvcnRlZCBieTogSm/vv71sIFJlcGlxdWV0IDxqb2VscmVwaXF1ZXRAZ21h aWwuY29tPg0KPg0KPiBTZWN0aW9uOiA1LjMuMQ0KPg0KPiBPcmlnaW5hbCBUZXh0DQo+IC0tLS0t LS0tLS0tLS0NCj4gICAgIFdoZW5ldmVyIGEgQy1tdWx0aWNhc3Qgcm91dGUgaXMgc2VudCwgaXQg bXVzdCBhbHNvIGNhcnJ5IHRoZSBTZWxlY3RlZA0KPiAgICAgVXBzdHJlYW0gTXVsdGljYXN0IEhv cCBjb3JyZXNwb25kaW5nIHRvIHRoZSBDLXJvb3QgYWRkcmVzcw0KPiAgICAgKGRldGVybWluZWQg YnkgdGhlIHByb2NlZHVyZXMgb2YgU2VjdGlvbiA1LjEpLiAgVGhlIFNlbGVjdGVkIFVwc3RyZWFt DQo+ICAgICBNdWx0aWNhc3QgSG9wIG11c3QgYmUgZW5jb2RlZCBhcyBwYXJ0IG9mIGEgUm91dGUg VGFyZ2V0IEV4dGVuZGVkDQo+ICAgICBDb21tdW5pdHkgdG8gZmFjaWxpdGF0ZSB0aGUgb3B0aW9u YWwgdXNlIG9mIGZpbHRlcnMgdGhhdCBjYW4gcHJldmVudA0KPiAgICAgdGhlIGRpc3RyaWJ1dGlv biBvZiB0aGUgdXBkYXRlIHRvIEJHUCBzcGVha2VycyBvdGhlciB0aGFuIHRoZQ0KPiAgICAgVXBz dHJlYW0gTXVsdGljYXN0IEhvcC4gIFNlZSBTZWN0aW9uIDEwLjEuMyBvZiBbTVZQTi1CR1BdIGZv ciB0aGUNCj4gICAgIGRldGFpbHMuDQo+DQo+IENvcnJlY3RlZCBUZXh0DQo+IC0tLS0tLS0tLS0t LS0tDQo+ICAgICBXaGVuZXZlciBhIEMtbXVsdGljYXN0IHJvdXRlIGlzIHNlbnQsIGl0IG11c3Qg YWxzbyBjYXJyeSB0aGUgU2VsZWN0ZWQNCj4gICAgIFVwc3RyZWFtIE11bHRpY2FzdCBIb3AgY29y cmVzcG9uZGluZyB0byB0aGUgQy1yb290IGFkZHJlc3MNCj4gICAgIChkZXRlcm1pbmVkIGJ5IHRo ZSBwcm9jZWR1cmVzIG9mIFNlY3Rpb24gNS4xKS4gIFRoZSBTZWxlY3RlZCBVcHN0cmVhbQ0KPiAg ICAgTXVsdGljYXN0IEhvcCBtdXN0IGJlIGVuY29kZWQgYXMgcGFydCBvZiBhIFJvdXRlIFRhcmdl dCBFeHRlbmRlZA0KPiAgICAgQ29tbXVuaXR5IHRvIGZhY2lsaXRhdGUgdGhlIG9wdGlvbmFsIHVz ZSBvZiBmaWx0ZXJzIHRoYXQgY2FuIHByZXZlbnQNCj4gICAgIHRoZSBkaXN0cmlidXRpb24gb2Yg dGhlIHVwZGF0ZSB0byBCR1Agc3BlYWtlcnMgb3RoZXIgdGhhbiB0aGUNCj4gICAgIFVwc3RyZWFt IE11bHRpY2FzdCBIb3AuICBTZWUgU2VjdGlvbiAxMS4xLjMgb2YgW01WUE4tQkdQXSBmb3IgdGhl DQo+ICAgICBkZXRhaWxzLg0KPg0KPiBOb3Rlcw0KPiAtLS0tLQ0KPg0KPg0KPiBJbnN0cnVjdGlv bnM6DQo+IC0tLS0tLS0tLS0tLS0NCj4gVGhpcyBlcnJhdGEgaXMgY3VycmVudGx5IHBvc3RlZCBh cyAiUmVwb3J0ZWQiLiBJZiBuZWNlc3NhcnksIHBsZWFzZQ0KPiB1c2UgIlJlcGx5IEFsbCIgdG8g ZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KPiByZWplY3RlZC4gV2hl biBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkgKElFU0cpDQo+IGNh biBsb2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVj ZXNzYXJ5Lg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBS RkM2NTEzIChkcmFmdC1pZXRmLWwzdnBuLTI1NDdiaXMtbWNhc3QtMTApDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRpdGxlICAgICAgICAgICAgICAgOiBNdWx0 aWNhc3QgaW4gTVBMUy9CR1AgSVAgVlBOcw0KPiBQdWJsaWNhdGlvbiBEYXRlICAgIDogRmVicnVh cnkgMjAxMg0KPiBBdXRob3IocykgICAgICAgICAgIDogRS4gUm9zZW4sIEVkLiwgUi4gQWdnYXJ3 YWwsIEVkLg0KPiBDYXRlZ29yeSAgICAgICAgICAgIDogUFJPUE9TRUQgU1RBTkRBUkQNCj4gU291 cmNlICAgICAgICAgICAgICA6IExheWVyIDMgVmlydHVhbCBQcml2YXRlIE5ldHdvcmtzDQo+IEFy ZWEgICAgICAgICAgICAgICAgOiBSb3V0aW5nDQo+IFN0cmVhbSAgICAgICAgICAgICAgOiBJRVRG DQo+IFZlcmlmeWluZyBQYXJ0eSAgICAgOiBJRVNHDQo+DQoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sCkZyYW5jZSBUZWxlY29tIC0gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoK VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsK dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1 dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIEZyYW5jZSBUZWxlY29tIC0gT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From xuxiaohu@huawei.com Thu Jun 20 00:07:39 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3813021F9F86 for ; Thu, 20 Jun 2013 00:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.452 X-Spam-Level: X-Spam-Status: No, score=-5.452 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 p-xZ7nipopSA for ; Thu, 20 Jun 2013 00:07:35 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8B04021F9BA0 for ; Thu, 20 Jun 2013 00:07:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AUC10653; Thu, 20 Jun 2013 07:07:29 +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; Thu, 20 Jun 2013 08:06:35 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 20 Jun 2013 08:07:09 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Thu, 20 Jun 2013 15:07:06 +0800 From: Xuxiaohu To: "l3vpn-chairs@tools.ietf.org" , "thomas.morin@orange.com" , "martin.vigoureux@alcatel-lucent.com" Subject: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: Ac5thMS2t8EppEHAQo6a5WxySmdDhQ== Date: Thu, 20 Jun 2013 07:07:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C87FE@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 07:07:39 -0000 Hi WG co-chairs, As mentioned before, this draft (http://tools.ietf.org/html/draft-xu-virtua= l-subnet-10) describes how to reuse the proven L3VPN technology to realize = subnet extension for data center interconnect, with the aid of many concret= e experiments and verifications.=20 We co-authors believe the information contained in this draft would be valu= able for cloud service providers to evaluate the feasibility of adopting th= e proven L3VPN technology for data center interconnection (by the way, some= people had shown their interests on the scheme described in this draft whe= n visiting our implementation demo of this scheme at the Bits-N-Bites event= of IETF86). Hence we would like co-chairs to start a WG adoption poll for = this draft.=20 Best regards, Xiaohu (on behalf of all co-authors) From internet-drafts@ietf.org Fri Jun 21 17:38:21 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB05321E8091; Fri, 21 Jun 2013 17:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, 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 6OHy+IiGLTjJ; Fri, 21 Jun 2013 17:38:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5417821F9A25; Fri, 21 Jun 2013 17:38:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l3vpn-mldp-vrf-in-band-signaling-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130622003821.16656.78977.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2013 17:38:21 -0700 Cc: l3vpn@ietf.org X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 00:38:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 3 Virtual Private Networks Working = Group of the IETF. Title : Multipoint Label Distribution Protocol In-Band Signaling= in a VRF Context Author(s) : IJsbrand Wijnands Paul Hitchen Nicolai Leymann Wim Henderickx Arkadiy Gulko Filename : draft-ietf-l3vpn-mldp-vrf-in-band-signaling-01.txt Pages : 13 Date : 2013-06-21 Abstract: Sometimes an IP multicast distribution tree (MDT) traverses both MPLS-enabled and non-MPLS-enabled regions of a network. Typically the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP (Label Switched Path) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non- MPLS region of the network, and using Multipoint Extensions to Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a "Virtual Routing and Forwarding Table" (VRF) link, as defined in the "BGP IP/MPLS VPN" specifications. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than Multicast VPN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l3vpn-mldp-vrf-in-band-signaling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l3vpn-mldp-vrf-in-band-signaling-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l3vpn-mldp-vrf-in-band-signal= ing-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From erosen@cisco.com Mon Jun 24 14:51:10 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2743221E813F; Mon, 24 Jun 2013 14:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.997 X-Spam-Level: X-Spam-Status: No, score=-9.997 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356] 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 2mtiB+FGO+aY; Mon, 24 Jun 2013 14:51:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8C63C21E812C; Mon, 24 Jun 2013 14:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8356; q=dns/txt; s=iport; t=1372110661; x=1373320261; h=from:to:cc:subject:reply-to:date:message-id; bh=FQ4VSS8yjFrIQhuhH4rVt2/4GL1v5rJx7TVTCO7qpTE=; b=N0EGza8yE5kNcmMeAhQ78k8sPyWka8+pZquFiaPCFfVDdlKd4q3iRgJD Ez5hdiOG6/v6LBA3Rfmu1XLd7+svmOO2W5qyWpdd1yQblp+LYcxVbBZwp 3FLZBZrz+ZZtQmpErBnRgFVeICGJe766obW8vyBLqCkSxsivEyXzMzmND c=; X-IronPort-AV: E=Sophos;i="4.87,931,1363132800"; d="scan'208";a="223881863" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jun 2013 21:51:01 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5OLp0R1003476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jun 2013 21:51:00 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r5OLoxQH016687; Mon, 24 Jun 2013 17:50:59 -0400 From: Eric Rosen To: Pavan Kurapati Subject: Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt Date: Mon, 24 Jun 2013 17:50:59 -0400 Message-ID: <16686.1372110659@erosen-linux> Cc: erosen@cisco.com, "l3vpn@ietf.org" , "pim@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 21:51:10 -0000 Stig Venaas and I have discussed draft-kurapati-dynamicrp-bgpmvpn-00.text, and together we have prepared the following set of questions and comments. - We are wondering why the draft proposes to use a new SAFI, rather than reusing the MCAST-VPN SAFI. Using a new SAFI does provide a bit more freedom in designing the NLRI, but the draft sticks to the basic NLRI format of the MCAST-VPN SAFI anyway. I don't think the new SAFI would be used on a BGP session unless the MCAST-VPN SAFI is also used on that session, so why not just use the MCAST-VPN SAFI for the new route types? - The draft seems to allow an AFI of "IPv6" to be used together with an IPv4 BSR address, or vice versa. When using the type 1-7 routes of the MCAST-VPN SAFI, the AFI designates the address family being used by the customer. The address family being used by the service provider is inferred from the various length computations that are discussed in RFC 6515. It seems best to stick with that same convention for the new BSR route types. That would mean that the field "BSR Address" must be of the address family identified by the AFI. The address length would then have to be appropriate for that address family, or the Update would be considered malformed. On the other hand, if it were to be decided to use a new SAFI, it might make more sense to dispense with the RFC 6515 hacks altogether and explicitly encode the address family of each address. - For RP addresses and Group addresses the draft proposes to use the "encoded" formats from the PIM spec. These formats contain an octet that identifies the address family. There should be a requirement that the address family as encoded in the "encoded format" be the same as the address family identified in the BGP Update's AFI, and that the lengths be appropriate for that address family. - In the BGP Update, parsing would be simpler if the Length field that precedes an "encoded group format" field or an "encoded unicast address field" contains the length of that field, not the length of the address prefix that appears within the encoded format. - The mention of the "VRF Route Import Extended Community" in section 4.1 should say "VRF Route Import Extended Community" or "VRF Route Import IPv6 Address Specific Extended Community", to cover the case of a SP with an IPv6 infrastructure. (It also needs to be made clear that this applies to the NLRI of sections 4.2 and 4.3 as well.) - What action is to be taken if a BGP Update with an MCAST-VPN-BSR NLRI is received, but there is no BSR-BGP Path attribute? - It's hard to interpret phrases like "the group count for this NLRI is not set". How does one send this attribute without "setting" all its fields? Does "not set" just mean "set to zero", or does it mean only that certain fields are irrelevant to the processing of certain NLRIs. - The draft could use a little table to show which fields affect the processing which received NLRIs: NLRI FragTag RP Count Group Count BSR Parameters Yes No Yes BSM Group Parameters Yes Yes No BSM RP Parameters Yes No No I think this table corresponds to your intentions. Where a particular NLRI/field combination is "No", perhaps what the draft should say is that the field MUST be ignored when processing that type of NLRI. That would allow the ignored field to carry any value, without risk of any interoperability problems. If one only says "SHOULD be ignored", there may be interoperability problems. - Regarding Fragmentation Tags There don't seem to be any clear instructions as to when the fragmentation tag field of the BSR-BGP attribute of a given NLRI actually needs to be changed. As a result, it's difficult to figure out its uses. If some customer is sending fragmented BSMs every minute, one doesn't want to have BGP update all its RP mappings every minute. So just when does the attribute value have to change? Hopefully not too often, or there will be a lot of BGP thrashing. It's difficult to understand why a fragmentation tag field is needed in the BSR-BGP attribute at all. The Group Count and RP Count fields are really what control when an egress PE can send a BSM. If an ingress PE doesn't advertise changes to a groups RP mappings until it has all the mappings for that group (which I think is required in BSR), why can't fragmentation be entirely a local matter (i.e., not communicated across the net)? What are we missing? - Constructing BSMs from the Counts Suppose an ingress PE receives a BSM with 15 RP mappings for a given group. Then it receives another BSM with 15 RP mappings for that group, 10 of which are the same, and 5 of which are different. It seems that if the egress PE receives "withdraw, update, withdraw, update, withdraw, update, withdraw, update, withdraw, update", it could generate five BSMs. Is our understanding correct, or are we missing something? - End of RIB Given that there is almost always a route reflector between the ingress and egress PEs, how is the "End of RIB" marker going to be helpful in deciding when to originate a BSM? - BS_Timeout There seems to be a problem with the following procedure from section 6.2.2 ("Missing BSM"): "Egress PE receiving a withdrawn "BSR Parameters" route (Type-1) MUST still keep the corresponding Type-2 and Type-3 entries. However, it MUST NOT advertise the BSM to the CE without the Type-1 route present. As soon as the Type-1 is withdrawn, BS_Timeout period has to be started at the egress and upon its expiry, all the Type-2 and Type-3 entries MUST be deleted. Say the egress has generated BSM at t=0. At t=1 BS_Period expired at ingress PE and ingress PE did not get the periodic BSM. So, it withdraws type-1 (BSR Parameters). Egress PE has already generated BSM just before the type-1 withdrawal was received. The egress PE skips the next periodic BSM towards the CE. But CE is "off" by BS_Period interval by now. Once the BS_Timeout expires, egress PE removes all the type-2 and type-3 entries. CEs connected to egress PE will remove the same, a whole BS_Period later. Hence, to avoid this issue, once the BS_Timeout expires,an egress PE MUST generate a new BSM towards CE with RP hold time set to "0" for all the type-2 and type-3 entries. This will make the CEs in sinc with the the PEs. After generating the BSM, PE removes all the Type-2 and Type-3 entries as stated above. The problem is the following. The holding times of the individual RP mapping entries may be longer than the BS_Timeout. Typically if BS_Timeout fires, the remaining holding time of an RP mapping entry will be the difference between (a) its holding time as reported in the last received BSM and (b) BS_Timeout. The above seems to set the RP holding times to zero as soon as BS_Timeout expires. The problem with this is that it may cause the RP mappings to timeout before a new BSR can be elected. Perhaps the withdrawal of a BSR parameters route should trigger the transmission of a new BSM that doesn't set the RP-mapping holding times to zero, but that just reduces each RP-mapping holding time by BS_Timeout. Well, that would correct the RP-mapping holding times downstream of an egress PE, but it would also have the side effect of restarting the BS_Timeout at the routers downstream of the egress PE. So that doesn't seem right either. - With regard to the sentence "As soon as the Type-1 is withdrawn, BS_Timeout period has to be started at the egress and upon its expiry, all the Type-2 and Type-3 entries MUST be deleted", it doesn't seem right for an egress PE to remove BGP installed routes based upon the expiry of a local timer. From sa9362@att.com Mon Jun 24 15:20:36 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37BE21F9E98; Mon, 24 Jun 2013 15:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356] 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 X2UbvdpMqiq5; Mon, 24 Jun 2013 15:20:29 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id C696621F9E99; Mon, 24 Jun 2013 15:20:28 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id c26c8c15.2aaae382b940.3675173.00-500.10196580.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 24 Jun 2013 22:20:28 +0000 (UTC) X-MXL-Hash: 51c8c62c0ef49cee-58951cb659043edb5addc5038a92664202443e45 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id b26c8c15.0.3675171.00-374.10196562.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 24 Jun 2013 22:20:28 +0000 (UTC) X-MXL-Hash: 51c8c62c06aa7e04-e6661c9baa32588d81475c89fd9ead0f6050a90d Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5OMKRoA000789; Mon, 24 Jun 2013 18:20:27 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r5OMKEsn000664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jun 2013 18:20:14 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 24 Jun 2013 22:19:55 GMT Received: from MISOUT7MSGUSR9N.ITServices.sbc.com ([144.151.223.65]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 18:20:03 -0400 From: "ASIF, SAUD" To: "erosen@cisco.com" , Pavan Kurapati Subject: RE: Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt Thread-Topic: Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt Thread-Index: AQHOcSTy9g1VifR/+0KwEjRwntlHLplFb0ZA Date: Mon, 24 Jun 2013 22:20:02 +0000 Message-ID: <0AE6584056494741966D3375421AA5FA0A8153EE@MISOUT7MSGUSR9N.ITServices.sbc.com> References: <16686.1372110659@erosen-linux> In-Reply-To: <16686.1372110659@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.210.9.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=VapAyiV9 c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=LjiJzgVtPZYA:10 a=jbJpJJ24HfYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=oRsydU86GDAA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=VCS96u-Z_NdyCPHywNYA:9 a=CjuIK1q_8ugA:10 a=JfD0Fch1gWkA] X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=gcA5wFdTaSmkQWvO:21 a=sEf1U6gY1GKk] X-AnalysisOut: [LaJU:21] Cc: "l3vpn@ietf.org" , "pim@ietf.org" X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 22:20:36 -0000 Eric, Thanks for your comments. I received it earlier as well. We are looking int= o this and will get back to you shortly. Saud -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Monday, June 24, 2013 5:51 PM To: Pavan Kurapati Cc: l3vpn@ietf.org; pim@ietf.org; Marco Rodrigues; ASIF, SAUD; erosen@cisco= .com Subject: Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt Stig Venaas and I have discussed draft-kurapati-dynamicrp-bgpmvpn-00.text, and together we have prepared the following set of questions and comments. - We are wondering why the draft proposes to use a new SAFI, rather than reusing the MCAST-VPN SAFI. =20 Using a new SAFI does provide a bit more freedom in designing the NLRI, but the draft sticks to the basic NLRI format of the MCAST-VPN SAFI anyway. I don't think the new SAFI would be used on a BGP session unless the MCAST-VPN SAFI is also used on that session, so why not just use the MCAST-VPN SAFI for the new route types? - The draft seems to allow an AFI of "IPv6" to be used together with an IPv= 4 BSR address, or vice versa. When using the type 1-7 routes of the MCAST-VPN SAFI, the AFI designates the address family being used by the customer. The address family being used by the service provider is inferred from the various length computations that are discussed in RFC 6515. It seems best to stick with that same convention for the new BSR route types. That would mean that the field "BSR Address" must be of the address family identified by the AFI. The address length would then have to be appropriate for that address family, or the Update would be considered malformed. On the other hand, if it were to be decided to use a new SAFI, it might make more sense to dispense with the RFC 6515 hacks altogether and explicitly encode the address family of each address. - For RP addresses and Group addresses the draft proposes to use the "encoded" formats from the PIM spec. These formats contain an octet that identifies the address family. There should be a requirement that the address family as encoded in the "encoded format" be the same as the address family identified in the BGP Update's AFI, and that the lengths b= e appropriate for that address family. - In the BGP Update, parsing would be simpler if the Length field that precedes an "encoded group format" field or an "encoded unicast address field" contains the length of that field, not the length of the address prefix that appears within the encoded format. - The mention of the "VRF Route Import Extended Community" in section 4.1 should say "VRF Route Import Extended Community" or "VRF Route Import IPv= 6 Address Specific Extended Community", to cover the case of a SP with an IPv6 infrastructure. (It also needs to be made clear that this applies t= o the NLRI of sections 4.2 and 4.3 as well.) - What action is to be taken if a BGP Update with an MCAST-VPN-BSR NLRI is received, but there is no BSR-BGP Path attribute? - It's hard to interpret phrases like "the group count for this NLRI is not set". How does one send this attribute without "setting" all its fields? Does "not set" just mean "set to zero", or does it mean only that certain fields are irrelevant to the processing of certain NLRIs. - The draft could use a little table to show which fields affect the processing which received NLRIs: NLRI FragTag RP Count Group Coun= t =20 BSR Parameters Yes No Yes =20 BSM Group Parameters Yes Yes No BSM RP Parameters Yes No No I think this table corresponds to your intentions. Where a particular NLRI/field combination is "No", perhaps what the draft should say is that the field MUST be ignored when processing that type of NLRI. That would allow the ignored field to carry any value, without ris= k of any interoperability problems. If one only says "SHOULD be ignored", there may be interoperability problems. - Regarding Fragmentation Tags There don't seem to be any clear instructions as to when the fragmentatio= n tag field of the BSR-BGP attribute of a given NLRI actually needs to be changed. As a result, it's difficult to figure out its uses. If some customer is sending fragmented BSMs every minute, one doesn't want to hav= e BGP update all its RP mappings every minute. So just when does the attribute value have to change? Hopefully not too often, or there will b= e a lot of BGP thrashing. It's difficult to understand why a fragmentation tag field is needed in t= he BSR-BGP attribute at all. The Group Count and RP Count fields are really what control when an egress PE can send a BSM. If an ingress PE doesn't advertise changes to a groups RP mappings until it has all the mappings for that group (which I think is required in BSR), why can't fragmentatio= n be entirely a local matter (i.e., not communicated across the net)? What are we missing? - Constructing BSMs from the Counts Suppose an ingress PE receives a BSM with 15 RP mappings for a given group. Then it receives another BSM with 15 RP mappings for that group, 10 of which are the same, and 5 of which are different. It seems that if the egress PE receives "withdraw, update, withdraw, update, withdraw, update, withdraw, update, withdraw, update", it could generate five BSMs. Is our understanding correct, or are we missing something? - End of RIB Given that there is almost always a route reflector between the ingress and egress PEs, how is the "End of RIB" marker going to be helpful in deciding when to originate a BSM? - BS_Timeout There seems to be a problem with the following procedure from section 6.2.2 ("Missing BSM"): "Egress PE receiving a withdrawn "BSR Parameters" route (Type-1) MUST still keep the corresponding Type-2 and Type-3 entries. However, it MUST NOT advertise the BSM to the CE without the Type-1 route present. As soon as the Type-1 is withdrawn, BS_Timeout period has to be started at the egress and upon its expiry, all the Type-2 and Type-3 entries MUST be deleted. Say the egress has generated BSM at t=3D0. At t=3D1 BS_Period expired at ingress PE and ingress PE did not get the periodic BSM. So, it withdraws type-1 (BSR Parameters). Egress PE has already generated BSM just before the type-1 withdrawal was received. The egress PE skips the next periodic BSM towards the CE. But CE is "off" by BS_Period interval by now. Once the BS_Timeout expires, egress PE removes all the type-2 and type-3 entries. CEs connected to egress PE will remove the same, a whole BS_Period later. Hence, to avoid this issue, once the BS_Timeout expires,an egress PE MUST generate a new BSM towards CE with RP hold time set to "0" for all the type-2 and type-3 entries. This will make the CEs in sinc with the the PEs. After generating the BSM, PE removes all the Type-2 and Type-3 entries as stated above. The problem is the following. The holding times of the individual RP mapping entries may be longer than the BS_Timeout. Typically if BS_Timeout fires, the remaining holding time of an RP mapping entry will be the difference between (a) its holding time as reported in the last received BSM and (b) BS_Timeout. The above seems to set the RP holding times to zero as soon as BS_Timeout expires. The problem with this is that it may cause the RP mappings to timeout before a new BSR can be elected. Perhaps the withdrawal of a BSR parameters route should trigger the transmission of a new BSM that doesn't set the RP-mapping holding times to zero, but that just reduces each RP-mapping holding time by BS_Timeout. Well, that would correct the RP-mapping holding times downstream of an egress PE, but it would also have the side effect of restarting the BS_Timeout at the routers downstream of the egress PE. S= o that doesn't seem right either. - With regard to the sentence "As soon as the Type-1 is withdrawn, BS_Timeout period has to be started at the egress and upon its expiry, al= l the Type-2 and Type-3 entries MUST be deleted", it doesn't seem right for an egress PE to remove BGP installed routes based upon the expiry of a local timer. =20 =20 =20 =20 =20 =20 =20 =20 =20 From xuxiaohu@huawei.com Sun Jun 30 18:36:05 2013 Return-Path: X-Original-To: l3vpn@ietfa.amsl.com Delivered-To: l3vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD7421F9E95 for ; Sun, 30 Jun 2013 18:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 u64NPsy4O0Sy for ; Sun, 30 Jun 2013 18:35:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3A22B21F9E91 for ; Sun, 30 Jun 2013 18:35:57 -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 ASZ65530; Mon, 01 Jul 2013 01:35:55 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Jul 2013 02:33:38 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Jul 2013 02:34:32 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Mon, 1 Jul 2013 09:34:27 +0800 From: Xuxiaohu To: "l3vpn-chairs@tools.ietf.org" , "thomas.morin@orange.com" , "martin.vigoureux@alcatel-lucent.com" Subject: re: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Topic: Request a WG adoption poll for draft-xu-virtual-subnet-10 Thread-Index: Ac5thMS2t8EppEHAQo6a5WxySmdDhQIdhP9g Date: Mon, 1 Jul 2013 01:34:26 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081CAD74@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: L3VPN X-BeenThere: l3vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 01:36:05 -0000 SGkgVGhvbWFzIGFuZCBNYXJ0aW4sDQoNCkkgaGF2ZW4ndCByZWNlaXZlZCBhbnkgcmVzcG9uc2Ug ZnJvbSBhbnkgb2YgeW91LiBIZW5jZSBJIHJlc2VuZCBpdC4NCg0KQmVzdCByZWdhcmRzLA0KWGlh b2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogWHV4aWFvaHUNCj4gt6LLzcqx vOQ6IDIwMTPE6jbUwjIwyNUgMTU6MDcNCj4gytW8/sjLOiAnbDN2cG4tY2hhaXJzQHRvb2xzLmll dGYub3JnJzsgJ3Rob21hcy5tb3JpbkBvcmFuZ2UuY29tJzsNCj4gJ21hcnRpbi52aWdvdXJldXhA YWxjYXRlbC1sdWNlbnQuY29tJw0KPiCzrcvNOiBMM1ZQTg0KPiDW98ziOiBSZXF1ZXN0IGEgV0cg YWRvcHRpb24gcG9sbCBmb3IgZHJhZnQteHUtdmlydHVhbC1zdWJuZXQtMTANCj4gDQo+IEhpIFdH IGNvLWNoYWlycywNCj4gDQo+IEFzIG1lbnRpb25lZCBiZWZvcmUsIHRoaXMgZHJhZnQNCj4gKGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXZpcnR1YWwtc3VibmV0LTEwKSBkZXNj cmliZXMgaG93IHRvIHJldXNlDQo+IHRoZSBwcm92ZW4gTDNWUE4gdGVjaG5vbG9neSB0byByZWFs aXplIHN1Ym5ldCBleHRlbnNpb24gZm9yIGRhdGEgY2VudGVyDQo+IGludGVyY29ubmVjdCwgd2l0 aCB0aGUgYWlkIG9mIG1hbnkgY29uY3JldGUgZXhwZXJpbWVudHMgYW5kIHZlcmlmaWNhdGlvbnMu DQo+IA0KPiBXZSBjby1hdXRob3JzIGJlbGlldmUgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIGRyYWZ0IHdvdWxkIGJlIHZhbHVhYmxlDQo+IGZvciBjbG91ZCBzZXJ2aWNlIHByb3Zp ZGVycyB0byBldmFsdWF0ZSB0aGUgZmVhc2liaWxpdHkgb2YgYWRvcHRpbmcgdGhlIHByb3Zlbg0K PiBMM1ZQTiB0ZWNobm9sb2d5IGZvciBkYXRhIGNlbnRlciBpbnRlcmNvbm5lY3Rpb24gKGJ5IHRo ZSB3YXksIHNvbWUgcGVvcGxlDQo+IGhhZCBzaG93biB0aGVpciBpbnRlcmVzdHMgb24gdGhlIHNj aGVtZSBkZXNjcmliZWQgaW4gdGhpcyBkcmFmdCB3aGVuIHZpc2l0aW5nDQo+IG91ciBpbXBsZW1l bnRhdGlvbiBkZW1vIG9mIHRoaXMgc2NoZW1lIGF0IHRoZSBCaXRzLU4tQml0ZXMgZXZlbnQgb2Yg SUVURjg2KS4NCj4gSGVuY2Ugd2Ugd291bGQgbGlrZSBjby1jaGFpcnMgdG8gc3RhcnQgYSBXRyBh ZG9wdGlvbiBwb2xsIGZvciB0aGlzIGRyYWZ0Lg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFv aHUgKG9uIGJlaGFsZiBvZiBhbGwgY28tYXV0aG9ycykNCg==