From xuxiaohu@huawei.com Sun Jun 2 20:51:46 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B7A21F8F38 for ; Sun, 2 Jun 2013 20:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 2GDq3dOgpkBO for ; Sun, 2 Jun 2013 20:51:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E316221F8CB5 for ; Sun, 2 Jun 2013 20:51:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASA87010; Mon, 03 Jun 2013 03:51:37 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 3 Jun 2013 04:50:50 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 3 Jun 2013 04:51:34 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Mon, 3 Jun 2013 11:51:28 +0800 From: Xuxiaohu To: Mike McBride , "Prashant Jhingran (pjhingra)" Thread-Topic: [pim] call for adoption: draft-zhou-pim-vrrp-01 Thread-Index: AQHOXc1oyBNO9pOfGUaQq5QJP/JnZZkjXzZA Date: Mon, 3 Jun 2013 03:51:28 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C4824@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F669D4@NKGEML512-MBS.china.huawei.com> In-Reply-To: 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: "sganesan@extremenetworks.com" , "pim@ietf.org" Subject: [pim] =?gb2312?b?tPC4tDogIGNhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16aG91?= =?gb2312?b?LXBpbS12cnJwLTAx?= X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 03:51:46 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogTWlrZSBNY0JyaWRlIFttYWlsdG86 bW1jYnJpZGU3QGdtYWlsLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTPE6jXUwjMxyNUgMTU6MDcNCj4g ytW8/sjLOiBQcmFzaGFudCBKaGluZ3JhbiAocGpoaW5ncmEpDQo+ILOty806IFJhaml2IEFzYXRp IChyYWppdmEpOyBYdXhpYW9odTsgc2dhbmVzYW5AZXh0cmVtZW5ldHdvcmtzLmNvbTsgV2VpDQo+ IFpob3UgKHdlaXpobzIpOyBTdGlnIFZlbmFhczsgcGltQGlldGYub3JnDQo+INb3zOI6IFJlOiBb cGltXSBjYWxsIGZvciBhZG9wdGlvbjogZHJhZnQtemhvdS1waW0tdnJycC0wMQ0KPiANCj4gVGhh bmsgeW91IGZvciB0aGUgcmVzcG9uc2VzLg0KPiANCj4gU29tZSBmZWVsIHRoZSB0d28gZHJhZnRz IGFyZSBjb21wbGV0ZWx5IHVucmVsYXRlZCB3aGlsZSBvdGhlcnMgZmVlbA0KPiB0aGV5IGFyZSBj b21wbGV0ZWx5IHJlbGF0ZWQuIEluIGVpdGhlciBjYXNlLCBhcmUgeW91LCB3aG8gZmVlbCB0aGV5 DQo+IGFyZSByZWxhdGVkLCBzYXlpbmcgeW91IG9wcG9zZSB0aGUgYWRvcHRpb24gb2YgZHJhZnQt emhvdS1waW0tdnJycC0wMT8NCj4gV2UgY2FuIGluZmVyIHRoYXQgaXMgdGhlIGNhc2UgYnV0IEkg aGF2ZW4ndCBoZWFyZCBleHBsaWNpdGx5IHN0YXRlZA0KPiBvcHBvc2l0aW9uIHRvIGFkb3B0aW9u LiBXZSBub3cgaGF2ZSBzZXZlcmFsIGNob2ljZXMgZm9yDQo+IGRyYWZ0LXpob3UtcGltLXZycnAs IGxldCBtZSB0cnkgYm9pbGluZyBpdCBkb3duIHRvIDM6DQo+IA0KPiAxLiBhZG9wdCBkcmFmdC16 aG91LXBpbS12cnJwLTAxIGFzIGlzDQo+IDIuIGFkb3B0IGRyYWZ0LXpob3UtcGltLXZycnAtMDEg b25seSBhZnRlcg0KPiBkcmFmdC14dS1waW0tZHJwcmlvcml0eS1hdXRvLWFkanVzdG1lbnQgaXMg cmVmZXJlbmNlZC4NCj4gMy4gbWVyZ2UgdGhlIGRyYWZ0cw0KDQpJIHByZWZlciBvcHRpb24gMy4N Cg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gSW4gZWl0aGVyIGNhc2UgdGhlIGF1dGhvcnMg c2hvdWxkIHJldml2ZSB0aGUgZXhwaXJlZA0KPiBkcmFmdC14dS1waW0tZHJwcmlvcml0eS1hdXRv LWFkanVzdG1lbnQtMDMgZm9yIGNvbnNpZGVyYXRpb24gd2l0aGluDQo+IHRoZSB3ZyBpcnJlZ2Fy ZGxlc3Mgb2YgdnJycC0wMSBhZG9wdGlvbiBvdXRjb21lLg0KPiANCj4gV2hhdCBzYXkgeWU/DQo+ IA0KPiBtaWtlDQo+IA0KPiBPbiBUaHUsIE1heSAyMywgMjAxMyBhdCAyOjA4IEFNLCBQcmFzaGFu dCBKaGluZ3JhbiAocGpoaW5ncmEpDQo+IDxwamhpbmdyYUBjaXNjby5jb20+IHdyb3RlOg0KPiA+ IEhpIE1pa2UsDQo+ID4NCj4gPiBJIGFncmVlIHdpdGggUmFqaXYsIGJvdGggZHJhZnRzIGFyZSB0 cnlpbmcgdG8gc29sdmUgdGhlIHNhbWUgaXNzdWUuLi4udGhhdCB0b28gaW4NCj4gYWxtb3N0IHNp bWlsYXIgd2F5Lg0KPiA+DQo+ID4gLQ0KPiA+IFJlZ2FyZHMsDQo+ID4gUHJhc2hhbnQgSmhpbmdy YW4NCj4gPiBOT1NURyBUTUUgLSBTUCBXaS1GaQ0KPiA+DQo+ID4gaHR0cDovL3d3d2luLmNpc2Nv LmNvbS9pb3MvdGVjaC9tb2JpbGUvcHJveHlpcHY2Lw0KPiA+IGh0dHA6Ly93d3dpbi5jaXNjby5j b20vaW9zL3RlY2gvYnJvYWRiYW5kDQo+ID4NCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogUmFqaXYgQXNhdGkgKHJhaml2YSkNCj4gPiBTZW50OiBUaHVyc2Rh eSwgTWF5IDIzLCAyMDEzIDM6MDYgQU0NCj4gPiBUbzogTWlrZSBNY0JyaWRlOyBYdXhpYW9odTsg c2dhbmVzYW5AZXh0cmVtZW5ldHdvcmtzLmNvbTsgUHJhc2hhbnQNCj4gSmhpbmdyYW4gKHBqaGlu Z3JhKTsgV2VpIFpob3UgKHdlaXpobzIpDQo+ID4gQ2M6IFN0aWcgVmVuYWFzOyBwaW1AaWV0Zi5v cmcNCj4gPiBTdWJqZWN0OiBSRTogW3BpbV0gY2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXpob3Ut cGltLXZycnAtMDENCj4gPg0KPiA+IEhpIE1pa2UsDQo+ID4NCj4gPiBJdCBzZWVtcyB0aGF0IGJv dGggZHJhZnRzIHNlZW0gdG8gc29sdmUgbmVhcmx5IHRoZSBzYW1lIHByb2JsZW0gKG11bHRpcGxl DQo+IHJvdXRlcnMgb24gdGhlIG11bHRpLWFjY2VzcyBpbnRlcmZhY2UgYW5kIGV4aXN0ZW5jZSBv ZiBmaXJzdC1ob3AgcmVkdW5kYW5jeQ0KPiBwcm90b2NvbHMgZS5nLiBWUlJQKS4NCj4gPg0KPiA+ IENoZWVycywNCj4gPiBSYWppdg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPj4gRnJvbTogTWlrZSBNY0JyaWRlIFttYWlsdG86bW1jYnJpZGU3QGdtYWlsLmNv bV0NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMjIsIDIwMTMgMjoxNyBBTQ0KPiA+PiBUbzog WHV4aWFvaHU7IHNnYW5lc2FuQGV4dHJlbWVuZXR3b3Jrcy5jb207IFJhaml2IEFzYXRpIChyYWpp dmEpOw0KPiA+PiBQcmFzaGFudCBKaGluZ3JhbiAocGpoaW5ncmEpOyBXZWkgWmhvdSAod2Vpemhv MikNCj4gPj4gQ2M6IFN0aWcgVmVuYWFzOyBNaWtlIE1jQnJpZGU7IHBpbUBpZXRmLm9yZw0KPiA+ PiBTdWJqZWN0OiBSZTogW3BpbV0gY2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXpob3UtcGltLXZy cnAtMDENCj4gPj4NCj4gPj4gRm9sa3MsDQo+ID4+DQo+ID4+IFdlIGhhdmUgdGhpcyBuZXcgZHJh ZnQtemhvdS1waW0tdnJycC0wMSB3aGljaCB3ZSBhcmUgYWJvdXQgdG8gYWRvcHQNCj4gPj4gaW50 byB0aGUgcGltIHdnLiBJdCBoYXMgYmVlbiBicm91Z2h0IHRvIHRoZSBXR3MgYXR0ZW50aW9uIHRo YXQgdGhlcmUNCj4gPj4gaXMgYSBvbGRlciBkcmFmdCAoZHJhZnQteHUtcGltLWRycHJpb3JpdHkt YXV0by1hZGp1c3RtZW50LTAzKSB3aGljaA0KPiA+PiBtYXkgaGF2ZSBzb21lIG92ZXJsYXAgd2l0 aCB0aGUgbmV3IG9uZS4gVGhhdCBvbGRlciBkcmFmdCBkb2VzIGNvbnRhaW4NCj4gPj4gaW5mb3Jt YXRpb24gYWJvdXQgVlJSUCBhd2FyZSBQSU0gd2hpY2ggaXMgYXR0cmlidXRlZCB0byBTdGlnIGlu IHRoZQ0KPiA+PiBhY2tub3dsZWRnZW1lbnRzLiBJZiB0aGUgZml2ZSBvZiB5b3UgYXV0aG9ycyBm ZWVsIHRoYXQgdGhlcmUgaXMgc29tZQ0KPiA+PiB2YWxpZGl0eSB0aGF0IHRoZSBvbGRlciBkcmFm dCBjb250YWlucyBzb21lIGluZm9ybWF0aW9uIGJlaW5nIHVzZWQgaW4NCj4gPj4gdGhlIG5ldyBk cmFmdCwgeW91IG1heSB3YW50IHRvIGFja25vd2xlZGdlIHRoYXQgaW4gdGhlIHJlZmVyZW5jZXMg b3INCj4gPj4gYWNrbm93bGVkZ2VtZW50cy4gSXQgYXBwZWFycyB0aGUgZHJhZnRzIGFyZSBkaXNz aW1pbGFyIGVub3VnaCB0byBub3QNCj4gPj4gYmUgbWVyZ2VkIGJ1dCBJIG1heSBiZSB3cm9uZy4g UGxlYXNlIHNoYXJlIHlvdXIgb3BpbmlvbnMgb24gdGhpcyBzbyB3ZQ0KPiA+PiBjYW4gZXN0YWJs aXNoIGNvbnNlbnN1cyB3aXRoaW4gdGhlIGdyb3VwIGFuZCBtb3ZlIHRoZSBkb2N1bWVudCBhbG9u Zy4NCj4gPj4NCj4gPj4gSWYgdGhlIGJyb2FkZXIgV0cgcGFydGljaXBhbnRzIGhhdmUgYW4gb3Bp bmlvbiBvbiB0aGlzIHBsZWFzZSBzcGVhayB1cC4NCj4gPj4NCj4gPj4gdGhhbmtzLA0KPiA+PiBt aWtlDQo+ID4+DQo+ID4+IE9uIFRodSwgTWF5IDksIDIwMTMgYXQgNzozMiBQTSwgWHV4aWFvaHUg PHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+PiA+IEhpIGFsbCwNCj4gPj4gPg0KPiA+ PiA+IFRoaXMgZHJhZnQgcmVtaW5kcyBtZSB0aGF0IHRoZXJlIGhhcyBiZWVuIGEgZHJhZnQNCj4g Pj4gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXBpbS1kcnByaW9yaXR5LWF1 dG8tYWRqdXN0bWVudC0wMw0KPiA+PiApIHRocmVlIHllYXJzIGJlZm9yZSB3aGljaCB1c2VzIGFs bW9zdCB0aGUgc2FtZSB0ZWNobm9sb2d5IHRvIHNhdmUNCj4gPj4gYWxtb3N0IHRoZSBzYW1lIHBy b2JsZW0uDQo+ID4+ID4NCj4gPj4gPiBUaGUgZm9sbG93aW5nIGlzIHF1b3RlZCBmcm9tIHRoZSBh Ym92ZSBkcmFmdDoNCj4gPj4gPg0KPiA+PiA+ICAgICJJbiBmYWN0LCBpZiBWUlJQIGlzIHJ1biBv biB0aGUgUElNIHJvdXRlcnMgYW5kIHRoZSBWUlJQIGhhcyBlbmFibGVkDQo+ID4+ID4gICAgdGhl IHVwc3RyZWFtIGxpbmsgdHJhY2tpbmcgbWVjaGFuaXNtLCB0aGUgUElNIERSIGZhaWxvdmVyDQo+ IG1lY2hhbmlzbQ0KPiA+PiA+ICAgIGNvdWxkIGJlIGNvdXBsZWQgd2l0aCB0aGUgVlJSUCBzbyBh cyB0byByZXVzZSB0aGUgdXBzdHJlYW0gbGluaw0KPiA+PiA+ICAgIHRyYWNraW5nIG1lY2hhbmlz bSBvZiBWUlJQLiBPbmUgb3B0aW9uIGlzIHRvIHN5bmNocm9uaXplIHRoZSBQSU0gRFINCj4gPj4g PiAgICBwcmlvcml0eSB2YWx1ZSB0byB0aGUgVlJSUCBwcmlvcml0eSB2YWx1ZSBhbHdheXMuIElu IHRoaXMgd2F5LCB0aGUNCj4gPj4gPiAgICBQSU0gRFIgYW5kIHRoZSBWUlJQIG1hc3RlciB3aWxs IGFsd2F5cyBydW4gb24gYW4gaWRlbnRpY2FsIHJvdXRlciBpZg0KPiA+PiA+ICAgIHRoZSBWUlJQ IFByZWVtcHRfTW9kZSBpcyBzZXQgdG8gVHJ1ZS4gQW5vdGhlciBvcHRpb24gaXMgdG8gbWFrZSB0 aGUNCj4gPj4gPiAgICBQSU0gRFIgYW5kIHRoZSBWUlJQIG1hc3RlciBydW4gb24gYW4gaWRlbnRp Y2FsIHJvdXRlciBhbnl3YXkgKGkuZS4sDQo+ID4+ID4gICAgcmVnYXJkbGVzcyB3aGV0aGVyIG9y IG5vdCB0aGUgVlJSUCBQcmVlbXB0X01vZGUgaXMgVHJ1ZSkuIFRvDQo+IGFjaGlldmUNCj4gPj4g PiAgICB0aGlzIGdvYWwsIHRoZSBQSU0gRFIgcHJpb3JpdHkgb2YgdGhlIFZSUlAgbWFzdGVyIHJv dXRlciBTSE9VTEQNCj4gPj4gPiAgICBhbHdheXMgYmUgc2V0IHRvIGEgaGlnaGVyIGZpeGVkIHZh bHVlIHRoYW4gdGhhdCBvZiB0aGUgVlJSUCBzbGF2ZQ0KPiA+PiA+ICAgIHJvdXRlciBhdXRvbWF0 aWNhbGx5LiINCj4gPj4gPg0KPiA+PiA+IEJlc3QgcmVnYXJkcywNCj4gPj4gPiBYaWFvaHUNCj4g Pj4gPg0KPiA+PiA+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPj4gPj4gt6K8/sjLOiBwaW0tYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBpbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+ID4+IE1p a2UNCj4gPj4gPj4gTWNCcmlkZQ0KPiA+PiA+PiC3osvNyrG85DogMjAxM8TqNdTCMTDI1SAzOjQ4 DQo+ID4+ID4+IMrVvP7IyzogcGltQGlldGYub3JnDQo+ID4+ID4+INb3zOI6IFtwaW1dIGNhbGwg Zm9yIGFkb3B0aW9uOiBkcmFmdC16aG91LXBpbS12cnJwLTAxDQo+ID4+ID4+DQo+ID4+ID4+IGRy YWZ0LXpob3UtcGltLXZycnAtMDEgd2FzIHByZXNlbnRlZCBpbiBvdXIgbW9zdCByZWNlbnQgcGlt IG1lZXRpbmcNCj4gPj4gPj4gaW4gT3JsYW5kby4gNCBwZW9wbGUgd2VyZSBpbiBmYXZvciBvZiBh ZG9wdGluZyB0aGUgZHJhZnQuIFplcm8gYWdhaW5zdC4NCj4gPj4gPj4gUGxlYXNlIHJlYWQgdGhl IGRyYWZ0IChpdHMgc2hvcnQpIGFuZCBwcm92aWRlIGFuIG9waW5pb24gZWl0aGVyIHdheQ0KPiA+ PiA+PiBieSB0aGUgZW5kIG9mIG5leHQgRnJpZGF5IHRoZSAxN3RoLg0KPiA+PiA+Pg0KPiA+PiA+ PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXpob3UtcGltLXZycnAtMDEudHh0DQo+ID4+ ID4+DQo+ID4+ID4+IHRoYW5rcywNCj4gPj4gPj4gbWlrZQ0KPiA+PiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+PiBwaW0gbWFpbGluZyBs aXN0DQo+ID4+ID4+IHBpbUBpZXRmLm9yZw0KPiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3BpbQ0K From stig@venaas.com Mon Jun 3 10:39:35 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A49C21F8F3E for ; Mon, 3 Jun 2013 10:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.966 X-Spam-Level: X-Spam-Status: No, score=-94.966 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345, 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 N6rj95mi+-68 for ; Mon, 3 Jun 2013 10:39:25 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 90B5721F8EAD for ; Mon, 3 Jun 2013 10:33:16 -0700 (PDT) Received: from [IPv6:2001:420:301:1004:fd03:20e:59e5:4632] (unknown [IPv6:2001:420:301:1004:fd03:20e:59e5:4632]) by ufisa.uninett.no (Postfix) with ESMTPSA id 203ED830C; Mon, 3 Jun 2013 19:33:12 +0200 (CEST) Message-ID: <51ACD34B.90001@venaas.com> Date: Mon, 03 Jun 2013 10:32:59 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Xuxiaohu References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F669D4@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C4824@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C4824@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: "sganesan@extremenetworks.com" , Mike McBride , "pim@ietf.org" Subject: Re: [pim] =?gb2312?b?tPC4tDogIGNhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16aG91?= =?gb2312?b?LXBpbS12cnJwLTAx?= X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 17:39:35 -0000 Hi On 6/2/2013 8:51 PM, Xuxiaohu wrote: > > >> -----ÓʼþÔ­¼þ----- >> ·¢¼þÈË: Mike McBride [mailto:mmcbride7@gmail.com] >> ·¢ËÍʱ¼ä: 2013Äê5ÔÂ31ÈÕ 15:07 >> ÊÕ¼þÈË: Prashant Jhingran (pjhingra) >> ³­ËÍ: Rajiv Asati (rajiva); Xuxiaohu; sganesan@extremenetworks.com; Wei >> Zhou (weizho2); Stig Venaas; pim@ietf.org >> Ö÷Ìâ: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01 >> >> Thank you for the responses. >> >> Some feel the two drafts are completely unrelated while others feel >> they are completely related. In either case, are you, who feel they >> are related, saying you oppose the adoption of draft-zhou-pim-vrrp-01? >> We can infer that is the case but I haven't heard explicitly stated >> opposition to adoption. We now have several choices for >> draft-zhou-pim-vrrp, let me try boiling it down to 3: >> >> 1. adopt draft-zhou-pim-vrrp-01 as is >> 2. adopt draft-zhou-pim-vrrp-01 only after >> draft-xu-pim-drpriority-auto-adjustment is referenced. >> 3. merge the drafts > > I prefer option 3. I don't think we should simply do a vote here, we need to get an understanding of what the WG wants and see if we have a rough consensus. I think it would be helpful if people responding could state why they believe so, this may lead to some useful discussion and help people make up their mind. As for merging, we need to see if the WG is interested in the content of both the two drafts, and consider whether merging them makes sense. We did have some support for adopting draft-zhou-pim-vrrp-01 in the last meeting, while draft-xu-pim-drpriority-auto-adjustment was discussed a few years ago, and people probably need to re-read it and see what they think now. Stig > Best regards, > Xiaohu > >> In either case the authors should revive the expired >> draft-xu-pim-drpriority-auto-adjustment-03 for consideration within >> the wg irregardless of vrrp-01 adoption outcome. >> >> What say ye? >> >> mike >> >> On Thu, May 23, 2013 at 2:08 AM, Prashant Jhingran (pjhingra) >> wrote: >>> Hi Mike, >>> >>> I agree with Rajiv, both drafts are trying to solve the same issue....that too in >> almost similar way. >>> >>> - >>> Regards, >>> Prashant Jhingran >>> NOSTG TME - SP Wi-Fi >>> >>> http://wwwin.cisco.com/ios/tech/mobile/proxyipv6/ >>> http://wwwin.cisco.com/ios/tech/broadband >>> >>> >>> -----Original Message----- >>> From: Rajiv Asati (rajiva) >>> Sent: Thursday, May 23, 2013 3:06 AM >>> To: Mike McBride; Xuxiaohu; sganesan@extremenetworks.com; Prashant >> Jhingran (pjhingra); Wei Zhou (weizho2) >>> Cc: Stig Venaas; pim@ietf.org >>> Subject: RE: [pim] call for adoption: draft-zhou-pim-vrrp-01 >>> >>> Hi Mike, >>> >>> It seems that both drafts seem to solve nearly the same problem (multiple >> routers on the multi-access interface and existence of first-hop redundancy >> protocols e.g. VRRP). >>> >>> Cheers, >>> Rajiv >>> >>> >>>> -----Original Message----- >>>> From: Mike McBride [mailto:mmcbride7@gmail.com] >>>> Sent: Wednesday, May 22, 2013 2:17 AM >>>> To: Xuxiaohu; sganesan@extremenetworks.com; Rajiv Asati (rajiva); >>>> Prashant Jhingran (pjhingra); Wei Zhou (weizho2) >>>> Cc: Stig Venaas; Mike McBride; pim@ietf.org >>>> Subject: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01 >>>> >>>> Folks, >>>> >>>> We have this new draft-zhou-pim-vrrp-01 which we are about to adopt >>>> into the pim wg. It has been brought to the WGs attention that there >>>> is a older draft (draft-xu-pim-drpriority-auto-adjustment-03) which >>>> may have some overlap with the new one. That older draft does contain >>>> information about VRRP aware PIM which is attributed to Stig in the >>>> acknowledgements. If the five of you authors feel that there is some >>>> validity that the older draft contains some information being used in >>>> the new draft, you may want to acknowledge that in the references or >>>> acknowledgements. It appears the drafts are dissimilar enough to not >>>> be merged but I may be wrong. Please share your opinions on this so we >>>> can establish consensus within the group and move the document along. >>>> >>>> If the broader WG participants have an opinion on this please speak up. >>>> >>>> thanks, >>>> mike >>>> >>>> On Thu, May 9, 2013 at 7:32 PM, Xuxiaohu wrote: >>>>> Hi all, >>>>> >>>>> This draft reminds me that there has been a draft >>>> (http://tools.ietf.org/html/draft-xu-pim-drpriority-auto-adjustment-03 >>>> ) three years before which uses almost the same technology to save >>>> almost the same problem. >>>>> >>>>> The following is quoted from the above draft: >>>>> >>>>> "In fact, if VRRP is run on the PIM routers and the VRRP has enabled >>>>> the upstream link tracking mechanism, the PIM DR failover >> mechanism >>>>> could be coupled with the VRRP so as to reuse the upstream link >>>>> tracking mechanism of VRRP. One option is to synchronize the PIM DR >>>>> priority value to the VRRP priority value always. In this way, the >>>>> PIM DR and the VRRP master will always run on an identical router if >>>>> the VRRP Preempt_Mode is set to True. Another option is to make the >>>>> PIM DR and the VRRP master run on an identical router anyway (i.e., >>>>> regardless whether or not the VRRP Preempt_Mode is True). To >> achieve >>>>> this goal, the PIM DR priority of the VRRP master router SHOULD >>>>> always be set to a higher fixed value than that of the VRRP slave >>>>> router automatically." >>>>> >>>>> Best regards, >>>>> Xiaohu >>>>> >>>>>> -----ÓʼþÔ­¼þ----- >>>>>> ·¢¼þÈË: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] ´ú±í >>>> Mike >>>>>> McBride >>>>>> ·¢ËÍʱ¼ä: 2013Äê5ÔÂ10ÈÕ 3:48 >>>>>> ÊÕ¼þÈË: pim@ietf.org >>>>>> Ö÷Ìâ: [pim] call for adoption: draft-zhou-pim-vrrp-01 >>>>>> >>>>>> draft-zhou-pim-vrrp-01 was presented in our most recent pim meeting >>>>>> in Orlando. 4 people were in favor of adopting the draft. Zero against. >>>>>> Please read the draft (its short) and provide an opinion either way >>>>>> by the end of next Friday the 17th. >>>>>> >>>>>> http://www.ietf.org/id/draft-zhou-pim-vrrp-01.txt >>>>>> >>>>>> thanks, >>>>>> mike >>>>>> _______________________________________________ >>>>>> pim mailing list >>>>>> pim@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/pim From xuxiaohu@huawei.com Tue Jun 4 00:17:06 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B0821E8086 for ; Tue, 4 Jun 2013 00:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 xrNZoUdDjT53 for ; Tue, 4 Jun 2013 00:16:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9E921F9B2C for ; Mon, 3 Jun 2013 23:17:49 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN90901; Tue, 04 Jun 2013 06:17:47 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 4 Jun 2013 07:17:02 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 4 Jun 2013 14:17:45 +0800 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Tue, 4 Jun 2013 14:17:38 +0800 From: Xuxiaohu To: Stig Venaas Thread-Topic: =?gb2312?B?W3BpbV0gtPC4tDogIGNhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16aG91LXBp?= =?gb2312?Q?m-vrrp-01?= Thread-Index: AQHOYIFVRz1ZkcfbJ0KUC0Rw5g9zppkk6OYg Date: Tue, 4 Jun 2013 06:17:38 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C4DF1@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F669D4@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C4824@NKGEML512-MBS.china.huawei.com> <51ACD34B.90001@venaas.com> In-Reply-To: <51ACD34B.90001@venaas.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: "sganesan@extremenetworks.com" , Mike McBride , "pim@ietf.org" Subject: [pim] =?gb2312?b?tPC4tDogILTwuLQ6ICBjYWxsIGZvciBhZG9wdGlvbjogZHJh?= =?gb2312?b?ZnQtemhvdS1waW0tdnJycC0wMQ==?= X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 07:17:06 -0000 SGkgU3RpZywNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBwaW0tYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnBpbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFN0aWcNCj4gVmVuYWFz DQo+ILeiy83KsbzkOiAyMDEzxOo21MI0yNUgMTozMw0KPiDK1bz+yMs6IFh1eGlhb2h1DQo+ILOt y806IHNnYW5lc2FuQGV4dHJlbWVuZXR3b3Jrcy5jb207IE1pa2UgTWNCcmlkZTsgcGltQGlldGYu b3JnDQo+INb3zOI6IFJlOiBbcGltXSC08Li0OiBjYWxsIGZvciBhZG9wdGlvbjogZHJhZnQtemhv dS1waW0tdnJycC0wMQ0KPiANCj4gSGkNCj4gDQo+IE9uIDYvMi8yMDEzIDg6NTEgUE0sIFh1eGlh b2h1IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+ILeivP7I yzogTWlrZSBNY0JyaWRlIFttYWlsdG86bW1jYnJpZGU3QGdtYWlsLmNvbV0NCj4gPj4gt6LLzcqx vOQ6IDIwMTPE6jXUwjMxyNUgMTU6MDcNCj4gPj4gytW8/sjLOiBQcmFzaGFudCBKaGluZ3JhbiAo cGpoaW5ncmEpDQo+ID4+ILOty806IFJhaml2IEFzYXRpIChyYWppdmEpOyBYdXhpYW9odTsgc2dh bmVzYW5AZXh0cmVtZW5ldHdvcmtzLmNvbTsgV2VpDQo+ID4+IFpob3UgKHdlaXpobzIpOyBTdGln IFZlbmFhczsgcGltQGlldGYub3JnDQo+ID4+INb3zOI6IFJlOiBbcGltXSBjYWxsIGZvciBhZG9w dGlvbjogZHJhZnQtemhvdS1waW0tdnJycC0wMQ0KPiA+Pg0KPiA+PiBUaGFuayB5b3UgZm9yIHRo ZSByZXNwb25zZXMuDQo+ID4+DQo+ID4+IFNvbWUgZmVlbCB0aGUgdHdvIGRyYWZ0cyBhcmUgY29t cGxldGVseSB1bnJlbGF0ZWQgd2hpbGUgb3RoZXJzIGZlZWwNCj4gPj4gdGhleSBhcmUgY29tcGxl dGVseSByZWxhdGVkLiBJbiBlaXRoZXIgY2FzZSwgYXJlIHlvdSwgd2hvIGZlZWwgdGhleQ0KPiA+ PiBhcmUgcmVsYXRlZCwgc2F5aW5nIHlvdSBvcHBvc2UgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LXpo b3UtcGltLXZycnAtMDE/DQo+ID4+IFdlIGNhbiBpbmZlciB0aGF0IGlzIHRoZSBjYXNlIGJ1dCBJ IGhhdmVuJ3QgaGVhcmQgZXhwbGljaXRseSBzdGF0ZWQNCj4gPj4gb3Bwb3NpdGlvbiB0byBhZG9w dGlvbi4gV2Ugbm93IGhhdmUgc2V2ZXJhbCBjaG9pY2VzIGZvcg0KPiA+PiBkcmFmdC16aG91LXBp bS12cnJwLCBsZXQgbWUgdHJ5IGJvaWxpbmcgaXQgZG93biB0byAzOg0KPiA+Pg0KPiA+PiAxLiBh ZG9wdCBkcmFmdC16aG91LXBpbS12cnJwLTAxIGFzIGlzDQo+ID4+IDIuIGFkb3B0IGRyYWZ0LXpo b3UtcGltLXZycnAtMDEgb25seSBhZnRlcg0KPiA+PiBkcmFmdC14dS1waW0tZHJwcmlvcml0eS1h dXRvLWFkanVzdG1lbnQgaXMgcmVmZXJlbmNlZC4NCj4gPj4gMy4gbWVyZ2UgdGhlIGRyYWZ0cw0K PiA+DQo+ID4gSSBwcmVmZXIgb3B0aW9uIDMuDQo+IA0KPiBJIGRvbid0IHRoaW5rIHdlIHNob3Vs ZCBzaW1wbHkgZG8gYSB2b3RlIGhlcmUsIHdlIG5lZWQgdG8gZ2V0IGFuDQo+IHVuZGVyc3RhbmRp bmcgb2Ygd2hhdCB0aGUgV0cgd2FudHMgYW5kIHNlZSBpZiB3ZSBoYXZlIGEgcm91Z2gNCj4gY29u c2Vuc3VzLiBJIHRoaW5rIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgcGVvcGxlIHJlc3BvbmRpbmcg Y291bGQNCj4gc3RhdGUgd2h5IHRoZXkgYmVsaWV2ZSBzbywgdGhpcyBtYXkgbGVhZCB0byBzb21l IHVzZWZ1bCBkaXNjdXNzaW9uDQo+IGFuZCBoZWxwIHBlb3BsZSBtYWtlIHVwIHRoZWlyIG1pbmQu DQoNCkFsdGhvdWdoIGRyYWZ0LXpob3UtcGltLXZycnAgYXR0ZW1wdHMgdG8gYWRkcmVzcyB0aGUg dHJhbnNpdCBuZXR3b3JrIHNjZW5hcmlvIGFkZGl0aW9uYWxseSB3aGVyZSBWUlJQIGlzIGVuYWJs ZWQsIGJ1dCBJR1AgaXMgZGlzYWJsZWQsIHRoZXJlIGlzIG9uZSBtYWpvciBvdmVybGFwIGJldHdl ZW4gdGhlc2UgdHdvIGRyYWZ0czogdG8gbWFrZSB0aGUgUElNIGxhc3QtaG9wL2xhc3QtaG9wIERS IGFuZCB0aGUgVlJSUCBtYXN0ZXIgcnVuIG9uIHRoZSBzYW1lIHJvdXRlci4gDQoNCj4gQXMgZm9y IG1lcmdpbmcsIHdlIG5lZWQgdG8gc2VlIGlmIHRoZSBXRyBpcyBpbnRlcmVzdGVkIGluIHRoZSBj b250ZW50DQo+IG9mIGJvdGggdGhlIHR3byBkcmFmdHMsIGFuZCBjb25zaWRlciB3aGV0aGVyIG1l cmdpbmcgdGhlbSBtYWtlcyBzZW5zZS4NCj4gDQo+IFdlIGRpZCBoYXZlIHNvbWUgc3VwcG9ydCBm b3IgYWRvcHRpbmcgZHJhZnQtemhvdS1waW0tdnJycC0wMSBpbiB0aGUNCj4gbGFzdCBtZWV0aW5n LCB3aGlsZSBkcmFmdC14dS1waW0tZHJwcmlvcml0eS1hdXRvLWFkanVzdG1lbnQgd2FzDQo+IGRp c2N1c3NlZCBhIGZldyB5ZWFycyBhZ28sIGFuZCBwZW9wbGUgcHJvYmFibHkgbmVlZCB0byByZS1y ZWFkIGl0IGFuZA0KPiBzZWUgd2hhdCB0aGV5IHRoaW5rIG5vdy4NCg0KRm9yIHBlb3BsZSB0byBy ZS1yZWFkIGl0IGNvbnZlbmllbnRseSwgYSByZXZpc2lvbiBpcyBhdmFpbGFibGUgbm93IGF0IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXBpbS1kcnByaW9yaXR5LWF1dG8tYWRq dXN0bWVudC0wNA0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiBTdGlnDQo+IA0KPiA+IEJl c3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+PiBJbiBlaXRoZXIgY2FzZSB0aGUgYXV0 aG9ycyBzaG91bGQgcmV2aXZlIHRoZSBleHBpcmVkDQo+ID4+IGRyYWZ0LXh1LXBpbS1kcnByaW9y aXR5LWF1dG8tYWRqdXN0bWVudC0wMyBmb3IgY29uc2lkZXJhdGlvbiB3aXRoaW4NCj4gPj4gdGhl IHdnIGlycmVnYXJkbGVzcyBvZiB2cnJwLTAxIGFkb3B0aW9uIG91dGNvbWUuDQo+ID4+DQo+ID4+ IFdoYXQgc2F5IHllPw0KPiA+Pg0KPiA+PiBtaWtlDQo+ID4+DQo+ID4+IE9uIFRodSwgTWF5IDIz LCAyMDEzIGF0IDI6MDggQU0sIFByYXNoYW50IEpoaW5ncmFuIChwamhpbmdyYSkNCj4gPj4gPHBq aGluZ3JhQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+PiBIaSBNaWtlLA0KPiA+Pj4NCj4gPj4+IEkg YWdyZWUgd2l0aCBSYWppdiwgYm90aCBkcmFmdHMgYXJlIHRyeWluZyB0byBzb2x2ZSB0aGUgc2Ft ZSBpc3N1ZS4uLi50aGF0IHRvbw0KPiBpbg0KPiA+PiBhbG1vc3Qgc2ltaWxhciB3YXkuDQo+ID4+ Pg0KPiA+Pj4gLQ0KPiA+Pj4gUmVnYXJkcywNCj4gPj4+IFByYXNoYW50IEpoaW5ncmFuDQo+ID4+ PiBOT1NURyBUTUUgLSBTUCBXaS1GaQ0KPiA+Pj4NCj4gPj4+IGh0dHA6Ly93d3dpbi5jaXNjby5j b20vaW9zL3RlY2gvbW9iaWxlL3Byb3h5aXB2Ni8NCj4gPj4+IGh0dHA6Ly93d3dpbi5jaXNjby5j b20vaW9zL3RlY2gvYnJvYWRiYW5kDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBSYWppdiBBc2F0aSAocmFqaXZhKQ0KPiA+Pj4gU2Vu dDogVGh1cnNkYXksIE1heSAyMywgMjAxMyAzOjA2IEFNDQo+ID4+PiBUbzogTWlrZSBNY0JyaWRl OyBYdXhpYW9odTsgc2dhbmVzYW5AZXh0cmVtZW5ldHdvcmtzLmNvbTsgUHJhc2hhbnQNCj4gPj4g SmhpbmdyYW4gKHBqaGluZ3JhKTsgV2VpIFpob3UgKHdlaXpobzIpDQo+ID4+PiBDYzogU3RpZyBW ZW5hYXM7IHBpbUBpZXRmLm9yZw0KPiA+Pj4gU3ViamVjdDogUkU6IFtwaW1dIGNhbGwgZm9yIGFk b3B0aW9uOiBkcmFmdC16aG91LXBpbS12cnJwLTAxDQo+ID4+Pg0KPiA+Pj4gSGkgTWlrZSwNCj4g Pj4+DQo+ID4+PiBJdCBzZWVtcyB0aGF0IGJvdGggZHJhZnRzIHNlZW0gdG8gc29sdmUgbmVhcmx5 IHRoZSBzYW1lIHByb2JsZW0gKG11bHRpcGxlDQo+ID4+IHJvdXRlcnMgb24gdGhlIG11bHRpLWFj Y2VzcyBpbnRlcmZhY2UgYW5kIGV4aXN0ZW5jZSBvZiBmaXJzdC1ob3AgcmVkdW5kYW5jeQ0KPiA+ PiBwcm90b2NvbHMgZS5nLiBWUlJQKS4NCj4gPj4+DQo+ID4+PiBDaGVlcnMsDQo+ID4+PiBSYWpp dg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+ PiBGcm9tOiBNaWtlIE1jQnJpZGUgW21haWx0bzptbWNicmlkZTdAZ21haWwuY29tXQ0KPiA+Pj4+ IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDIyLCAyMDEzIDI6MTcgQU0NCj4gPj4+PiBUbzogWHV4aWFv aHU7IHNnYW5lc2FuQGV4dHJlbWVuZXR3b3Jrcy5jb207IFJhaml2IEFzYXRpIChyYWppdmEpOw0K PiA+Pj4+IFByYXNoYW50IEpoaW5ncmFuIChwamhpbmdyYSk7IFdlaSBaaG91ICh3ZWl6aG8yKQ0K PiA+Pj4+IENjOiBTdGlnIFZlbmFhczsgTWlrZSBNY0JyaWRlOyBwaW1AaWV0Zi5vcmcNCj4gPj4+ PiBTdWJqZWN0OiBSZTogW3BpbV0gY2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXpob3UtcGltLXZy cnAtMDENCj4gPj4+Pg0KPiA+Pj4+IEZvbGtzLA0KPiA+Pj4+DQo+ID4+Pj4gV2UgaGF2ZSB0aGlz IG5ldyBkcmFmdC16aG91LXBpbS12cnJwLTAxIHdoaWNoIHdlIGFyZSBhYm91dCB0byBhZG9wdA0K PiA+Pj4+IGludG8gdGhlIHBpbSB3Zy4gSXQgaGFzIGJlZW4gYnJvdWdodCB0byB0aGUgV0dzIGF0 dGVudGlvbiB0aGF0IHRoZXJlDQo+ID4+Pj4gaXMgYSBvbGRlciBkcmFmdCAoZHJhZnQteHUtcGlt LWRycHJpb3JpdHktYXV0by1hZGp1c3RtZW50LTAzKSB3aGljaA0KPiA+Pj4+IG1heSBoYXZlIHNv bWUgb3ZlcmxhcCB3aXRoIHRoZSBuZXcgb25lLiBUaGF0IG9sZGVyIGRyYWZ0IGRvZXMgY29udGFp bg0KPiA+Pj4+IGluZm9ybWF0aW9uIGFib3V0IFZSUlAgYXdhcmUgUElNIHdoaWNoIGlzIGF0dHJp YnV0ZWQgdG8gU3RpZyBpbiB0aGUNCj4gPj4+PiBhY2tub3dsZWRnZW1lbnRzLiBJZiB0aGUgZml2 ZSBvZiB5b3UgYXV0aG9ycyBmZWVsIHRoYXQgdGhlcmUgaXMgc29tZQ0KPiA+Pj4+IHZhbGlkaXR5 IHRoYXQgdGhlIG9sZGVyIGRyYWZ0IGNvbnRhaW5zIHNvbWUgaW5mb3JtYXRpb24gYmVpbmcgdXNl ZCBpbg0KPiA+Pj4+IHRoZSBuZXcgZHJhZnQsIHlvdSBtYXkgd2FudCB0byBhY2tub3dsZWRnZSB0 aGF0IGluIHRoZSByZWZlcmVuY2VzIG9yDQo+ID4+Pj4gYWNrbm93bGVkZ2VtZW50cy4gSXQgYXBw ZWFycyB0aGUgZHJhZnRzIGFyZSBkaXNzaW1pbGFyIGVub3VnaCB0byBub3QNCj4gPj4+PiBiZSBt ZXJnZWQgYnV0IEkgbWF5IGJlIHdyb25nLiBQbGVhc2Ugc2hhcmUgeW91ciBvcGluaW9ucyBvbiB0 aGlzIHNvIHdlDQo+ID4+Pj4gY2FuIGVzdGFibGlzaCBjb25zZW5zdXMgd2l0aGluIHRoZSBncm91 cCBhbmQgbW92ZSB0aGUgZG9jdW1lbnQgYWxvbmcuDQo+ID4+Pj4NCj4gPj4+PiBJZiB0aGUgYnJv YWRlciBXRyBwYXJ0aWNpcGFudHMgaGF2ZSBhbiBvcGluaW9uIG9uIHRoaXMgcGxlYXNlIHNwZWFr IHVwLg0KPiA+Pj4+DQo+ID4+Pj4gdGhhbmtzLA0KPiA+Pj4+IG1pa2UNCj4gPj4+Pg0KPiA+Pj4+ IE9uIFRodSwgTWF5IDksIDIwMTMgYXQgNzozMiBQTSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdl aS5jb20+DQo+IHdyb3RlOg0KPiA+Pj4+PiBIaSBhbGwsDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoaXMg ZHJhZnQgcmVtaW5kcyBtZSB0aGF0IHRoZXJlIGhhcyBiZWVuIGEgZHJhZnQNCj4gPj4+PiAoaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtcGltLWRycHJpb3JpdHktYXV0by1hZGp1 c3RtZW50LTAzDQo+ID4+Pj4gKSB0aHJlZSB5ZWFycyBiZWZvcmUgd2hpY2ggdXNlcyBhbG1vc3Qg dGhlIHNhbWUgdGVjaG5vbG9neSB0byBzYXZlDQo+ID4+Pj4gYWxtb3N0IHRoZSBzYW1lIHByb2Js ZW0uDQo+ID4+Pj4+DQo+ID4+Pj4+IFRoZSBmb2xsb3dpbmcgaXMgcXVvdGVkIGZyb20gdGhlIGFi b3ZlIGRyYWZ0Og0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgIkluIGZhY3QsIGlmIFZSUlAgaXMgcnVu IG9uIHRoZSBQSU0gcm91dGVycyBhbmQgdGhlIFZSUlAgaGFzDQo+IGVuYWJsZWQNCj4gPj4+Pj4g ICAgIHRoZSB1cHN0cmVhbSBsaW5rIHRyYWNraW5nIG1lY2hhbmlzbSwgdGhlIFBJTSBEUiBmYWls b3Zlcg0KPiA+PiBtZWNoYW5pc20NCj4gPj4+Pj4gICAgIGNvdWxkIGJlIGNvdXBsZWQgd2l0aCB0 aGUgVlJSUCBzbyBhcyB0byByZXVzZSB0aGUgdXBzdHJlYW0gbGluaw0KPiA+Pj4+PiAgICAgdHJh Y2tpbmcgbWVjaGFuaXNtIG9mIFZSUlAuIE9uZSBvcHRpb24gaXMgdG8gc3luY2hyb25pemUgdGhl IFBJTQ0KPiBEUg0KPiA+Pj4+PiAgICAgcHJpb3JpdHkgdmFsdWUgdG8gdGhlIFZSUlAgcHJpb3Jp dHkgdmFsdWUgYWx3YXlzLiBJbiB0aGlzIHdheSwgdGhlDQo+ID4+Pj4+ICAgICBQSU0gRFIgYW5k IHRoZSBWUlJQIG1hc3RlciB3aWxsIGFsd2F5cyBydW4gb24gYW4gaWRlbnRpY2FsIHJvdXRlcg0K PiBpZg0KPiA+Pj4+PiAgICAgdGhlIFZSUlAgUHJlZW1wdF9Nb2RlIGlzIHNldCB0byBUcnVlLiBB bm90aGVyIG9wdGlvbiBpcyB0byBtYWtlDQo+IHRoZQ0KPiA+Pj4+PiAgICAgUElNIERSIGFuZCB0 aGUgVlJSUCBtYXN0ZXIgcnVuIG9uIGFuIGlkZW50aWNhbCByb3V0ZXIgYW55d2F5DQo+IChpLmUu LA0KPiA+Pj4+PiAgICAgcmVnYXJkbGVzcyB3aGV0aGVyIG9yIG5vdCB0aGUgVlJSUCBQcmVlbXB0 X01vZGUgaXMgVHJ1ZSkuIFRvDQo+ID4+IGFjaGlldmUNCj4gPj4+Pj4gICAgIHRoaXMgZ29hbCwg dGhlIFBJTSBEUiBwcmlvcml0eSBvZiB0aGUgVlJSUCBtYXN0ZXIgcm91dGVyIFNIT1VMRA0KPiA+ Pj4+PiAgICAgYWx3YXlzIGJlIHNldCB0byBhIGhpZ2hlciBmaXhlZCB2YWx1ZSB0aGFuIHRoYXQg b2YgdGhlIFZSUlAgc2xhdmUNCj4gPj4+Pj4gICAgIHJvdXRlciBhdXRvbWF0aWNhbGx5LiINCj4g Pj4+Pj4NCj4gPj4+Pj4gQmVzdCByZWdhcmRzLA0KPiA+Pj4+PiBYaWFvaHUNCj4gPj4+Pj4NCj4g Pj4+Pj4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiA+Pj4+Pj4gt6K8/sjLOiBwaW0tYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnBpbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+ID4+Pj4gTWlrZQ0K PiA+Pj4+Pj4gTWNCcmlkZQ0KPiA+Pj4+Pj4gt6LLzcqxvOQ6IDIwMTPE6jXUwjEwyNUgMzo0OA0K PiA+Pj4+Pj4gytW8/sjLOiBwaW1AaWV0Zi5vcmcNCj4gPj4+Pj4+INb3zOI6IFtwaW1dIGNhbGwg Zm9yIGFkb3B0aW9uOiBkcmFmdC16aG91LXBpbS12cnJwLTAxDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g ZHJhZnQtemhvdS1waW0tdnJycC0wMSB3YXMgcHJlc2VudGVkIGluIG91ciBtb3N0IHJlY2VudCBw aW0gbWVldGluZw0KPiA+Pj4+Pj4gaW4gT3JsYW5kby4gNCBwZW9wbGUgd2VyZSBpbiBmYXZvciBv ZiBhZG9wdGluZyB0aGUgZHJhZnQuIFplcm8gYWdhaW5zdC4NCj4gPj4+Pj4+IFBsZWFzZSByZWFk IHRoZSBkcmFmdCAoaXRzIHNob3J0KSBhbmQgcHJvdmlkZSBhbiBvcGluaW9uIGVpdGhlciB3YXkN Cj4gPj4+Pj4+IGJ5IHRoZSBlbmQgb2YgbmV4dCBGcmlkYXkgdGhlIDE3dGguDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC16aG91LXBpbS12cnJwLTAxLnR4 dA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IHRoYW5rcywNCj4gPj4+Pj4+IG1pa2UNCj4gPj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+PiBw aW0gbWFpbGluZyBsaXN0DQo+ID4+Pj4+PiBwaW1AaWV0Zi5vcmcNCj4gPj4+Pj4+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGltDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwaW0gbWFpbGluZyBsaXN0DQo+IHBp bUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BpbQ0K From xuxiaohu@huawei.com Tue Jun 4 20:19:59 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2022121F942B for ; Tue, 4 Jun 2013 20:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.366 X-Spam-Level: X-Spam-Status: No, score=0.366 tagged_above=-999 required=5 tests=[AWL=2.422, BAYES_00=-2.599, CN_BODY_35=0.339, 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 b5ZJeNXsgQvk for ; Tue, 4 Jun 2013 20:19:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 20F4721F8FBE for ; Tue, 4 Jun 2013 20:19:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASC74019; Wed, 05 Jun 2013 03:19:51 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 5 Jun 2013 04:18:59 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 5 Jun 2013 04:19:48 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Wed, 5 Jun 2013 11:19:42 +0800 From: Xuxiaohu To: "Wei Zhou (weizho2)" , Mike McBride , "Prashant Jhingran (pjhingra)" Thread-Topic: [pim] call for adoption: draft-zhou-pim-vrrp-01 Thread-Index: AQHOXc1oyBNO9pOfGUaQq5QJP/JnZZkfHyaAgAdUqXA= Date: Wed, 5 Jun 2013 03:19:42 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C52EF@NKGEML512-MBS.china.huawei.com> References: <23EF39780ADBDE42806FAEE7B8578690183E5E6E@xmb-rcd-x05.cisco.com> In-Reply-To: <23EF39780ADBDE42806FAEE7B8578690183E5E6E@xmb-rcd-x05.cisco.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: "sganesan@extremenetworks.com" , "pim@ietf.org" Subject: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 03:19:59 -0000 SGkgV2VpLA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IFdlaSBaaG91ICh3ZWl6 aG8yKSBbbWFpbHRvOndlaXpobzJAY2lzY28uY29tXQ0KPiC3osvNyrG85DogMjAxM8TqNtTCMcjV IDI6NTYNCj4gytW8/sjLOiBNaWtlIE1jQnJpZGU7IFByYXNoYW50IEpoaW5ncmFuIChwamhpbmdy YSkNCj4gs63LzTogUmFqaXYgQXNhdGkgKHJhaml2YSk7IFh1eGlhb2h1OyBzZ2FuZXNhbkBleHRy ZW1lbmV0d29ya3MuY29tOyBTdGlnDQo+IFZlbmFhczsgcGltQGlldGYub3JnDQo+INb3zOI6IFJl OiBbcGltXSBjYWxsIGZvciBhZG9wdGlvbjogZHJhZnQtemhvdS1waW0tdnJycC0wMQ0KPiANCj4g SGksDQo+IA0KPiBUaGFuayB5b3UgYWxsIGZvciB0aGUgY29tbWVudHMgYW5kIHRob3VnaHRzLiBJ IGJlbGlldmUgdGhhdCB0aGUgb2xkIGRyYWZ0DQo+IGlzIGFib3V0IHVwc3RyZWFtIGxpbmsgZmFp bHVyZXMsIHdoaWNoIGlzIG5vdCB3aGF0IHRoZSBuZXcgZHJhZnQgaXMgYWJvdXQuDQo+IFRoZSBu ZXcgZHJhZnQgaXMgYWJvdXQgaG93IHRvIHN1cHBvcnQgUElNIGFuZCBWUlJQIGluIGdlbmVyYWwg aW5zdGVhZCBvZg0KPiBmb2N1c2luZyBvbiB0aGUgb2JqZWN0IGJlaW5nIHRyYWNrZWQuDQoNCklm IHlvdXIgZHJhZnQgaXMgaXJyZWxldmFudCB0byB1cHN0cmVhbSBsaW5rIGZhaWx1cmUgc2NlbmFy aW8sIHdoYXQncyB0aGUgbW90aXZhdGlvbiBmb3IgbWFraW5nIHRoZSBQSU0gRFIgYW5kIHRoZSBW UlJQIG1hc3RlciBhbHdheXMgcnVuIG9uIHRoZSBzYW1lIHJvdXRlcj8gSW4gb3RoZXIgd29yZHMs IHdoYXQncyB0aGUgcHJvYmxlbSB3aGVuIHRoZSBQSU0gRFIgZG9lc24ndCBydW4gb24gdGhlIFZS UlAgbWFzdGVyIHJvdXRlcj8gSXQgc2VlbXMgdGhhdCB0aGUgYmVsb3cgdGV4dCBxdW90ZWQgZnJv bSB5b3VyIGRyYWZ0IGRvZXNuJ3QgcmVhbGx5IHN0YXRlIHRoZSBGSU5BTCBwcm9ibGVtLiBJTUhP LCBpdCBkb2Vzbid0IG1hdHRlciB3aGV0aGVyIG9yIG5vdCB0aGUgbXVsdGljYXN0IHRyYWZmaWMg aXMgZm9yd2FyZGVkIGJ5IHRoZSBWUlJQIG1hc3RlciByb3V0ZXIuIEluIGFkZGl0aW9uLCAidG8g ZW5zdXJlIHRoYXQgdGhlIFBJTSBEUiBpcyBhbHdheXMgYWJsZSB0byBmb3J3YXJkIFBJTSBKb2lu L1BydW5lIG1lc3NhZ2UgdG93YXJkcyBSUCBvciBGSFIiLCBpdCBkb2Vzbid0IHJlcXVpcmUgdGhl IFBJTSBEUiBydW5zIG9uIHRoZSBWUlJQIG1hc3RlciByb3V0ZXIgZWl0aGVyLg0KDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQogICJQSU0gaGFzIG5vIGluaGVyZW50IHJlZHVuZGFu Y3kgY2FwYWJpbGl0aWVzIGFuZCBpdHMgb3BlcmF0aW9uIGlzDQogICBjb21wbGV0ZWx5IGluZGVw ZW5kZW50IG9mIFZSUlAgZ3JvdXAgc3RhdGVzLiAgQXMgYSByZXN1bHQsIElQDQogICBtdWx0aWNh c3QgdHJhZmZpYyBpcyBmb3J3YXJkZWQgbm90IG5lY2Vzc2FyaWx5IGJ5IHRoZSBzYW1lIGRldmlj ZSBhcw0KICAgaXMgZWxlY3RlZCBieSBWUlJQLiAgVGhlIFZSUlAgQXdhcmUgUElNIGZlYXR1cmUg cHJvdmlkZXMgY29uc2lzdGVudA0KICAgSVAgbXVsdGljYXN0IGZvcndhcmRpbmcgaW4gYSByZWR1 bmRhbnQgbmV0d29yayB3aXRoIHZpcnR1YWwgcm91dGluZw0KICAgZ3JvdXBzIGVuYWJsZWQuDQoN CiAgIEluIGEgbXVsdGktYWNjZXNzIHNlZ21lbnQgKHN1Y2ggYXMgTEFOKSwgUElNIGRlc2lnbmF0 ZWQgcm91dGVyIChEUikNCiAgIGVsZWN0aW9uIGlzIHVuYXdhcmUgb2YgdGhlIHJlZHVuZGFuY3kg Y29uZmlndXJhdGlvbiwgYW5kIHRoZSBlbGVjdGVkDQogICBEUiBhbmQgVlJSUCBtYXN0ZXIgcm91 dGVyIChNUikgbWF5IG5vdCBiZSB0aGUgc2FtZSByb3V0ZXIuICBJbiBvcmRlcg0KICAgdG8gZW5z dXJlIHRoYXQgdGhlIFBJTSBEUiBpcyBhbHdheXMgYWJsZSB0byBmb3J3YXJkIFBJTSBKb2luL1By dW5lDQogICBtZXNzYWdlIHRvd2FyZHMgUlAgb3IgRkhSLCB0aGUgVlJSUCBNUiBiZWNvbWVzIHRo ZSBQSU0gRFIgKGlmIHRoZXJlDQogICBpcyBvbmx5IG9uZSBWUlJQIGdyb3VwKS4uLi4iDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+ IElmIHRoZSBXRyB0aGluayB0aGUgdXBzdHJlYW0gbGluayBmYWlsdXJlIHNjZW5hcmlvIHNob3Vs ZCBiZSBkaXNjdXNzZWQgaW4NCj4gZGV0YWlsIGluIHRoZSBuZXcgZHJhZnQsIHRoZW4gSSdtIGNv bXBsZXRlbHkgZmluZSB3aXRoIG1lcmdpbmcuIE1vcmVvdmVyLA0KPiBpZiB0aGUgbmV3IGRyYWZ0 IGlzIGFkb3B0ZWQgaW4gaXRzIGN1cnJlbnQgc2hhcGUsIHRoZW4gdGhlIFdHIGNhbiBhbHdheXMN Cj4gZGVjaWRlIHRvIGluY2x1ZGUgdGhlIHVwc3RyZWFtIGxpbmsgZmFpbHVyZSBzY2VuYXJpbyBs YXRlci4NCj4gDQo+IFRoYW5rcywNCj4gV2VpDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gT24gNS8z MS8xMyAxMjowNiBBTSwgIk1pa2UgTWNCcmlkZSIgPG1tY2JyaWRlN0BnbWFpbC5jb20+IHdyb3Rl Og0KPiANCj4gPlRoYW5rIHlvdSBmb3IgdGhlIHJlc3BvbnNlcy4NCj4gPg0KPiA+U29tZSBmZWVs IHRoZSB0d28gZHJhZnRzIGFyZSBjb21wbGV0ZWx5IHVucmVsYXRlZCB3aGlsZSBvdGhlcnMgZmVl bA0KPiA+dGhleSBhcmUgY29tcGxldGVseSByZWxhdGVkLiBJbiBlaXRoZXIgY2FzZSwgYXJlIHlv dSwgd2hvIGZlZWwgdGhleQ0KPiA+YXJlIHJlbGF0ZWQsIHNheWluZyB5b3Ugb3Bwb3NlIHRoZSBh ZG9wdGlvbiBvZiBkcmFmdC16aG91LXBpbS12cnJwLTAxPw0KPiA+V2UgY2FuIGluZmVyIHRoYXQg aXMgdGhlIGNhc2UgYnV0IEkgaGF2ZW4ndCBoZWFyZCBleHBsaWNpdGx5IHN0YXRlZA0KPiA+b3Bw b3NpdGlvbiB0byBhZG9wdGlvbi4gV2Ugbm93IGhhdmUgc2V2ZXJhbCBjaG9pY2VzIGZvcg0KPiA+ ZHJhZnQtemhvdS1waW0tdnJycCwgbGV0IG1lIHRyeSBib2lsaW5nIGl0IGRvd24gdG8gMzoNCj4g Pg0KPiA+MS4gYWRvcHQgZHJhZnQtemhvdS1waW0tdnJycC0wMSBhcyBpcw0KPiA+Mi4gYWRvcHQg ZHJhZnQtemhvdS1waW0tdnJycC0wMSBvbmx5IGFmdGVyDQo+ID5kcmFmdC14dS1waW0tZHJwcmlv cml0eS1hdXRvLWFkanVzdG1lbnQgaXMgcmVmZXJlbmNlZC4NCj4gPjMuIG1lcmdlIHRoZSBkcmFm dHMNCj4gPg0KPiA+SW4gZWl0aGVyIGNhc2UgdGhlIGF1dGhvcnMgc2hvdWxkIHJldml2ZSB0aGUg ZXhwaXJlZA0KPiA+ZHJhZnQteHUtcGltLWRycHJpb3JpdHktYXV0by1hZGp1c3RtZW50LTAzIGZv ciBjb25zaWRlcmF0aW9uIHdpdGhpbg0KPiA+dGhlIHdnIGlycmVnYXJkbGVzcyBvZiB2cnJwLTAx IGFkb3B0aW9uIG91dGNvbWUuDQo+ID4NCj4gPldoYXQgc2F5IHllPw0KPiA+DQo+ID5taWtlDQo+ ID4NCj4gPk9uIFRodSwgTWF5IDIzLCAyMDEzIGF0IDI6MDggQU0sIFByYXNoYW50IEpoaW5ncmFu IChwamhpbmdyYSkNCj4gPjxwamhpbmdyYUBjaXNjby5jb20+IHdyb3RlOg0KPiA+PiBIaSBNaWtl LA0KPiA+Pg0KPiA+PiBJIGFncmVlIHdpdGggUmFqaXYsIGJvdGggZHJhZnRzIGFyZSB0cnlpbmcg dG8gc29sdmUgdGhlIHNhbWUNCj4gPj5pc3N1ZS4uLi50aGF0IHRvbyBpbiBhbG1vc3Qgc2ltaWxh ciB3YXkuDQo+ID4+DQo+ID4+IC0NCj4gPj4gUmVnYXJkcywNCj4gPj4gUHJhc2hhbnQgSmhpbmdy YW4NCj4gPj4gTk9TVEcgVE1FIC0gU1AgV2ktRmkNCj4gPj4NCj4gPj4gaHR0cDovL3d3d2luLmNp c2NvLmNvbS9pb3MvdGVjaC9tb2JpbGUvcHJveHlpcHY2Lw0KPiA+PiBodHRwOi8vd3d3aW4uY2lz Y28uY29tL2lvcy90ZWNoL2Jyb2FkYmFuZA0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBSYWppdiBBc2F0aSAocmFqaXZhKQ0KPiA+PiBTZW50 OiBUaHVyc2RheSwgTWF5IDIzLCAyMDEzIDM6MDYgQU0NCj4gPj4gVG86IE1pa2UgTWNCcmlkZTsg WHV4aWFvaHU7IHNnYW5lc2FuQGV4dHJlbWVuZXR3b3Jrcy5jb207IFByYXNoYW50DQo+ID4+Smhp bmdyYW4gKHBqaGluZ3JhKTsgV2VpIFpob3UgKHdlaXpobzIpDQo+ID4+IENjOiBTdGlnIFZlbmFh czsgcGltQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJFOiBbcGltXSBjYWxsIGZvciBhZG9wdGlv bjogZHJhZnQtemhvdS1waW0tdnJycC0wMQ0KPiA+Pg0KPiA+PiBIaSBNaWtlLA0KPiA+Pg0KPiA+ PiBJdCBzZWVtcyB0aGF0IGJvdGggZHJhZnRzIHNlZW0gdG8gc29sdmUgbmVhcmx5IHRoZSBzYW1l IHByb2JsZW0NCj4gPj4obXVsdGlwbGUgcm91dGVycyBvbiB0aGUgbXVsdGktYWNjZXNzIGludGVy ZmFjZSBhbmQgZXhpc3RlbmNlIG9mDQo+ID4+Zmlyc3QtaG9wIHJlZHVuZGFuY3kgcHJvdG9jb2xz IGUuZy4gVlJSUCkuDQo+ID4+DQo+ID4+IENoZWVycywNCj4gPj4gUmFqaXYNCj4gPj4NCj4gPj4N Cj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBGcm9tOiBNaWtlIE1jQnJp ZGUgW21haWx0bzptbWNicmlkZTdAZ21haWwuY29tXQ0KPiA+Pj4gU2VudDogV2VkbmVzZGF5LCBN YXkgMjIsIDIwMTMgMjoxNyBBTQ0KPiA+Pj4gVG86IFh1eGlhb2h1OyBzZ2FuZXNhbkBleHRyZW1l bmV0d29ya3MuY29tOyBSYWppdiBBc2F0aSAocmFqaXZhKTsNCj4gPj4+IFByYXNoYW50IEpoaW5n cmFuIChwamhpbmdyYSk7IFdlaSBaaG91ICh3ZWl6aG8yKQ0KPiA+Pj4gQ2M6IFN0aWcgVmVuYWFz OyBNaWtlIE1jQnJpZGU7IHBpbUBpZXRmLm9yZw0KPiA+Pj4gU3ViamVjdDogUmU6IFtwaW1dIGNh bGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16aG91LXBpbS12cnJwLTAxDQo+ID4+Pg0KPiA+Pj4gRm9s a3MsDQo+ID4+Pg0KPiA+Pj4gV2UgaGF2ZSB0aGlzIG5ldyBkcmFmdC16aG91LXBpbS12cnJwLTAx IHdoaWNoIHdlIGFyZSBhYm91dCB0byBhZG9wdA0KPiA+Pj4gaW50byB0aGUgcGltIHdnLiBJdCBo YXMgYmVlbiBicm91Z2h0IHRvIHRoZSBXR3MgYXR0ZW50aW9uIHRoYXQgdGhlcmUNCj4gPj4+IGlz IGEgb2xkZXIgZHJhZnQgKGRyYWZ0LXh1LXBpbS1kcnByaW9yaXR5LWF1dG8tYWRqdXN0bWVudC0w Mykgd2hpY2gNCj4gPj4+IG1heSBoYXZlIHNvbWUgb3ZlcmxhcCB3aXRoIHRoZSBuZXcgb25lLiBU aGF0IG9sZGVyIGRyYWZ0IGRvZXMgY29udGFpbg0KPiA+Pj4gaW5mb3JtYXRpb24gYWJvdXQgVlJS UCBhd2FyZSBQSU0gd2hpY2ggaXMgYXR0cmlidXRlZCB0byBTdGlnIGluIHRoZQ0KPiA+Pj4gYWNr bm93bGVkZ2VtZW50cy4gSWYgdGhlIGZpdmUgb2YgeW91IGF1dGhvcnMgZmVlbCB0aGF0IHRoZXJl IGlzIHNvbWUNCj4gPj4+IHZhbGlkaXR5IHRoYXQgdGhlIG9sZGVyIGRyYWZ0IGNvbnRhaW5zIHNv bWUgaW5mb3JtYXRpb24gYmVpbmcgdXNlZCBpbg0KPiA+Pj4gdGhlIG5ldyBkcmFmdCwgeW91IG1h eSB3YW50IHRvIGFja25vd2xlZGdlIHRoYXQgaW4gdGhlIHJlZmVyZW5jZXMgb3INCj4gPj4+IGFj a25vd2xlZGdlbWVudHMuIEl0IGFwcGVhcnMgdGhlIGRyYWZ0cyBhcmUgZGlzc2ltaWxhciBlbm91 Z2ggdG8gbm90DQo+ID4+PiBiZSBtZXJnZWQgYnV0IEkgbWF5IGJlIHdyb25nLiBQbGVhc2Ugc2hh cmUgeW91ciBvcGluaW9ucyBvbiB0aGlzIHNvIHdlDQo+ID4+PiBjYW4gZXN0YWJsaXNoIGNvbnNl bnN1cyB3aXRoaW4gdGhlIGdyb3VwIGFuZCBtb3ZlIHRoZSBkb2N1bWVudCBhbG9uZy4NCj4gPj4+ DQo+ID4+PiBJZiB0aGUgYnJvYWRlciBXRyBwYXJ0aWNpcGFudHMgaGF2ZSBhbiBvcGluaW9uIG9u IHRoaXMgcGxlYXNlIHNwZWFrIHVwLg0KPiA+Pj4NCj4gPj4+IHRoYW5rcywNCj4gPj4+IG1pa2UN Cj4gPj4+DQo+ID4+PiBPbiBUaHUsIE1heSA5LCAyMDEzIGF0IDc6MzIgUE0sIFh1eGlhb2h1IDx4 dXhpYW9odUBodWF3ZWkuY29tPg0KPiB3cm90ZToNCj4gPj4+ID4gSGkgYWxsLA0KPiA+Pj4gPg0K PiA+Pj4gPiBUaGlzIGRyYWZ0IHJlbWluZHMgbWUgdGhhdCB0aGVyZSBoYXMgYmVlbiBhIGRyYWZ0 DQo+ID4+PiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtcGltLWRycHJpb3Jp dHktYXV0by1hZGp1c3RtZW50LTAzDQo+ID4+PiApIHRocmVlIHllYXJzIGJlZm9yZSB3aGljaCB1 c2VzIGFsbW9zdCB0aGUgc2FtZSB0ZWNobm9sb2d5IHRvIHNhdmUNCj4gPj4+IGFsbW9zdCB0aGUg c2FtZSBwcm9ibGVtLg0KPiA+Pj4gPg0KPiA+Pj4gPiBUaGUgZm9sbG93aW5nIGlzIHF1b3RlZCBm cm9tIHRoZSBhYm92ZSBkcmFmdDoNCj4gPj4+ID4NCj4gPj4+ID4gICAgIkluIGZhY3QsIGlmIFZS UlAgaXMgcnVuIG9uIHRoZSBQSU0gcm91dGVycyBhbmQgdGhlIFZSUlAgaGFzDQo+ID4+PmVuYWJs ZWQNCj4gPj4+ID4gICAgdGhlIHVwc3RyZWFtIGxpbmsgdHJhY2tpbmcgbWVjaGFuaXNtLCB0aGUg UElNIERSIGZhaWxvdmVyDQo+ID4+Pm1lY2hhbmlzbQ0KPiA+Pj4gPiAgICBjb3VsZCBiZSBjb3Vw bGVkIHdpdGggdGhlIFZSUlAgc28gYXMgdG8gcmV1c2UgdGhlIHVwc3RyZWFtIGxpbmsNCj4gPj4+ ID4gICAgdHJhY2tpbmcgbWVjaGFuaXNtIG9mIFZSUlAuIE9uZSBvcHRpb24gaXMgdG8gc3luY2hy b25pemUgdGhlIFBJTQ0KPiA+Pj5EUg0KPiA+Pj4gPiAgICBwcmlvcml0eSB2YWx1ZSB0byB0aGUg VlJSUCBwcmlvcml0eSB2YWx1ZSBhbHdheXMuIEluIHRoaXMgd2F5LCB0aGUNCj4gPj4+ID4gICAg UElNIERSIGFuZCB0aGUgVlJSUCBtYXN0ZXIgd2lsbCBhbHdheXMgcnVuIG9uIGFuIGlkZW50aWNh bCByb3V0ZXINCj4gPj4+aWYNCj4gPj4+ID4gICAgdGhlIFZSUlAgUHJlZW1wdF9Nb2RlIGlzIHNl dCB0byBUcnVlLiBBbm90aGVyIG9wdGlvbiBpcyB0byBtYWtlDQo+ID4+PnRoZQ0KPiA+Pj4gPiAg ICBQSU0gRFIgYW5kIHRoZSBWUlJQIG1hc3RlciBydW4gb24gYW4gaWRlbnRpY2FsIHJvdXRlciBh bnl3YXkNCj4gPj4+KGkuZS4sDQo+ID4+PiA+ICAgIHJlZ2FyZGxlc3Mgd2hldGhlciBvciBub3Qg dGhlIFZSUlAgUHJlZW1wdF9Nb2RlIGlzIFRydWUpLiBUbw0KPiA+Pj5hY2hpZXZlDQo+ID4+PiA+ ICAgIHRoaXMgZ29hbCwgdGhlIFBJTSBEUiBwcmlvcml0eSBvZiB0aGUgVlJSUCBtYXN0ZXIgcm91 dGVyIFNIT1VMRA0KPiA+Pj4gPiAgICBhbHdheXMgYmUgc2V0IHRvIGEgaGlnaGVyIGZpeGVkIHZh bHVlIHRoYW4gdGhhdCBvZiB0aGUgVlJSUCBzbGF2ZQ0KPiA+Pj4gPiAgICByb3V0ZXIgYXV0b21h dGljYWxseS4iDQo+ID4+PiA+DQo+ID4+PiA+IEJlc3QgcmVnYXJkcywNCj4gPj4+ID4gWGlhb2h1 DQo+ID4+PiA+DQo+ID4+PiA+PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPj4+ID4+ILeivP7Iyzog cGltLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwaW0tYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0K PiA+Pj4gTWlrZQ0KPiA+Pj4gPj4gTWNCcmlkZQ0KPiA+Pj4gPj4gt6LLzcqxvOQ6IDIwMTPE6jXU wjEwyNUgMzo0OA0KPiA+Pj4gPj4gytW8/sjLOiBwaW1AaWV0Zi5vcmcNCj4gPj4+ID4+INb3zOI6 IFtwaW1dIGNhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16aG91LXBpbS12cnJwLTAxDQo+ID4+PiA+ Pg0KPiA+Pj4gPj4gZHJhZnQtemhvdS1waW0tdnJycC0wMSB3YXMgcHJlc2VudGVkIGluIG91ciBt b3N0IHJlY2VudCBwaW0gbWVldGluZw0KPiA+Pj4gPj4gaW4gT3JsYW5kby4gNCBwZW9wbGUgd2Vy ZSBpbiBmYXZvciBvZiBhZG9wdGluZyB0aGUgZHJhZnQuIFplcm8NCj4gPj4+YWdhaW5zdC4NCj4g Pj4+ID4+IFBsZWFzZSByZWFkIHRoZSBkcmFmdCAoaXRzIHNob3J0KSBhbmQgcHJvdmlkZSBhbiBv cGluaW9uIGVpdGhlciB3YXkNCj4gPj4+ID4+IGJ5IHRoZSBlbmQgb2YgbmV4dCBGcmlkYXkgdGhl IDE3dGguDQo+ID4+PiA+Pg0KPiA+Pj4gPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC16 aG91LXBpbS12cnJwLTAxLnR4dA0KPiA+Pj4gPj4NCj4gPj4+ID4+IHRoYW5rcywNCj4gPj4+ID4+ IG1pa2UNCj4gPj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4+PiA+PiBwaW0gbWFpbGluZyBsaXN0DQo+ID4+PiA+PiBwaW1AaWV0Zi5vcmcN Cj4gPj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGltDQoNCg== From xuxiaohu@huawei.com Tue Jun 4 20:55:49 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C2021F9AD6 for ; Tue, 4 Jun 2013 20:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[AWL=1.615, BAYES_00=-2.599, CN_BODY_35=0.339, 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 Qkwcwq9iwWNA for ; Tue, 4 Jun 2013 20:55:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 23AEF21F8E37 for ; Tue, 4 Jun 2013 20:55:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATO76444; Wed, 05 Jun 2013 03:55:42 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 5 Jun 2013 04:54:53 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 5 Jun 2013 04:55:39 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Wed, 5 Jun 2013 11:55:35 +0800 From: Xuxiaohu To: "Wei Zhou (weizho2)" , "Prashant Jhingran (pjhingra)" , "Rajiv Asati (rajiva)" , Mike McBride , "sganesan@extremenetworks.com" Thread-Topic: [pim] call for adoption: draft-zhou-pim-vrrp-01 Thread-Index: AQHOVrP2yBNO9pOfGUaQq5QJP/JnZZkRNU+AgADBXYCAAND0gIAAyGuAgAcFaICAC/VMkA== Date: Wed, 5 Jun 2013 03:55:33 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C5336@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C2A89@NKGEML512-MBS.china.huawei.com> <23EF39780ADBDE42806FAEE7B8578690183E54D2@xmb-rcd-x05.cisco.com> In-Reply-To: <23EF39780ADBDE42806FAEE7B8578690183E54D2@xmb-rcd-x05.cisco.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: "pim@ietf.org" Subject: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 03:55:49 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogV2VpIFpob3UgKHdlaXpobzIpIFtt YWlsdG86d2VpemhvMkBjaXNjby5jb21dDQo+ILeiy83KsbzkOiAyMDEzxOo11MIyOcjVIDQ6NDcN Cj4gytW8/sjLOiBYdXhpYW9odTsgUHJhc2hhbnQgSmhpbmdyYW4gKHBqaGluZ3JhKTsgUmFqaXYg QXNhdGkgKHJhaml2YSk7IE1pa2UNCj4gTWNCcmlkZTsgc2dhbmVzYW5AZXh0cmVtZW5ldHdvcmtz LmNvbQ0KPiCzrcvNOiBTdGlnIFZlbmFhczsgcGltQGlldGYub3JnDQo+INb3zOI6IFJlOiBbcGlt XSBjYWxsIGZvciBhZG9wdGlvbjogZHJhZnQtemhvdS1waW0tdnJycC0wMQ0KPiANCj4gSGksIFhp YW9odQ0KPiANCj4gVGhlIG1vdGl2YXRlIGZvciBlbmFibGluZyBWUlJQLCByYXRoZXIgdGhhbiBJ R1AgaW4gdGhlIHJlYWwgdHJhbnNpdA0KPiBuZXR3b3JrIGlzIHRvIGFkZHJlc3MgdGhlIGZvbGxv d2luZyBzY2VuYXJpb3M6IDEpIHR3byBQSU0gZG9tYWlucyBpbg0KPiBkaWZmZXJlbnQgc3VibmV0 cyAocG9zc2libHkgd2l0aCBmaXJld2FsbCBpbiBiZXR3ZWVuKSwgDQoNClNpbmNlIHlvdSBzYWlk ICJkaWZmZXJlbnQgc3VibmV0cyIsIHRoZSBmaXJld2FsbCB3b3VsZCBiZSBhIEwzIGRldmljZSwg cmlnaHQ/IElmIHNvLCB0aGUgZmlyZXdhbGwgY291bGQgcnVuIElHUCB3aXRoIHRoZSB0d28gdXBz dHJlYW0gUElNIHJvdXRlcnMuIA0KDQo+IG9yIDIpIGluIGEgc2luZ2xlDQo+IHN1Ym5ldCB3aGVy ZSB0aGUgcHJvdmlkZXIgZG9lcyBub3Qgd2lzaCB0byBydW4gYSByb3V0aW5nIHByb3RvY29sIGJl dHdlZW4NCj4gdGhlIHByb3ZpZGVyJ3MgbmV0d29yayBhbmQgY3VzdG9tZXIgbmV0d29ya3MuDQoN CkluIHRoaXMgY2FzZSwgaXQgZG9lc24ndCByZXF1aXJlIHJ1bm5pbmcgSUdQIGJldHdlZW4gdGhl IHByb3ZpZGVyIG5ldHdvcmsgYW5kIHRoZSBjdXN0b21lciBuZXR3b3JrLiBPbiB0aGUgY29udHJh cnksIGl0IG9ubHkgbmVlZHMgdGhlIHR3byBQSU0gcm91dGVycyBpbiB0aGUgcHJvdmlkZXIgbmV0 d29yayB0byBydW4gSUdQIGluIGFuIGF1dGhlbnRpY2F0aW9uIG1vZGUuDQoNCj4gVGhhbmtzLA0K PiBXZWkNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBPbiA1LzIzLzEzIDY6NTYgUE0sICJYdXhpYW9o dSIgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gPkhpLA0KPiA+DQo+ID4+IC0t LS0t08q8/tStvP4tLS0tLQ0KPiA+PiC3orz+yMs6IFdlaSBaaG91ICh3ZWl6aG8yKSBbbWFpbHRv OndlaXpobzJAY2lzY28uY29tXQ0KPiA+PiC3osvNyrG85DogMjAxM8TqNdTCMjTI1SA1OjM2DQo+ ID4+IMrVvP7IyzogUHJhc2hhbnQgSmhpbmdyYW4gKHBqaGluZ3JhKTsgUmFqaXYgQXNhdGkgKHJh aml2YSk7IE1pa2UgTWNCcmlkZTsNCj4gPj4gWHV4aWFvaHU7IHNnYW5lc2FuQGV4dHJlbWVuZXR3 b3Jrcy5jb20NCj4gPj4gs63LzTogU3RpZyBWZW5hYXM7IHBpbUBpZXRmLm9yZw0KPiA+PiDW98zi OiBSZTogW3BpbV0gY2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXpob3UtcGltLXZycnAtMDENCj4g Pj4NCj4gPj4gSGksDQo+ID4+DQo+ID4+IFRoYW5rIHlvdSBhbGwgZm9yIHByb3ZpZGluZyBjb21t ZW50cyBhbmQgdGhlIGluZm9ybWF0aW9uIG9uDQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXh1LXBpbS1kcnByaW9yaXR5LWF1dG8tYWRqdXN0bWVudC0wMy4NCj4gPj4NCj4g Pj4gSSBqdXN0IHJlYWQgdGhyb3VnaCB0aGUgZHJhZnQgcHJvcG9zZWQgYnkgeGlhb2h1IGFzIEkg d2FzIG5vdCBhd2FyZSBvZg0KPiA+PiB0aGlzIGRyYWZ0IHVudGlsIHhpYW9odSBraW5kbHkgbWVu dGlvbmVkIGluIHRoZSBtYWlsIGxpc3QuIEFmdGVyDQo+ID4+Y2FyZWZ1bGx5DQo+ID4+IGNvbXBh cmluZyB0aGUgdHdvIGRyYWZ0cywgbGV0IG1lIHRyeSBleHBsYWluIHRoZSBkaWZmZXJlbmNlcyBi ZXR3ZWVuDQo+ID4+dGhlbQ0KPiA+PiAocmVmZXJyZWQgYXMgZHJhZnQteHUtZHItYWRqIGFuZCBk cmFmdC16aG91LXBpbS12cnJwKToNCj4gPj4NCj4gPj4gMS4gVGhlIG9yaWdpbmFsIHByb2JsZW1z IHRoYXQgdHdvIGRyYWZ0cyB0cnkgdG8gc29sdmUgbWlnaHQgbG9vayBzaW1pbGFyDQo+ID4+IGJ1 dCB0aGV5IGFyZSBhY3R1YWxseSBxdWl0ZSBkaWZmZXJlbnQgaW4gdGhlIGZvbGxvd2luZyB3YXk6 DQo+ID4+IGRyYWZ0LXh1LWRyLWFkaiB0YXJnZXRzIHRoZSBQSU0gRFIgYXV0by1hZGp1c3RtZW50 IGJhc2VkIG9uIHVwc3RyZWFtDQo+ID4+bGluaw0KPiA+PiB0cmFja2luZywgd2hpbGUgdGhlIGlk ZWEgaW4gZHJhZnQtemhvdS1waW0tdnJycCBpcyB0byBwcm92aWRlIGEgY29tcGxldGUNCj4gPj4g c29sdXRpb24gdG8gZW5hYmxlIG11bHRpY2FzdCB0byBpbnRlcm9wZXJhdGUgd2l0aCBmaXJzdCBo b3AgcmVkdW5kYW5jeQ0KPiA+PiBwcm90b2NvbCBpbiByZXNwb25zZSB0byBhbnkgaW50ZXJlc3Rl ZCBldmVudHM6IE1hc3RlciByb3V0ZXJzIGdvZXMgZG93biwNCj4gPj4gdXBzdHJlYW0gbGluayB1 cC9kb3duLCBiYW5kd2lkdGggY2hhbmdlIGFuZCBvdGhlciBsb2dpY2FsIG9iamVjdHMgdGhhdA0K PiA+PiBWUlJQIGNvdWxkIHRyYWNrLg0KPiA+DQo+ID5BcyBpdCBzYWlkIGluIHNlY3Rpb24gMiBv ZiBkcmFmdC14dS1kci1hZGosDQo+ID4NCj4gPiIgIEluIGZhY3QsIGlmIFZSUlAgaXMgcnVuIG9u IHRoZSBQSU0gcm91dGVycyBhbmQgdGhlIFZSUlAgaGFzIGVuYWJsZWQNCj4gPiAgIHRoZSB1cHN0 cmVhbSBsaW5rIHRyYWNraW5nIG1lY2hhbmlzbSwgdGhlIFBJTSBEUiBmYWlsb3ZlciBtZWNoYW5p c20NCj4gPiAgIGNvdWxkIGJlIGNvdXBsZWQgd2l0aCB0aGUgVlJSUCBzbyBhcyB0byByZXVzZSB0 aGUgdXBzdHJlYW0gbGluaw0KPiA+ICAgdHJhY2tpbmcgbWVjaGFuaXNtIG9mIFZSUlAuIE9uZSBv cHRpb24gaXMgdG8gc3luY2hyb25pemUgdGhlIFBJTSBEUg0KPiA+ICAgcHJpb3JpdHkgdmFsdWUg dG8gdGhlIFZSUlAgcHJpb3JpdHkgdmFsdWUgYWx3YXlzLiBJbiB0aGlzIHdheSwgdGhlDQo+ID4g ICBQSU0gRFIgYW5kIHRoZSBWUlJQIG1hc3RlciB3aWxsIGFsd2F5cyBydW4gb24gYW4gaWRlbnRp Y2FsIHJvdXRlciBpZg0KPiA+ICAgdGhlIFZSUlAgUHJlZW1wdF9Nb2RlIGlzIHNldCB0byBUcnVl LiBBbm90aGVyIG9wdGlvbiBpcyB0byBtYWtlIHRoZQ0KPiA+ICAgUElNIERSIGFuZCB0aGUgVlJS UCBtYXN0ZXIgcnVuIG9uIGFuIGlkZW50aWNhbCByb3V0ZXIgYW55d2F5IChpLmUuLA0KPiA+ICAg cmVnYXJkbGVzcyB3aGV0aGVyIG9yIG5vdCB0aGUgVlJSUCBQcmVlbXB0X01vZGUgaXMgVHJ1ZSku IFRvIGFjaGlldmUNCj4gPiAgIHRoaXMgZ29hbCwgdGhlIFBJTSBEUiBwcmlvcml0eSBvZiB0aGUg VlJSUCBtYXN0ZXIgcm91dGVyIFNIT1VMRA0KPiA+ICAgYWx3YXlzIGJlIHNldCB0byBhIGhpZ2hl ciBmaXhlZCB2YWx1ZSB0aGFuIHRoYXQgb2YgdGhlIFZSUlAgc2xhdmUNCj4gPiAgIHJvdXRlciBh dXRvbWF0aWNhbGx5Lg0KPiA+Ig0KPiA+SW4gYSB3b3JkLCB0aGUgUElNIERSIGFuZCB0aGUgVlJS UCBtYXN0ZXIgY291bGQgYWN0dWFsbHkgcnVuIG9uIHRoZSBzYW1lDQo+ID5yb3V0ZXIgbm8gbWF0 dGVyIHdoYXRldmVyIGZhY3RvciB0cmlnZ2VycyB0aGUgVlJSUCBzd2l0Y2hvdmVyLCBhcyBwZXIg dGhlDQo+ID5hYm92ZSBkZXNjcmlwdGlvbi4NCj4gPg0KPiA+PiAyLiBUaGUgc29sdXRpb24gcHJv cG9zZWQgaW4gZHJhZnQtemhvdS1waW0tdnJycCBpcyBkZXNpZ25lZCBhcyBhDQo+ID4+Y29tcGxl dGUNCj4gPj4gbXVsdGljYXN0IGZhaWxvdmVyIG1lY2hhbmlzbTogaW4gYWRkaXRpb24gdG8gRFIg cHJpb3JpdHkgYWRqdXN0bWVudCwgdGhlDQo+ID4+IG5ldyBkcmFmdCBhZGRyZXNzZXMgb3RoZXIg Y3JpdGljYWwgcHJvYmxlbXMgaW4gcHJvdmlkaW5nIG11bHRpY2FzdA0KPiA+PiByZWR1bmRhbmN5 LCBpbmNsdWRpbmcgQXNzZXJ0IG1ldHJpYyBhZGp1c3RtZW50LCBERiBlbGVjdGlvbiBmb3IgQmlE aXINCj4gPj4gZ3JvdXAgYW5kIHRyYWNraW5nIG11bHRpcGxlIFZSUlAgZ3JvdXBzLg0KPiA+DQo+ ID4NCj4gPj4gMy4gSW4gYWRkaXRpb24gdG8gbGFzdC1ob3AgYW5kIGZpcnN0LWhvcCBzY2VuYXJp bywgdGhlIG5ldyBkcmFmdA0KPiA+PmFkZHJlc3Nlcw0KPiA+PiAgdHJhbnNpdCBuZXR3b3JrIHNj ZW5hcmlvIHRvIG1ha2UgTWFzdGVyIHJvdXRlciBwcm9jZXNzIFBJTSBKL1AgZm9yIHRoZQ0KPiA+ PiB2aXJ0dWFsIGFkZHJlc3MsIGFuZCBob3cgdG8gbWFpbnRhaW4gb3IgcmVidWlsZCBKL1Agc3Rh dGUgd2hlbg0KPiA+PnN3aXRjaGluZy4NCj4gPg0KPiA+Q291bGQgeW91IHBsZWFzZSBleHBsYWlu IHRoZSBtb3RpdmF0aW9uIGZvciBlbmFibGluZyBWUlJQLCByYXRoZXIgdGhhbg0KPiA+SUdQIGlu IHRoZSByZWFsIHRyYW5zaXQgbmV0d29yayBzY2VuYXJpbz8NCj4gPg0KPiA+PiBUaGUgb25seSBz aW1pbGFyaXR5IGJldHdlZW4gdGhlIG9sZCBhbmQgbmV3IGRyYWZ0cyBpcyB0byBtYWtlIG1hc3Rl cg0KPiA+PiByb3V0ZXIgdGhlIERSLCB3aGljaCBpcyBvYnZpb3VzIHdheSB0byBtYWtlIGRlc2ly ZWQgcm91dGVyIERSLg0KPiA+DQo+ID5ZZXMsIHRoaXMgaXMgdGhlIG1ham9yIG1vdGl2YXRpb24g Zm9yIGJvdGggZHJhZnRzIGluIG15IHVuZGVyc3RhbmRpbmcuDQo+ID4NCj4gPkJlc3QgcmVnYXJk cywNCj4gPlhpYW9odQ0KPiA+DQo+ID4+IFRoYW5rcywNCj4gPj4gV2VpDQo+ID4+DQo+ID4+DQo+ ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIDUvMjMvMTMgMjowOCBBTSwgIlByYXNoYW50 IEpoaW5ncmFuIChwamhpbmdyYSkiIDxwamhpbmdyYUBjaXNjby5jb20+DQo+ID4+IHdyb3RlOg0K PiA+Pg0KPiA+PiA+SGkgTWlrZSwNCj4gPj4gPg0KPiA+PiA+SSBhZ3JlZSB3aXRoIFJhaml2LCBi b3RoIGRyYWZ0cyBhcmUgdHJ5aW5nIHRvIHNvbHZlIHRoZSBzYW1lDQo+ID4+ID5pc3N1ZS4uLi50 aGF0IHRvbyBpbiBhbG1vc3Qgc2ltaWxhciB3YXkuDQo+ID4+ID4NCj4gPj4gPi0NCj4gPj4gPlJl Z2FyZHMsDQo+ID4+ID5QcmFzaGFudCBKaGluZ3Jhbg0KPiA+PiA+Tk9TVEcgVE1FIC0gU1AgV2kt RmkNCj4gPj4gPg0KPiA+PiA+aHR0cDovL3d3d2luLmNpc2NvLmNvbS9pb3MvdGVjaC9tb2JpbGUv cHJveHlpcHY2Lw0KPiA+PiA+aHR0cDovL3d3d2luLmNpc2NvLmNvbS9pb3MvdGVjaC9icm9hZGJh bmQNCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ PiA+RnJvbTogUmFqaXYgQXNhdGkgKHJhaml2YSkNCj4gPj4gPlNlbnQ6IFRodXJzZGF5LCBNYXkg MjMsIDIwMTMgMzowNiBBTQ0KPiA+PiA+VG86IE1pa2UgTWNCcmlkZTsgWHV4aWFvaHU7IHNnYW5l c2FuQGV4dHJlbWVuZXR3b3Jrcy5jb207IFByYXNoYW50DQo+ID4+ID5KaGluZ3JhbiAocGpoaW5n cmEpOyBXZWkgWmhvdSAod2VpemhvMikNCj4gPj4gPkNjOiBTdGlnIFZlbmFhczsgcGltQGlldGYu b3JnDQo+ID4+ID5TdWJqZWN0OiBSRTogW3BpbV0gY2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXpo b3UtcGltLXZycnAtMDENCj4gPj4gPg0KPiA+PiA+SGkgTWlrZSwNCj4gPj4gPg0KPiA+PiA+SXQg c2VlbXMgdGhhdCBib3RoIGRyYWZ0cyBzZWVtIHRvIHNvbHZlIG5lYXJseSB0aGUgc2FtZSBwcm9i bGVtDQo+ID4+KG11bHRpcGxlDQo+ID4+ID5yb3V0ZXJzIG9uIHRoZSBtdWx0aS1hY2Nlc3MgaW50 ZXJmYWNlIGFuZCBleGlzdGVuY2Ugb2YgZmlyc3QtaG9wDQo+ID4+ID5yZWR1bmRhbmN5IHByb3Rv Y29scyBlLmcuIFZSUlApLg0KPiA+PiA+DQo+ID4+ID5DaGVlcnMsDQo+ID4+ID5SYWppdg0KPiA+ PiA+DQo+ID4+ID4NCj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4g RnJvbTogTWlrZSBNY0JyaWRlIFttYWlsdG86bW1jYnJpZGU3QGdtYWlsLmNvbV0NCj4gPj4gPj4g U2VudDogV2VkbmVzZGF5LCBNYXkgMjIsIDIwMTMgMjoxNyBBTQ0KPiA+PiA+PiBUbzogWHV4aWFv aHU7IHNnYW5lc2FuQGV4dHJlbWVuZXR3b3Jrcy5jb207IFJhaml2IEFzYXRpIChyYWppdmEpOw0K PiA+PiA+PiBQcmFzaGFudCBKaGluZ3JhbiAocGpoaW5ncmEpOyBXZWkgWmhvdSAod2VpemhvMikN Cj4gPj4gPj4gQ2M6IFN0aWcgVmVuYWFzOyBNaWtlIE1jQnJpZGU7IHBpbUBpZXRmLm9yZw0KPiA+ PiA+PiBTdWJqZWN0OiBSZTogW3BpbV0gY2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXpob3UtcGlt LXZycnAtMDENCj4gPj4gPj4NCj4gPj4gPj4gRm9sa3MsDQo+ID4+ID4+DQo+ID4+ID4+IFdlIGhh dmUgdGhpcyBuZXcgZHJhZnQtemhvdS1waW0tdnJycC0wMSB3aGljaCB3ZSBhcmUgYWJvdXQgdG8g YWRvcHQNCj4gPj4gPj4gaW50byB0aGUgcGltIHdnLiBJdCBoYXMgYmVlbiBicm91Z2h0IHRvIHRo ZSBXR3MgYXR0ZW50aW9uIHRoYXQgdGhlcmUNCj4gPj4gPj4gaXMgYSBvbGRlciBkcmFmdCAoZHJh ZnQteHUtcGltLWRycHJpb3JpdHktYXV0by1hZGp1c3RtZW50LTAzKSB3aGljaA0KPiA+PiA+PiBt YXkgaGF2ZSBzb21lIG92ZXJsYXAgd2l0aCB0aGUgbmV3IG9uZS4gVGhhdCBvbGRlciBkcmFmdCBk b2VzIGNvbnRhaW4NCj4gPj4gPj4gaW5mb3JtYXRpb24gYWJvdXQgVlJSUCBhd2FyZSBQSU0gd2hp Y2ggaXMgYXR0cmlidXRlZCB0byBTdGlnIGluIHRoZQ0KPiA+PiA+PiBhY2tub3dsZWRnZW1lbnRz LiBJZiB0aGUgZml2ZSBvZiB5b3UgYXV0aG9ycyBmZWVsIHRoYXQgdGhlcmUgaXMgc29tZQ0KPiA+ PiA+PiB2YWxpZGl0eSB0aGF0IHRoZSBvbGRlciBkcmFmdCBjb250YWlucyBzb21lIGluZm9ybWF0 aW9uIGJlaW5nIHVzZWQgaW4NCj4gPj4gPj4gdGhlIG5ldyBkcmFmdCwgeW91IG1heSB3YW50IHRv IGFja25vd2xlZGdlIHRoYXQgaW4gdGhlIHJlZmVyZW5jZXMgb3INCj4gPj4gPj4gYWNrbm93bGVk Z2VtZW50cy4gSXQgYXBwZWFycyB0aGUgZHJhZnRzIGFyZSBkaXNzaW1pbGFyIGVub3VnaCB0byBu b3QNCj4gPj4gPj4gYmUgbWVyZ2VkIGJ1dCBJIG1heSBiZSB3cm9uZy4gUGxlYXNlIHNoYXJlIHlv dXIgb3BpbmlvbnMgb24gdGhpcyBzbw0KPiA+PndlDQo+ID4+ID4+IGNhbiBlc3RhYmxpc2ggY29u c2Vuc3VzIHdpdGhpbiB0aGUgZ3JvdXAgYW5kIG1vdmUgdGhlIGRvY3VtZW50IGFsb25nLg0KPiA+ PiA+Pg0KPiA+PiA+PiBJZiB0aGUgYnJvYWRlciBXRyBwYXJ0aWNpcGFudHMgaGF2ZSBhbiBvcGlu aW9uIG9uIHRoaXMgcGxlYXNlIHNwZWFrDQo+ID4+dXAuDQo+ID4+ID4+DQo+ID4+ID4+IHRoYW5r cywNCj4gPj4gPj4gbWlrZQ0KPiA+PiA+Pg0KPiA+PiA+PiBPbiBUaHUsIE1heSA5LCAyMDEzIGF0 IDc6MzIgUE0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPg0KPiB3cm90ZToNCj4gPj4g Pj4gPiBIaSBhbGwsDQo+ID4+ID4+ID4NCj4gPj4gPj4gPiBUaGlzIGRyYWZ0IHJlbWluZHMgbWUg dGhhdCB0aGVyZSBoYXMgYmVlbiBhIGRyYWZ0DQo+ID4+ID4+DQo+ID4+KGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXBpbS1kcnByaW9yaXR5LWF1dG8tYWRqdXN0bWVudC0wMw0K PiA+PiA+PiApIHRocmVlIHllYXJzIGJlZm9yZSB3aGljaCB1c2VzIGFsbW9zdCB0aGUgc2FtZSB0 ZWNobm9sb2d5IHRvIHNhdmUNCj4gPj4gPj4gYWxtb3N0IHRoZSBzYW1lIHByb2JsZW0uDQo+ID4+ ID4+ID4NCj4gPj4gPj4gPiBUaGUgZm9sbG93aW5nIGlzIHF1b3RlZCBmcm9tIHRoZSBhYm92ZSBk cmFmdDoNCj4gPj4gPj4gPg0KPiA+PiA+PiA+ICAgICJJbiBmYWN0LCBpZiBWUlJQIGlzIHJ1biBv biB0aGUgUElNIHJvdXRlcnMgYW5kIHRoZSBWUlJQIGhhcw0KPiA+PiA+PmVuYWJsZWQNCj4gPj4g Pj4gPiAgICB0aGUgdXBzdHJlYW0gbGluayB0cmFja2luZyBtZWNoYW5pc20sIHRoZSBQSU0gRFIg ZmFpbG92ZXINCj4gPj4gbWVjaGFuaXNtDQo+ID4+ID4+ID4gICAgY291bGQgYmUgY291cGxlZCB3 aXRoIHRoZSBWUlJQIHNvIGFzIHRvIHJldXNlIHRoZSB1cHN0cmVhbSBsaW5rDQo+ID4+ID4+ID4g ICAgdHJhY2tpbmcgbWVjaGFuaXNtIG9mIFZSUlAuIE9uZSBvcHRpb24gaXMgdG8gc3luY2hyb25p emUgdGhlDQo+ID4+UElNIERSDQo+ID4+ID4+ID4gICAgcHJpb3JpdHkgdmFsdWUgdG8gdGhlIFZS UlAgcHJpb3JpdHkgdmFsdWUgYWx3YXlzLiBJbiB0aGlzIHdheSwNCj4gPj50aGUNCj4gPj4gPj4g PiAgICBQSU0gRFIgYW5kIHRoZSBWUlJQIG1hc3RlciB3aWxsIGFsd2F5cyBydW4gb24gYW4gaWRl bnRpY2FsDQo+ID4+cm91dGVyDQo+ID4+ID4+aWYNCj4gPj4gPj4gPiAgICB0aGUgVlJSUCBQcmVl bXB0X01vZGUgaXMgc2V0IHRvIFRydWUuIEFub3RoZXIgb3B0aW9uIGlzIHRvIG1ha2UNCj4gPj50 aGUNCj4gPj4gPj4gPiAgICBQSU0gRFIgYW5kIHRoZSBWUlJQIG1hc3RlciBydW4gb24gYW4gaWRl bnRpY2FsIHJvdXRlciBhbnl3YXkNCj4gPj4oaS5lLiwNCj4gPj4gPj4gPiAgICByZWdhcmRsZXNz IHdoZXRoZXIgb3Igbm90IHRoZSBWUlJQIFByZWVtcHRfTW9kZSBpcyBUcnVlKS4gVG8NCj4gPj4g Pj5hY2hpZXZlDQo+ID4+ID4+ID4gICAgdGhpcyBnb2FsLCB0aGUgUElNIERSIHByaW9yaXR5IG9m IHRoZSBWUlJQIG1hc3RlciByb3V0ZXIgU0hPVUxEDQo+ID4+ID4+ID4gICAgYWx3YXlzIGJlIHNl dCB0byBhIGhpZ2hlciBmaXhlZCB2YWx1ZSB0aGFuIHRoYXQgb2YgdGhlIFZSUlANCj4gPj5zbGF2 ZQ0KPiA+PiA+PiA+ICAgIHJvdXRlciBhdXRvbWF0aWNhbGx5LiINCj4gPj4gPj4gPg0KPiA+PiA+ PiA+IEJlc3QgcmVnYXJkcywNCj4gPj4gPj4gPiBYaWFvaHUNCj4gPj4gPj4gPg0KPiA+PiA+PiA+ PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPj4gPj4gPj4gt6K8/sjLOiBwaW0tYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnBpbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+ID4+ID4+IE1pa2UNCj4g Pj4gPj4gPj4gTWNCcmlkZQ0KPiA+PiA+PiA+PiC3osvNyrG85DogMjAxM8TqNdTCMTDI1SAzOjQ4 DQo+ID4+ID4+ID4+IMrVvP7IyzogcGltQGlldGYub3JnDQo+ID4+ID4+ID4+INb3zOI6IFtwaW1d IGNhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16aG91LXBpbS12cnJwLTAxDQo+ID4+ID4+ID4+DQo+ ID4+ID4+ID4+IGRyYWZ0LXpob3UtcGltLXZycnAtMDEgd2FzIHByZXNlbnRlZCBpbiBvdXIgbW9z dCByZWNlbnQgcGltDQo+ID4+bWVldGluZw0KPiA+PiA+PiA+PiBpbiBPcmxhbmRvLiA0IHBlb3Bs ZSB3ZXJlIGluIGZhdm9yIG9mIGFkb3B0aW5nIHRoZSBkcmFmdC4gWmVybw0KPiA+PiA+PmFnYWlu c3QuDQo+ID4+ID4+ID4+IFBsZWFzZSByZWFkIHRoZSBkcmFmdCAoaXRzIHNob3J0KSBhbmQgcHJv dmlkZSBhbiBvcGluaW9uIGVpdGhlcg0KPiA+PndheQ0KPiA+PiA+PiA+PiBieSB0aGUgZW5kIG9m IG5leHQgRnJpZGF5IHRoZSAxN3RoLg0KPiA+PiA+PiA+Pg0KPiA+PiA+PiA+PiBodHRwOi8vd3d3 LmlldGYub3JnL2lkL2RyYWZ0LXpob3UtcGltLXZycnAtMDEudHh0DQo+ID4+ID4+ID4+DQo+ID4+ ID4+ID4+IHRoYW5rcywNCj4gPj4gPj4gPj4gbWlrZQ0KPiA+PiA+PiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+PiA+PiBwaW0gbWFpbGlu ZyBsaXN0DQo+ID4+ID4+ID4+IHBpbUBpZXRmLm9yZw0KPiA+PiA+PiA+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3BpbQ0KPiA+DQoNCg== From stig@venaas.com Wed Jun 5 10:01:48 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2479F21F9C2F for ; Wed, 5 Jun 2013 10:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.966 X-Spam-Level: X-Spam-Status: No, score=-94.966 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345, 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 53QoLoRQ9Rot for ; Wed, 5 Jun 2013 10:01:44 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 43E3921F9A73 for ; Wed, 5 Jun 2013 10:01:33 -0700 (PDT) Received: from [IPv6:2001:420:4:ea0c:3852:b7f1:995:47b] (unknown [IPv6:2001:420:4:ea0c:3852:b7f1:995:47b]) by ufisa.uninett.no (Postfix) with ESMTPSA id 6F4328456; Wed, 5 Jun 2013 19:01:31 +0200 (CEST) Message-ID: <51AF6EE5.2030300@venaas.com> Date: Wed, 05 Jun 2013 10:01:25 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "pim@ietf.org" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F669D4@NKGEML512-MBS.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C4824@NKGEML512-MBS.china.huawei.com> <51ACD34B.90001@venaas.com> In-Reply-To: <51ACD34B.90001@venaas.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Cc: Mike McBride Subject: Re: [pim] =?gb2312?b?tPC4tDogIGNhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16aG91?= =?gb2312?b?LXBpbS12cnJwLTAx?= X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 17:01:48 -0000 So far we only got responses from the authors of the two drafts. To get an understanding of how the WG is thinking, we would need responses from other people too. So please help us out by reading the two drafts and stating your thoughts on the matter. As I commented below, it is good if you can state your thoughts and not just your vote though. Technical discussion on both the two drafts is also very welcome. Stig On 6/3/2013 10:32 AM, Stig Venaas wrote: > Hi > > On 6/2/2013 8:51 PM, Xuxiaohu wrote: >> >> >>> -----ÓʼþÔ­¼þ----- >>> ·¢¼þÈË: Mike McBride [mailto:mmcbride7@gmail.com] >>> ·¢ËÍʱ¼ä: 2013Äê5ÔÂ31ÈÕ 15:07 >>> ÊÕ¼þÈË: Prashant Jhingran (pjhingra) >>> ³­ËÍ: Rajiv Asati (rajiva); Xuxiaohu; sganesan@extremenetworks.com; Wei >>> Zhou (weizho2); Stig Venaas; pim@ietf.org >>> Ö÷Ìâ: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01 >>> >>> Thank you for the responses. >>> >>> Some feel the two drafts are completely unrelated while others feel >>> they are completely related. In either case, are you, who feel they >>> are related, saying you oppose the adoption of draft-zhou-pim-vrrp-01? >>> We can infer that is the case but I haven't heard explicitly stated >>> opposition to adoption. We now have several choices for >>> draft-zhou-pim-vrrp, let me try boiling it down to 3: >>> >>> 1. adopt draft-zhou-pim-vrrp-01 as is >>> 2. adopt draft-zhou-pim-vrrp-01 only after >>> draft-xu-pim-drpriority-auto-adjustment is referenced. >>> 3. merge the drafts >> >> I prefer option 3. > > I don't think we should simply do a vote here, we need to get an > understanding of what the WG wants and see if we have a rough > consensus. I think it would be helpful if people responding could > state why they believe so, this may lead to some useful discussion > and help people make up their mind. > > As for merging, we need to see if the WG is interested in the content > of both the two drafts, and consider whether merging them makes sense. > > We did have some support for adopting draft-zhou-pim-vrrp-01 in the > last meeting, while draft-xu-pim-drpriority-auto-adjustment was > discussed a few years ago, and people probably need to re-read it and > see what they think now. > > Stig > >> Best regards, >> Xiaohu >> >>> In either case the authors should revive the expired >>> draft-xu-pim-drpriority-auto-adjustment-03 for consideration within >>> the wg irregardless of vrrp-01 adoption outcome. >>> >>> What say ye? >>> >>> mike >>> >>> On Thu, May 23, 2013 at 2:08 AM, Prashant Jhingran (pjhingra) >>> wrote: >>>> Hi Mike, >>>> >>>> I agree with Rajiv, both drafts are trying to solve the same issue....that too in >>> almost similar way. >>>> >>>> - >>>> Regards, >>>> Prashant Jhingran >>>> NOSTG TME - SP Wi-Fi >>>> >>>> http://wwwin.cisco.com/ios/tech/mobile/proxyipv6/ >>>> http://wwwin.cisco.com/ios/tech/broadband >>>> >>>> >>>> -----Original Message----- >>>> From: Rajiv Asati (rajiva) >>>> Sent: Thursday, May 23, 2013 3:06 AM >>>> To: Mike McBride; Xuxiaohu; sganesan@extremenetworks.com; Prashant >>> Jhingran (pjhingra); Wei Zhou (weizho2) >>>> Cc: Stig Venaas; pim@ietf.org >>>> Subject: RE: [pim] call for adoption: draft-zhou-pim-vrrp-01 >>>> >>>> Hi Mike, >>>> >>>> It seems that both drafts seem to solve nearly the same problem (multiple >>> routers on the multi-access interface and existence of first-hop redundancy >>> protocols e.g. VRRP). >>>> >>>> Cheers, >>>> Rajiv >>>> >>>> >>>>> -----Original Message----- >>>>> From: Mike McBride [mailto:mmcbride7@gmail.com] >>>>> Sent: Wednesday, May 22, 2013 2:17 AM >>>>> To: Xuxiaohu; sganesan@extremenetworks.com; Rajiv Asati (rajiva); >>>>> Prashant Jhingran (pjhingra); Wei Zhou (weizho2) >>>>> Cc: Stig Venaas; Mike McBride; pim@ietf.org >>>>> Subject: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01 >>>>> >>>>> Folks, >>>>> >>>>> We have this new draft-zhou-pim-vrrp-01 which we are about to adopt >>>>> into the pim wg. It has been brought to the WGs attention that there >>>>> is a older draft (draft-xu-pim-drpriority-auto-adjustment-03) which >>>>> may have some overlap with the new one. That older draft does contain >>>>> information about VRRP aware PIM which is attributed to Stig in the >>>>> acknowledgements. If the five of you authors feel that there is some >>>>> validity that the older draft contains some information being used in >>>>> the new draft, you may want to acknowledge that in the references or >>>>> acknowledgements. It appears the drafts are dissimilar enough to not >>>>> be merged but I may be wrong. Please share your opinions on this so we >>>>> can establish consensus within the group and move the document along. >>>>> >>>>> If the broader WG participants have an opinion on this please speak up. >>>>> >>>>> thanks, >>>>> mike >>>>> >>>>> On Thu, May 9, 2013 at 7:32 PM, Xuxiaohu wrote: >>>>>> Hi all, >>>>>> >>>>>> This draft reminds me that there has been a draft >>>>> (http://tools.ietf.org/html/draft-xu-pim-drpriority-auto-adjustment-03 >>>>> ) three years before which uses almost the same technology to save >>>>> almost the same problem. >>>>>> >>>>>> The following is quoted from the above draft: >>>>>> >>>>>> "In fact, if VRRP is run on the PIM routers and the VRRP has enabled >>>>>> the upstream link tracking mechanism, the PIM DR failover >>> mechanism >>>>>> could be coupled with the VRRP so as to reuse the upstream link >>>>>> tracking mechanism of VRRP. One option is to synchronize the PIM DR >>>>>> priority value to the VRRP priority value always. In this way, the >>>>>> PIM DR and the VRRP master will always run on an identical router if >>>>>> the VRRP Preempt_Mode is set to True. Another option is to make the >>>>>> PIM DR and the VRRP master run on an identical router anyway (i.e., >>>>>> regardless whether or not the VRRP Preempt_Mode is True). To >>> achieve >>>>>> this goal, the PIM DR priority of the VRRP master router SHOULD >>>>>> always be set to a higher fixed value than that of the VRRP slave >>>>>> router automatically." >>>>>> >>>>>> Best regards, >>>>>> Xiaohu >>>>>> >>>>>>> -----ÓʼþÔ­¼þ----- >>>>>>> ·¢¼þÈË: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] ´ú±í >>>>> Mike >>>>>>> McBride >>>>>>> ·¢ËÍʱ¼ä: 2013Äê5ÔÂ10ÈÕ 3:48 >>>>>>> ÊÕ¼þÈË: pim@ietf.org >>>>>>> Ö÷Ìâ: [pim] call for adoption: draft-zhou-pim-vrrp-01 >>>>>>> >>>>>>> draft-zhou-pim-vrrp-01 was presented in our most recent pim meeting >>>>>>> in Orlando. 4 people were in favor of adopting the draft. Zero against. >>>>>>> Please read the draft (its short) and provide an opinion either way >>>>>>> by the end of next Friday the 17th. >>>>>>> >>>>>>> http://www.ietf.org/id/draft-zhou-pim-vrrp-01.txt >>>>>>> >>>>>>> thanks, >>>>>>> mike >>>>>>> _______________________________________________ >>>>>>> pim mailing list >>>>>>> pim@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/pim > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > From stig@venaas.com Wed Jun 5 11:11:33 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDBF21F9A69; Wed, 5 Jun 2013 11:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.3 X-Spam-Level: X-Spam-Status: No, score=-101.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 Dlt3XMIa+tF8; Wed, 5 Jun 2013 11:11:32 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 06F0821F9A30; Wed, 5 Jun 2013 11:11:32 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 38A0F84BB; Wed, 5 Jun 2013 20:11:28 +0200 (CEST) Message-ID: <51AF7F4E.605@venaas.com> Date: Wed, 05 Jun 2013 11:11:26 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Toerless Eckert References: <20130511182540.GV12184@cisco.com> <51912101.1090002@venaas.com> In-Reply-To: <51912101.1090002@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ah@TR-Sys.de, bcain99@gmail.com, holbrook@arastra.com, mboned@ietf.org, pim@ietf.org Subject: Re: [pim] [MBONED] Trying to clean-up an SSM Errata Report X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:11:33 -0000 On 5/13/2013 10:21 AM, Stig Venaas wrote: > Hi > > On 5/11/2013 11:25 AM, Toerless Eckert wrote: >> Let me add mboned and the author of said errata. >> >> The author of this errata seems to claim inconsistency between 4607 and >> prior addressing standards (RFC3307, RFC4291). He also states: "I'm >> sure that >> RFC 4291 should NOT be called in question.". This to me implies that >> he is asking >> to have RFC4607 updated to remove these conflicts in RFC4607bis. > > Med (copied) and I are trying to get some of these issues resolved, we > have one draft (draft-ietf-6man-multicast-addr-arch-update) that will > try to clarify and resolve some conflicts. We intent to discuss some of > these SSM issues mentioned here as well. We will probably both on the > list and in the next IETF meeting try to discuss some of these issues. > > We've been focusing on how the flag bits are used, and one of the cases > is the use of the transient flag and SSM. We now have a new version of the draft that suggests some major changes, e.g. what is an SSM address (including ff2x::/32 for IANA allocations). It would be great if you can see if this addresses the errata, and also whether it makes sense in general. The latest version is at http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-01 Stig > Perhaps this thread is a good opportunity to move forward on this topic. > One question in particular, is whether the T bit should be allowed to be > 0 for SSM, and whether the IANA SSM assignments (non-yet) should have > T=0. > > Stig > >> IMHO: >> >> I have not been able to (in)validate the erratas author claims wrt. to >> the interpretation of the prior RFCs. I hope others on the lists can >> chime >> in. Assuming he is right on one or the other accounts: >> >> I would like to see a resolution that minimizes actual >> deployment/interoperability >> problems. >> >> Withdrawing address ranges deemed to be useable according to existing >> RFC4607 >> in an upcoming RFC4607bis definitely has the potentialy to create mayor >> disturbances in deployments relying on those addresses. If MBoned can >> clearly >> identify affected ranges known not to be deployed at all, then they >> could be >> redesignated, otherwise IMHO not. >> >> I have not seen any example of actual deployment/interoperability issues >> from the incompatibility of existing RFC4607 and its claimed conflicts >> with prior address architectures. It would be good if the author of >> the errata >> (or someone else) could provide some example of such breakage. >> >> If no real breakage could reasonably be claimed, i think RFC4607bis >> should >> grandfather in the ranges from RFC4607 and explain how we derived at >> them, >> and that they constitute unfortunate, but not caught violations of >> principle due to the a) human nature, b) IETF process or c) the >> complexity >> of the IPv6 address architecture. And grandfathering is not the same as >> questioning RFC4291. >> >> Cheers >> Toerless >> >> On Sat, May 11, 2013 at 05:36:53PM +0100, Adrian Farrel wrote: >>> Hi, >>> >>> Take a look at http://www.rfc-editor.org/errata_search.php?eid=905 >>> >>> I can't make head or tail of what the appropriate resolution is. >>> Advice please. >>> >>> And any ideas if there is a better place to discuss this. >>> >>> Thanks, >>> Adrian >>> >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim >> > > _______________________________________________ > MBONED mailing list > MBONED@ietf.org > https://www.ietf.org/mailman/listinfo/mboned From stig@venaas.com Wed Jun 5 12:57:38 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2719921F9AD2 for ; Wed, 5 Jun 2013 12:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 a86n2mgqDUE2 for ; Wed, 5 Jun 2013 12:57:37 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6D221F9AF8 for ; Wed, 5 Jun 2013 12:57:36 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id A03B9847B; Wed, 5 Jun 2013 21:57:34 +0200 (CEST) Message-ID: <51AF982C.70408@venaas.com> Date: Wed, 05 Jun 2013 12:57:32 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pim@ietf.org References: <519BA747.1030201@venaas.com> <51A4F72C.9040507@venaas.com> In-Reply-To: <51A4F72C.9040507@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-rfc4601-update-survey-report@tools.ietf.org Subject: Re: [pim] Reminder: pim WGLC for draft-ietf-pim-rfc4601-update-survey-report-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:57:38 -0000 On 5/28/2013 11:27 AM, Stig Venaas wrote: > This last call ends Sunday, we need more people to review this. Not many responses, but we got a few people responding asking for some minor changes and stating that they think the doc is ready with those changes. As this report has been presented to the WG and discussed and the process is something we know the WG is behind, and that this draft is in no way controversial (according to Mike and I), the chairs agree that the document passed last call. We would in general like more responses, but at least in this case, we believe it is sufficient. The WGLC comments need to be addressed though. Authors, please submit a new version that addresses the comments as needed. If possible, we want a new version that makes everyone who commented happy. Stig > Stig > > On 5/21/2013 9:56 AM, Stig Venaas wrote: >> Hi >> >> We, the chairs, want to speed up the process of updating RFC 4601 >> and as a next step we want to make sure that you, the working group, >> are happy with the implementation report. Once the group is happy, we >> want to get the report published, and then finalize the updates to >> 4601 based on that. >> >> The report results have been presented to the group. There were some >> comments in the adoption call, and the adopted version took them into >> account. The draft is available at >> http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-report-00 >> >> With this email we're starting a working group last call, ending >> Sunday June 2nd. This is important work and we need your review. It >> is the bases for updating one of our core RFCs, please read through >> the report and tell us whether it is ready to be published. >> >> Stig >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From weizho2@cisco.com Thu Jun 6 10:23:12 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50821F9590 for ; Thu, 6 Jun 2013 10:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 3tjS8ttd8cU3 for ; Thu, 6 Jun 2013 10:23:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3194C21F9485 for ; Thu, 6 Jun 2013 10:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12954; q=dns/txt; s=iport; t=1370539387; x=1371748987; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=I6q+xiaMwvb3856wK1HaHT3elAnzdEJ1vrLUQmWlxgE=; b=jk40JHwGyEx8qFenUaR8F4VVTjDilDnGssDBZMKNHTi0W8H3EXqHXE08 P8b4lU7zmYr1eNaN4xOKc8PFnRVJnG9WwAlYvgJoLmQQ+QN0dRqjh54IC hn/UICkgeL4xp4pb3RmiyBDKKRggce7KdeO7SK60aGipoIi3S5douyYAA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FABrEsFGtJXHB/2dsb2JhbABZgwkwgzy8Cw1rFnSCIwEBAQQBAQEaFzoLDAYBBgIRBAEBAQQGHQUEHwYLFAkIAgQBDQUIARKHYAMPDI5rmzYIiGkNiFKBIoszgioCFhsHBoI9N2EDk22Ba4MQinSFI4MPgic X-IronPort-AV: E=Sophos;i="4.87,816,1363132800"; d="scan'208";a="219666299" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 06 Jun 2013 17:23:06 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r56HN6Lr013368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Jun 2013 17:23:06 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.201]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 12:23:05 -0500 From: "Wei Zhou (weizho2)" To: Xuxiaohu , Mike McBride , "Prashant Jhingran (pjhingra)" Thread-Topic: [pim] call for adoption: draft-zhou-pim-vrrp-01 Thread-Index: AQHOVrP+uggkeQnYAUax3C6a4z91JZkSDz2AgADBXYCADHCgAIAAULMAgAdLhgCAAgidgA== Date: Thu, 6 Jun 2013 17:23:04 +0000 Message-ID: <23EF39780ADBDE42806FAEE7B8578690183E68EE@xmb-rcd-x05.cisco.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C52EF@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.209.193] Content-Type: text/plain; charset="gb2312" Content-ID: <1C70D3E9F27E3945A42E876E0CAA2916@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sganesan@extremenetworks.com" , "pim@ietf.org" Subject: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:23:12 -0000 SGkgWGlhb2h1LA0KDQpBY3R1YWxseSBJIHdvdWxkIHNheSBpdCBpcyBub3QgdHJ1ZSB0aGF0IHRo ZSBuZXcgZHJhZnQgaXMgImlycmVsZXZhbnQiIHRvDQp1cHN0cmVhbSBsaW5rIGZhaWx1cmUsIHdo aWNoIGlzIG9uZSBvZiB0aGUgbWFueSBzY2VuYXJpb3MgdGhhdCB0aGUgbmV3DQpnZW5lcmFsIHNv bHV0aW9uIGlzIHRyeWluZyB0byBhZGRyZXNzLg0KDQpJZiBjdXN0b21lciBydW5zIGFuIElHUCwg dGhlbiB1cHN0cmVhbSBmYWlsdXJlIGlzIG5vdCBhbiBpc3N1ZS4gT24gdGhlDQpvdGhlciBoYW5k IGlmIHBlb3BsZSB3YW50IHRvIHRoZXkgY2FuIGNvbmZpZ3VyZSBWUlJQIHRvIHRyYWNrIGxpbmsN CmZhaWx1cmVzLCBidXQgdGhhdCB3YXMgbm90IHRoZSBmb2N1cyBvZiB0aGUgbmV3IGRyYWZ0LiBE aXNjdXNzaW5nIHRoZQ0KZGlmZmVyZW50IG9iamVjdHMgdGhhdCBkaWZmZXJlbnQgVlJSUCBpbXBs ZW1lbnRhdGlvbnMgbWF5IGFsbG93IHVzZXJzIHRvDQp0cmFjayBpcyBub3Qgb25lIG9mIHRoZSBw dXJwb3NlcyBvZiB0aGUgbmV3IGRyYWZ0LCBhcyB0aGF0IGlzIG5vdCBuZWVkZWQNCnRvIGV4cGxh aW4gaG93IFZSUlAgaW50ZXJhY3RzIHdpdGggUElNLg0KDQpNb3Jlb3ZlciwgaXQgaXMgZGVmaW5p dGVseSB0cnVlIHRoYXQgdGhlIG5ldyBkcmFmdCBpcyBwcm9wb3NpbmcgdG8gbWFrZQ0KUElNIERS IGFuZCBWUlJQIE1hc3RlciBydW4gb24gdGhlIHNhbWUgcm91dGVyIGJ5IGFkanVzdGluZyBQSU0g RFINCnByaW9yaXR5LCB3aGljaCBJIGJlbGlldmUgaXMgdGhlIG9idmlvdXMgd2F5IHRvIG1ha2Ug UElNIHJlc3BvbmQgdG8gVlJSUA0Kc3RhdGUgY2hhbmdlIGFuZCBzb21ldGhpbmcgYm90aCBkcmFm dHMgc3VwcG9ydC4gSWYgeW91IGhhdmUgbmV3L2RpZmZlcmVudA0KdGhvdWdodHMgb24gdGhpcywg cGxlYXNlIHNoYXJlLg0KDQpTbyBpbiBhZGRpdGlvbiB0byB0aGF0IG9idmlvdXMgcGFydCBzaGFy ZWQgYnkgYm90aCBkcmFmdHMsIG1heSBJIGtub3cgd2hhdA0KdGVjaG5pY2FsIGNvbnRlbnQvZGV0 YWlscyB5b3UnZCBzdWdnZXN0IHRvIG1lcmdlIGJldHdlZW4gdGhlIHR3byBkcmFmdHM/DQoNClRo YW5rcywNCldlaQ0KDQoNCg0KDQoNCg0KT24gNi80LzEzIDg6MTkgUE0sICJYdXhpYW9odSIgPHh1 eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+SGkgV2VpLA0KPg0KPj4gLS0tLS3Tyrz+1K28 /i0tLS0tDQo+PiC3orz+yMs6IFdlaSBaaG91ICh3ZWl6aG8yKSBbbWFpbHRvOndlaXpobzJAY2lz Y28uY29tXQ0KPj4gt6LLzcqxvOQ6IDIwMTPE6jbUwjHI1SAyOjU2DQo+PiDK1bz+yMs6IE1pa2Ug TWNCcmlkZTsgUHJhc2hhbnQgSmhpbmdyYW4gKHBqaGluZ3JhKQ0KPj4gs63LzTogUmFqaXYgQXNh dGkgKHJhaml2YSk7IFh1eGlhb2h1OyBzZ2FuZXNhbkBleHRyZW1lbmV0d29ya3MuY29tOyBTdGln DQo+PiBWZW5hYXM7IHBpbUBpZXRmLm9yZw0KPj4g1vfM4jogUmU6IFtwaW1dIGNhbGwgZm9yIGFk b3B0aW9uOiBkcmFmdC16aG91LXBpbS12cnJwLTAxDQo+PiANCj4+IEhpLA0KPj4gDQo+PiBUaGFu ayB5b3UgYWxsIGZvciB0aGUgY29tbWVudHMgYW5kIHRob3VnaHRzLiBJIGJlbGlldmUgdGhhdCB0 aGUgb2xkDQo+PmRyYWZ0DQo+PiBpcyBhYm91dCB1cHN0cmVhbSBsaW5rIGZhaWx1cmVzLCB3aGlj aCBpcyBub3Qgd2hhdCB0aGUgbmV3IGRyYWZ0IGlzDQo+PmFib3V0Lg0KPj4gVGhlIG5ldyBkcmFm dCBpcyBhYm91dCBob3cgdG8gc3VwcG9ydCBQSU0gYW5kIFZSUlAgaW4gZ2VuZXJhbCBpbnN0ZWFk IG9mDQo+PiBmb2N1c2luZyBvbiB0aGUgb2JqZWN0IGJlaW5nIHRyYWNrZWQuDQo+DQo+SWYgeW91 ciBkcmFmdCBpcyBpcnJlbGV2YW50IHRvIHVwc3RyZWFtIGxpbmsgZmFpbHVyZSBzY2VuYXJpbywg d2hhdCdzIHRoZQ0KPm1vdGl2YXRpb24gZm9yIG1ha2luZyB0aGUgUElNIERSIGFuZCB0aGUgVlJS UCBtYXN0ZXIgYWx3YXlzIHJ1biBvbiB0aGUNCj5zYW1lIHJvdXRlcj8gSW4gb3RoZXIgd29yZHMs IHdoYXQncyB0aGUgcHJvYmxlbSB3aGVuIHRoZSBQSU0gRFIgZG9lc24ndA0KPnJ1biBvbiB0aGUg VlJSUCBtYXN0ZXIgcm91dGVyPyBJdCBzZWVtcyB0aGF0IHRoZSBiZWxvdyB0ZXh0IHF1b3RlZCBm cm9tDQo+eW91ciBkcmFmdCBkb2Vzbid0IHJlYWxseSBzdGF0ZSB0aGUgRklOQUwgcHJvYmxlbS4g SU1ITywgaXQgZG9lc24ndA0KPm1hdHRlciB3aGV0aGVyIG9yIG5vdCB0aGUgbXVsdGljYXN0IHRy YWZmaWMgaXMgZm9yd2FyZGVkIGJ5IHRoZSBWUlJQDQo+bWFzdGVyIHJvdXRlci4gSW4gYWRkaXRp b24sICJ0byBlbnN1cmUgdGhhdCB0aGUgUElNIERSIGlzIGFsd2F5cyBhYmxlIHRvDQo+Zm9yd2Fy ZCBQSU0gSm9pbi9QcnVuZSBtZXNzYWdlIHRvd2FyZHMgUlAgb3IgRkhSIiwgaXQgZG9lc24ndCBy ZXF1aXJlIHRoZQ0KPlBJTSBEUiBydW5zIG9uIHRoZSBWUlJQIG1hc3RlciByb3V0ZXIgZWl0aGVy Lg0KPg0KPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gICJQSU0gaGFzIG5vIGlu aGVyZW50IHJlZHVuZGFuY3kgY2FwYWJpbGl0aWVzIGFuZCBpdHMgb3BlcmF0aW9uIGlzDQo+ICAg Y29tcGxldGVseSBpbmRlcGVuZGVudCBvZiBWUlJQIGdyb3VwIHN0YXRlcy4gIEFzIGEgcmVzdWx0 LCBJUA0KPiAgIG11bHRpY2FzdCB0cmFmZmljIGlzIGZvcndhcmRlZCBub3QgbmVjZXNzYXJpbHkg YnkgdGhlIHNhbWUgZGV2aWNlIGFzDQo+ICAgaXMgZWxlY3RlZCBieSBWUlJQLiAgVGhlIFZSUlAg QXdhcmUgUElNIGZlYXR1cmUgcHJvdmlkZXMgY29uc2lzdGVudA0KPiAgIElQIG11bHRpY2FzdCBm b3J3YXJkaW5nIGluIGEgcmVkdW5kYW50IG5ldHdvcmsgd2l0aCB2aXJ0dWFsIHJvdXRpbmcNCj4g ICBncm91cHMgZW5hYmxlZC4NCj4NCj4gICBJbiBhIG11bHRpLWFjY2VzcyBzZWdtZW50IChzdWNo IGFzIExBTiksIFBJTSBkZXNpZ25hdGVkIHJvdXRlciAoRFIpDQo+ICAgZWxlY3Rpb24gaXMgdW5h d2FyZSBvZiB0aGUgcmVkdW5kYW5jeSBjb25maWd1cmF0aW9uLCBhbmQgdGhlIGVsZWN0ZWQNCj4g ICBEUiBhbmQgVlJSUCBtYXN0ZXIgcm91dGVyIChNUikgbWF5IG5vdCBiZSB0aGUgc2FtZSByb3V0 ZXIuICBJbiBvcmRlcg0KPiAgIHRvIGVuc3VyZSB0aGF0IHRoZSBQSU0gRFIgaXMgYWx3YXlzIGFi bGUgdG8gZm9yd2FyZCBQSU0gSm9pbi9QcnVuZQ0KPiAgIG1lc3NhZ2UgdG93YXJkcyBSUCBvciBG SFIsIHRoZSBWUlJQIE1SIGJlY29tZXMgdGhlIFBJTSBEUiAoaWYgdGhlcmUNCj4gICBpcyBvbmx5 IG9uZSBWUlJQIGdyb3VwKS4uLi4iDQo+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K Pg0KPkJlc3QgcmVnYXJkcywNCj5YaWFvaHUNCj4NCj4+IElmIHRoZSBXRyB0aGluayB0aGUgdXBz dHJlYW0gbGluayBmYWlsdXJlIHNjZW5hcmlvIHNob3VsZCBiZSBkaXNjdXNzZWQNCj4+aW4NCj4+ IGRldGFpbCBpbiB0aGUgbmV3IGRyYWZ0LCB0aGVuIEknbSBjb21wbGV0ZWx5IGZpbmUgd2l0aCBt ZXJnaW5nLg0KPj5Nb3Jlb3ZlciwNCj4+IGlmIHRoZSBuZXcgZHJhZnQgaXMgYWRvcHRlZCBpbiBp dHMgY3VycmVudCBzaGFwZSwgdGhlbiB0aGUgV0cgY2FuIGFsd2F5cw0KPj4gZGVjaWRlIHRvIGlu Y2x1ZGUgdGhlIHVwc3RyZWFtIGxpbmsgZmFpbHVyZSBzY2VuYXJpbyBsYXRlci4NCj4+IA0KPj4g VGhhbmtzLA0KPj4gV2VpDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gT24gNS8zMS8xMyAx MjowNiBBTSwgIk1pa2UgTWNCcmlkZSIgPG1tY2JyaWRlN0BnbWFpbC5jb20+IHdyb3RlOg0KPj4g DQo+PiA+VGhhbmsgeW91IGZvciB0aGUgcmVzcG9uc2VzLg0KPj4gPg0KPj4gPlNvbWUgZmVlbCB0 aGUgdHdvIGRyYWZ0cyBhcmUgY29tcGxldGVseSB1bnJlbGF0ZWQgd2hpbGUgb3RoZXJzIGZlZWwN Cj4+ID50aGV5IGFyZSBjb21wbGV0ZWx5IHJlbGF0ZWQuIEluIGVpdGhlciBjYXNlLCBhcmUgeW91 LCB3aG8gZmVlbCB0aGV5DQo+PiA+YXJlIHJlbGF0ZWQsIHNheWluZyB5b3Ugb3Bwb3NlIHRoZSBh ZG9wdGlvbiBvZiBkcmFmdC16aG91LXBpbS12cnJwLTAxPw0KPj4gPldlIGNhbiBpbmZlciB0aGF0 IGlzIHRoZSBjYXNlIGJ1dCBJIGhhdmVuJ3QgaGVhcmQgZXhwbGljaXRseSBzdGF0ZWQNCj4+ID5v cHBvc2l0aW9uIHRvIGFkb3B0aW9uLiBXZSBub3cgaGF2ZSBzZXZlcmFsIGNob2ljZXMgZm9yDQo+ PiA+ZHJhZnQtemhvdS1waW0tdnJycCwgbGV0IG1lIHRyeSBib2lsaW5nIGl0IGRvd24gdG8gMzoN Cj4+ID4NCj4+ID4xLiBhZG9wdCBkcmFmdC16aG91LXBpbS12cnJwLTAxIGFzIGlzDQo+PiA+Mi4g YWRvcHQgZHJhZnQtemhvdS1waW0tdnJycC0wMSBvbmx5IGFmdGVyDQo+PiA+ZHJhZnQteHUtcGlt LWRycHJpb3JpdHktYXV0by1hZGp1c3RtZW50IGlzIHJlZmVyZW5jZWQuDQo+PiA+My4gbWVyZ2Ug dGhlIGRyYWZ0cw0KPj4gPg0KPj4gPkluIGVpdGhlciBjYXNlIHRoZSBhdXRob3JzIHNob3VsZCBy ZXZpdmUgdGhlIGV4cGlyZWQNCj4+ID5kcmFmdC14dS1waW0tZHJwcmlvcml0eS1hdXRvLWFkanVz dG1lbnQtMDMgZm9yIGNvbnNpZGVyYXRpb24gd2l0aGluDQo+PiA+dGhlIHdnIGlycmVnYXJkbGVz cyBvZiB2cnJwLTAxIGFkb3B0aW9uIG91dGNvbWUuDQo+PiA+DQo+PiA+V2hhdCBzYXkgeWU/DQo+ PiA+DQo+PiA+bWlrZQ0KPj4gPg0KPj4gPk9uIFRodSwgTWF5IDIzLCAyMDEzIGF0IDI6MDggQU0s IFByYXNoYW50IEpoaW5ncmFuIChwamhpbmdyYSkNCj4+ID48cGpoaW5ncmFAY2lzY28uY29tPiB3 cm90ZToNCj4+ID4+IEhpIE1pa2UsDQo+PiA+Pg0KPj4gPj4gSSBhZ3JlZSB3aXRoIFJhaml2LCBi b3RoIGRyYWZ0cyBhcmUgdHJ5aW5nIHRvIHNvbHZlIHRoZSBzYW1lDQo+PiA+Pmlzc3VlLi4uLnRo YXQgdG9vIGluIGFsbW9zdCBzaW1pbGFyIHdheS4NCj4+ID4+DQo+PiA+PiAtDQo+PiA+PiBSZWdh cmRzLA0KPj4gPj4gUHJhc2hhbnQgSmhpbmdyYW4NCj4+ID4+IE5PU1RHIFRNRSAtIFNQIFdpLUZp DQo+PiA+Pg0KPj4gPj4gaHR0cDovL3d3d2luLmNpc2NvLmNvbS9pb3MvdGVjaC9tb2JpbGUvcHJv eHlpcHY2Lw0KPj4gPj4gaHR0cDovL3d3d2luLmNpc2NvLmNvbS9pb3MvdGVjaC9icm9hZGJhbmQN Cj4+ID4+DQo+PiA+Pg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZy b206IFJhaml2IEFzYXRpIChyYWppdmEpDQo+PiA+PiBTZW50OiBUaHVyc2RheSwgTWF5IDIzLCAy MDEzIDM6MDYgQU0NCj4+ID4+IFRvOiBNaWtlIE1jQnJpZGU7IFh1eGlhb2h1OyBzZ2FuZXNhbkBl eHRyZW1lbmV0d29ya3MuY29tOyBQcmFzaGFudA0KPj4gPj5KaGluZ3JhbiAocGpoaW5ncmEpOyBX ZWkgWmhvdSAod2VpemhvMikNCj4+ID4+IENjOiBTdGlnIFZlbmFhczsgcGltQGlldGYub3JnDQo+ PiA+PiBTdWJqZWN0OiBSRTogW3BpbV0gY2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXpob3UtcGlt LXZycnAtMDENCj4+ID4+DQo+PiA+PiBIaSBNaWtlLA0KPj4gPj4NCj4+ID4+IEl0IHNlZW1zIHRo YXQgYm90aCBkcmFmdHMgc2VlbSB0byBzb2x2ZSBuZWFybHkgdGhlIHNhbWUgcHJvYmxlbQ0KPj4g Pj4obXVsdGlwbGUgcm91dGVycyBvbiB0aGUgbXVsdGktYWNjZXNzIGludGVyZmFjZSBhbmQgZXhp c3RlbmNlIG9mDQo+PiA+PmZpcnN0LWhvcCByZWR1bmRhbmN5IHByb3RvY29scyBlLmcuIFZSUlAp Lg0KPj4gPj4NCj4+ID4+IENoZWVycywNCj4+ID4+IFJhaml2DQo+PiA+Pg0KPj4gPj4NCj4+ID4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4+IEZyb206IE1pa2UgTWNCcmlkZSBb bWFpbHRvOm1tY2JyaWRlN0BnbWFpbC5jb21dDQo+PiA+Pj4gU2VudDogV2VkbmVzZGF5LCBNYXkg MjIsIDIwMTMgMjoxNyBBTQ0KPj4gPj4+IFRvOiBYdXhpYW9odTsgc2dhbmVzYW5AZXh0cmVtZW5l dHdvcmtzLmNvbTsgUmFqaXYgQXNhdGkgKHJhaml2YSk7DQo+PiA+Pj4gUHJhc2hhbnQgSmhpbmdy YW4gKHBqaGluZ3JhKTsgV2VpIFpob3UgKHdlaXpobzIpDQo+PiA+Pj4gQ2M6IFN0aWcgVmVuYWFz OyBNaWtlIE1jQnJpZGU7IHBpbUBpZXRmLm9yZw0KPj4gPj4+IFN1YmplY3Q6IFJlOiBbcGltXSBj YWxsIGZvciBhZG9wdGlvbjogZHJhZnQtemhvdS1waW0tdnJycC0wMQ0KPj4gPj4+DQo+PiA+Pj4g Rm9sa3MsDQo+PiA+Pj4NCj4+ID4+PiBXZSBoYXZlIHRoaXMgbmV3IGRyYWZ0LXpob3UtcGltLXZy cnAtMDEgd2hpY2ggd2UgYXJlIGFib3V0IHRvIGFkb3B0DQo+PiA+Pj4gaW50byB0aGUgcGltIHdn LiBJdCBoYXMgYmVlbiBicm91Z2h0IHRvIHRoZSBXR3MgYXR0ZW50aW9uIHRoYXQgdGhlcmUNCj4+ ID4+PiBpcyBhIG9sZGVyIGRyYWZ0IChkcmFmdC14dS1waW0tZHJwcmlvcml0eS1hdXRvLWFkanVz dG1lbnQtMDMpIHdoaWNoDQo+PiA+Pj4gbWF5IGhhdmUgc29tZSBvdmVybGFwIHdpdGggdGhlIG5l dyBvbmUuIFRoYXQgb2xkZXIgZHJhZnQgZG9lcw0KPj5jb250YWluDQo+PiA+Pj4gaW5mb3JtYXRp b24gYWJvdXQgVlJSUCBhd2FyZSBQSU0gd2hpY2ggaXMgYXR0cmlidXRlZCB0byBTdGlnIGluIHRo ZQ0KPj4gPj4+IGFja25vd2xlZGdlbWVudHMuIElmIHRoZSBmaXZlIG9mIHlvdSBhdXRob3JzIGZl ZWwgdGhhdCB0aGVyZSBpcyBzb21lDQo+PiA+Pj4gdmFsaWRpdHkgdGhhdCB0aGUgb2xkZXIgZHJh ZnQgY29udGFpbnMgc29tZSBpbmZvcm1hdGlvbiBiZWluZyB1c2VkDQo+PmluDQo+PiA+Pj4gdGhl IG5ldyBkcmFmdCwgeW91IG1heSB3YW50IHRvIGFja25vd2xlZGdlIHRoYXQgaW4gdGhlIHJlZmVy ZW5jZXMgb3INCj4+ID4+PiBhY2tub3dsZWRnZW1lbnRzLiBJdCBhcHBlYXJzIHRoZSBkcmFmdHMg YXJlIGRpc3NpbWlsYXIgZW5vdWdoIHRvIG5vdA0KPj4gPj4+IGJlIG1lcmdlZCBidXQgSSBtYXkg YmUgd3JvbmcuIFBsZWFzZSBzaGFyZSB5b3VyIG9waW5pb25zIG9uIHRoaXMgc28NCj4+d2UNCj4+ ID4+PiBjYW4gZXN0YWJsaXNoIGNvbnNlbnN1cyB3aXRoaW4gdGhlIGdyb3VwIGFuZCBtb3ZlIHRo ZSBkb2N1bWVudA0KPj5hbG9uZy4NCj4+ID4+Pg0KPj4gPj4+IElmIHRoZSBicm9hZGVyIFdHIHBh cnRpY2lwYW50cyBoYXZlIGFuIG9waW5pb24gb24gdGhpcyBwbGVhc2Ugc3BlYWsNCj4+dXAuDQo+ PiA+Pj4NCj4+ID4+PiB0aGFua3MsDQo+PiA+Pj4gbWlrZQ0KPj4gPj4+DQo+PiA+Pj4gT24gVGh1 LCBNYXkgOSwgMjAxMyBhdCA3OjMyIFBNLCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4N Cj4+IHdyb3RlOg0KPj4gPj4+ID4gSGkgYWxsLA0KPj4gPj4+ID4NCj4+ID4+PiA+IFRoaXMgZHJh ZnQgcmVtaW5kcyBtZSB0aGF0IHRoZXJlIGhhcyBiZWVuIGEgZHJhZnQNCj4+ID4+PiANCj4+KGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXBpbS1kcnByaW9yaXR5LWF1dG8tYWRq dXN0bWVudC0wMw0KPj4gPj4+ICkgdGhyZWUgeWVhcnMgYmVmb3JlIHdoaWNoIHVzZXMgYWxtb3N0 IHRoZSBzYW1lIHRlY2hub2xvZ3kgdG8gc2F2ZQ0KPj4gPj4+IGFsbW9zdCB0aGUgc2FtZSBwcm9i bGVtLg0KPj4gPj4+ID4NCj4+ID4+PiA+IFRoZSBmb2xsb3dpbmcgaXMgcXVvdGVkIGZyb20gdGhl IGFib3ZlIGRyYWZ0Og0KPj4gPj4+ID4NCj4+ID4+PiA+ICAgICJJbiBmYWN0LCBpZiBWUlJQIGlz IHJ1biBvbiB0aGUgUElNIHJvdXRlcnMgYW5kIHRoZSBWUlJQIGhhcw0KPj4gPj4+ZW5hYmxlZA0K Pj4gPj4+ID4gICAgdGhlIHVwc3RyZWFtIGxpbmsgdHJhY2tpbmcgbWVjaGFuaXNtLCB0aGUgUElN IERSIGZhaWxvdmVyDQo+PiA+Pj5tZWNoYW5pc20NCj4+ID4+PiA+ICAgIGNvdWxkIGJlIGNvdXBs ZWQgd2l0aCB0aGUgVlJSUCBzbyBhcyB0byByZXVzZSB0aGUgdXBzdHJlYW0gbGluaw0KPj4gPj4+ ID4gICAgdHJhY2tpbmcgbWVjaGFuaXNtIG9mIFZSUlAuIE9uZSBvcHRpb24gaXMgdG8gc3luY2hy b25pemUgdGhlDQo+PlBJTQ0KPj4gPj4+RFINCj4+ID4+PiA+ICAgIHByaW9yaXR5IHZhbHVlIHRv IHRoZSBWUlJQIHByaW9yaXR5IHZhbHVlIGFsd2F5cy4gSW4gdGhpcyB3YXksDQo+PnRoZQ0KPj4g Pj4+ID4gICAgUElNIERSIGFuZCB0aGUgVlJSUCBtYXN0ZXIgd2lsbCBhbHdheXMgcnVuIG9uIGFu IGlkZW50aWNhbA0KPj5yb3V0ZXINCj4+ID4+PmlmDQo+PiA+Pj4gPiAgICB0aGUgVlJSUCBQcmVl bXB0X01vZGUgaXMgc2V0IHRvIFRydWUuIEFub3RoZXIgb3B0aW9uIGlzIHRvIG1ha2UNCj4+ID4+ PnRoZQ0KPj4gPj4+ID4gICAgUElNIERSIGFuZCB0aGUgVlJSUCBtYXN0ZXIgcnVuIG9uIGFuIGlk ZW50aWNhbCByb3V0ZXIgYW55d2F5DQo+PiA+Pj4oaS5lLiwNCj4+ID4+PiA+ICAgIHJlZ2FyZGxl c3Mgd2hldGhlciBvciBub3QgdGhlIFZSUlAgUHJlZW1wdF9Nb2RlIGlzIFRydWUpLiBUbw0KPj4g Pj4+YWNoaWV2ZQ0KPj4gPj4+ID4gICAgdGhpcyBnb2FsLCB0aGUgUElNIERSIHByaW9yaXR5IG9m IHRoZSBWUlJQIG1hc3RlciByb3V0ZXIgU0hPVUxEDQo+PiA+Pj4gPiAgICBhbHdheXMgYmUgc2V0 IHRvIGEgaGlnaGVyIGZpeGVkIHZhbHVlIHRoYW4gdGhhdCBvZiB0aGUgVlJSUA0KPj5zbGF2ZQ0K Pj4gPj4+ID4gICAgcm91dGVyIGF1dG9tYXRpY2FsbHkuIg0KPj4gPj4+ID4NCj4+ID4+PiA+IEJl c3QgcmVnYXJkcywNCj4+ID4+PiA+IFhpYW9odQ0KPj4gPj4+ID4NCj4+ID4+PiA+PiAtLS0tLdPK vP7Urbz+LS0tLS0NCj4+ID4+PiA+PiC3orz+yMs6IHBpbS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86cGltLWJvdW5jZXNAaWV0Zi5vcmddILT6se0NCj4+ID4+PiBNaWtlDQo+PiA+Pj4gPj4gTWNC cmlkZQ0KPj4gPj4+ID4+ILeiy83KsbzkOiAyMDEzxOo11MIxMMjVIDM6NDgNCj4+ID4+PiA+PiDK 1bz+yMs6IHBpbUBpZXRmLm9yZw0KPj4gPj4+ID4+INb3zOI6IFtwaW1dIGNhbGwgZm9yIGFkb3B0 aW9uOiBkcmFmdC16aG91LXBpbS12cnJwLTAxDQo+PiA+Pj4gPj4NCj4+ID4+PiA+PiBkcmFmdC16 aG91LXBpbS12cnJwLTAxIHdhcyBwcmVzZW50ZWQgaW4gb3VyIG1vc3QgcmVjZW50IHBpbQ0KPj5t ZWV0aW5nDQo+PiA+Pj4gPj4gaW4gT3JsYW5kby4gNCBwZW9wbGUgd2VyZSBpbiBmYXZvciBvZiBh ZG9wdGluZyB0aGUgZHJhZnQuIFplcm8NCj4+ID4+PmFnYWluc3QuDQo+PiA+Pj4gPj4gUGxlYXNl IHJlYWQgdGhlIGRyYWZ0IChpdHMgc2hvcnQpIGFuZCBwcm92aWRlIGFuIG9waW5pb24gZWl0aGVy DQo+PndheQ0KPj4gPj4+ID4+IGJ5IHRoZSBlbmQgb2YgbmV4dCBGcmlkYXkgdGhlIDE3dGguDQo+ PiA+Pj4gPj4NCj4+ID4+PiA+PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXpob3UtcGlt LXZycnAtMDEudHh0DQo+PiA+Pj4gPj4NCj4+ID4+PiA+PiB0aGFua3MsDQo+PiA+Pj4gPj4gbWlr ZQ0KPj4gPj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiA+Pj4gPj4gcGltIG1haWxpbmcgbGlzdA0KPj4gPj4+ID4+IHBpbUBpZXRmLm9yZw0K Pj4gPj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGltDQo+DQoN Cg== From xuxiaohu@huawei.com Thu Jun 6 18:12:25 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A548B21F8AE8 for ; Thu, 6 Jun 2013 18:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, 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 rBYSbpBuWjFE for ; Thu, 6 Jun 2013 18:12:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 734A721F8BC0 for ; Thu, 6 Jun 2013 18:12:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATQ43173; Fri, 07 Jun 2013 01:12:07 +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; Fri, 7 Jun 2013 02:11:13 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 7 Jun 2013 02:12:04 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Fri, 7 Jun 2013 09:12:00 +0800 From: Xuxiaohu To: "Wei Zhou (weizho2)" , Mike McBride , "Prashant Jhingran (pjhingra)" Thread-Topic: [pim] call for adoption: draft-zhou-pim-vrrp-01 Thread-Index: AQHOXc1oyBNO9pOfGUaQq5QJP/JnZZkfHyaAgAdUqXCAAf97AIABBX0w Date: Fri, 7 Jun 2013 01:11:59 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C5E10@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C52EF@NKGEML512-MBS.china.huawei.com> <23EF39780ADBDE42806FAEE7B8578690183E68EE@xmb-rcd-x05.cisco.com> In-Reply-To: <23EF39780ADBDE42806FAEE7B8578690183E68EE@xmb-rcd-x05.cisco.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: "sganesan@extremenetworks.com" , "pim@ietf.org" Subject: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 01:12:25 -0000 SGkgV2VpLA0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3orz+yMs6IFdlaSBaaG91ICh3ZWl6 aG8yKSBbbWFpbHRvOndlaXpobzJAY2lzY28uY29tXQ0KPiC3osvNyrG85DogMjAxM8TqNtTCN8jV IDE6MjMNCj4gytW8/sjLOiBYdXhpYW9odTsgTWlrZSBNY0JyaWRlOyBQcmFzaGFudCBKaGluZ3Jh biAocGpoaW5ncmEpDQo+ILOty806IFJhaml2IEFzYXRpIChyYWppdmEpOyBzZ2FuZXNhbkBleHRy ZW1lbmV0d29ya3MuY29tOyBTdGlnIFZlbmFhczsNCj4gcGltQGlldGYub3JnDQo+INb3zOI6IFJl OiBbcGltXSBjYWxsIGZvciBhZG9wdGlvbjogZHJhZnQtemhvdS1waW0tdnJycC0wMQ0KPiANCj4g SGkgWGlhb2h1LA0KPiANCj4gQWN0dWFsbHkgSSB3b3VsZCBzYXkgaXQgaXMgbm90IHRydWUgdGhh dCB0aGUgbmV3IGRyYWZ0IGlzICJpcnJlbGV2YW50IiB0bw0KPiB1cHN0cmVhbSBsaW5rIGZhaWx1 cmUsIHdoaWNoIGlzIG9uZSBvZiB0aGUgbWFueSBzY2VuYXJpb3MgdGhhdCB0aGUgbmV3DQo+IGdl bmVyYWwgc29sdXRpb24gaXMgdHJ5aW5nIHRvIGFkZHJlc3MuDQoNCldoYXQgYXJlIHRoZSBvdGhl ciBzY2VuYXJpb3MgdGhhdCB0aGUgZ2VuZXJhbCBzb2x1dGlvbiBpcyB0cnlpbmcgdG8gYWRkcmVz cz8NCiANCj4gSWYgY3VzdG9tZXIgcnVucyBhbiBJR1AsIHRoZW4gdXBzdHJlYW0gZmFpbHVyZSBp cyBub3QgYW4gaXNzdWUuIE9uIHRoZQ0KPiBvdGhlciBoYW5kIGlmIHBlb3BsZSB3YW50IHRvIHRo ZXkgY2FuIGNvbmZpZ3VyZSBWUlJQIHRvIHRyYWNrIGxpbmsNCj4gZmFpbHVyZXMsIGJ1dCB0aGF0 IHdhcyBub3QgdGhlIGZvY3VzIG9mIHRoZSBuZXcgZHJhZnQuIERpc2N1c3NpbmcgdGhlDQo+IGRp ZmZlcmVudCBvYmplY3RzIHRoYXQgZGlmZmVyZW50IFZSUlAgaW1wbGVtZW50YXRpb25zIG1heSBh bGxvdyB1c2VycyB0bw0KPiB0cmFjayBpcyBub3Qgb25lIG9mIHRoZSBwdXJwb3NlcyBvZiB0aGUg bmV3IGRyYWZ0LCBhcyB0aGF0IGlzIG5vdCBuZWVkZWQNCj4gdG8gZXhwbGFpbiBob3cgVlJSUCBp bnRlcmFjdHMgd2l0aCBQSU0uDQo+IA0KPiBNb3Jlb3ZlciwgaXQgaXMgZGVmaW5pdGVseSB0cnVl IHRoYXQgdGhlIG5ldyBkcmFmdCBpcyBwcm9wb3NpbmcgdG8gbWFrZQ0KPiBQSU0gRFIgYW5kIFZS UlAgTWFzdGVyIHJ1biBvbiB0aGUgc2FtZSByb3V0ZXIgYnkgYWRqdXN0aW5nIFBJTSBEUg0KPiBw cmlvcml0eSwgd2hpY2ggSSBiZWxpZXZlIGlzIHRoZSBvYnZpb3VzIHdheSB0byBtYWtlIFBJTSBy ZXNwb25kIHRvIFZSUlANCj4gc3RhdGUgY2hhbmdlIGFuZCBzb21ldGhpbmcgYm90aCBkcmFmdHMg c3VwcG9ydC4gSWYgeW91IGhhdmUgbmV3L2RpZmZlcmVudA0KPiB0aG91Z2h0cyBvbiB0aGlzLCBw bGVhc2Ugc2hhcmUuDQo+IA0KPiBTbyBpbiBhZGRpdGlvbiB0byB0aGF0IG9idmlvdXMgcGFydCBz aGFyZWQgYnkgYm90aCBkcmFmdHMsIG1heSBJIGtub3cgd2hhdA0KPiB0ZWNobmljYWwgY29udGVu dC9kZXRhaWxzIHlvdSdkIHN1Z2dlc3QgdG8gbWVyZ2UgYmV0d2VlbiB0aGUgdHdvIGRyYWZ0cz8N Cg0KSU1ITywgdGhhdCAib2J2aW91cyIgcGFydCBpcyB0aGUgb25seSBwcmFjdGljYWwgcHJvYmxl bSB0aGF0IG5lZWRzIHRvIGJlIHNvbHZlZC4gVGhlIHRyYW5zaXQgTEFOIHNjZW5hcmlvIGlzIGEg ZmFrZSBvbmUsIHdoaWNoIGhhcyBiZWVuIGV4cGxhaW5lZCBpbiBhIHByZXZpb3VzIGVtYWlsLg0K DQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCiANCj4gVGhhbmtzLA0KPiBXZWkNCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gT24gNi80LzEzIDg6MTkgUE0sICJYdXhpYW9odSIgPHh1eGlhb2h1QGh1 YXdlaS5jb20+IHdyb3RlOg0KPiANCj4gPkhpIFdlaSwNCj4gPg0KPiA+PiAtLS0tLdPKvP7Urbz+ LS0tLS0NCj4gPj4gt6K8/sjLOiBXZWkgWmhvdSAod2VpemhvMikgW21haWx0bzp3ZWl6aG8yQGNp c2NvLmNvbV0NCj4gPj4gt6LLzcqxvOQ6IDIwMTPE6jbUwjHI1SAyOjU2DQo+ID4+IMrVvP7Iyzog TWlrZSBNY0JyaWRlOyBQcmFzaGFudCBKaGluZ3JhbiAocGpoaW5ncmEpDQo+ID4+ILOty806IFJh aml2IEFzYXRpIChyYWppdmEpOyBYdXhpYW9odTsgc2dhbmVzYW5AZXh0cmVtZW5ldHdvcmtzLmNv bTsgU3RpZw0KPiA+PiBWZW5hYXM7IHBpbUBpZXRmLm9yZw0KPiA+PiDW98ziOiBSZTogW3BpbV0g Y2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXpob3UtcGltLXZycnAtMDENCj4gPj4NCj4gPj4gSGks DQo+ID4+DQo+ID4+IFRoYW5rIHlvdSBhbGwgZm9yIHRoZSBjb21tZW50cyBhbmQgdGhvdWdodHMu IEkgYmVsaWV2ZSB0aGF0IHRoZSBvbGQNCj4gPj5kcmFmdA0KPiA+PiBpcyBhYm91dCB1cHN0cmVh bSBsaW5rIGZhaWx1cmVzLCB3aGljaCBpcyBub3Qgd2hhdCB0aGUgbmV3IGRyYWZ0IGlzDQo+ID4+ YWJvdXQuDQo+ID4+IFRoZSBuZXcgZHJhZnQgaXMgYWJvdXQgaG93IHRvIHN1cHBvcnQgUElNIGFu ZCBWUlJQIGluIGdlbmVyYWwgaW5zdGVhZCBvZg0KPiA+PiBmb2N1c2luZyBvbiB0aGUgb2JqZWN0 IGJlaW5nIHRyYWNrZWQuDQo+ID4NCj4gPklmIHlvdXIgZHJhZnQgaXMgaXJyZWxldmFudCB0byB1 cHN0cmVhbSBsaW5rIGZhaWx1cmUgc2NlbmFyaW8sIHdoYXQncyB0aGUNCj4gPm1vdGl2YXRpb24g Zm9yIG1ha2luZyB0aGUgUElNIERSIGFuZCB0aGUgVlJSUCBtYXN0ZXIgYWx3YXlzIHJ1biBvbiB0 aGUNCj4gPnNhbWUgcm91dGVyPyBJbiBvdGhlciB3b3Jkcywgd2hhdCdzIHRoZSBwcm9ibGVtIHdo ZW4gdGhlIFBJTSBEUiBkb2Vzbid0DQo+ID5ydW4gb24gdGhlIFZSUlAgbWFzdGVyIHJvdXRlcj8g SXQgc2VlbXMgdGhhdCB0aGUgYmVsb3cgdGV4dCBxdW90ZWQgZnJvbQ0KPiA+eW91ciBkcmFmdCBk b2Vzbid0IHJlYWxseSBzdGF0ZSB0aGUgRklOQUwgcHJvYmxlbS4gSU1ITywgaXQgZG9lc24ndA0K PiA+bWF0dGVyIHdoZXRoZXIgb3Igbm90IHRoZSBtdWx0aWNhc3QgdHJhZmZpYyBpcyBmb3J3YXJk ZWQgYnkgdGhlIFZSUlANCj4gPm1hc3RlciByb3V0ZXIuIEluIGFkZGl0aW9uLCAidG8gZW5zdXJl IHRoYXQgdGhlIFBJTSBEUiBpcyBhbHdheXMgYWJsZSB0bw0KPiA+Zm9yd2FyZCBQSU0gSm9pbi9Q cnVuZSBtZXNzYWdlIHRvd2FyZHMgUlAgb3IgRkhSIiwgaXQgZG9lc24ndCByZXF1aXJlIHRoZQ0K PiA+UElNIERSIHJ1bnMgb24gdGhlIFZSUlAgbWFzdGVyIHJvdXRlciBlaXRoZXIuDQo+ID4NCj4g Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPiAgIlBJTSBoYXMgbm8gaW5oZXJl bnQgcmVkdW5kYW5jeSBjYXBhYmlsaXRpZXMgYW5kIGl0cyBvcGVyYXRpb24gaXMNCj4gPiAgIGNv bXBsZXRlbHkgaW5kZXBlbmRlbnQgb2YgVlJSUCBncm91cCBzdGF0ZXMuICBBcyBhIHJlc3VsdCwg SVANCj4gPiAgIG11bHRpY2FzdCB0cmFmZmljIGlzIGZvcndhcmRlZCBub3QgbmVjZXNzYXJpbHkg YnkgdGhlIHNhbWUgZGV2aWNlIGFzDQo+ID4gICBpcyBlbGVjdGVkIGJ5IFZSUlAuICBUaGUgVlJS UCBBd2FyZSBQSU0gZmVhdHVyZSBwcm92aWRlcyBjb25zaXN0ZW50DQo+ID4gICBJUCBtdWx0aWNh c3QgZm9yd2FyZGluZyBpbiBhIHJlZHVuZGFudCBuZXR3b3JrIHdpdGggdmlydHVhbCByb3V0aW5n DQo+ID4gICBncm91cHMgZW5hYmxlZC4NCj4gPg0KPiA+ICAgSW4gYSBtdWx0aS1hY2Nlc3Mgc2Vn bWVudCAoc3VjaCBhcyBMQU4pLCBQSU0gZGVzaWduYXRlZCByb3V0ZXIgKERSKQ0KPiA+ICAgZWxl Y3Rpb24gaXMgdW5hd2FyZSBvZiB0aGUgcmVkdW5kYW5jeSBjb25maWd1cmF0aW9uLCBhbmQgdGhl IGVsZWN0ZWQNCj4gPiAgIERSIGFuZCBWUlJQIG1hc3RlciByb3V0ZXIgKE1SKSBtYXkgbm90IGJl IHRoZSBzYW1lIHJvdXRlci4gIEluIG9yZGVyDQo+ID4gICB0byBlbnN1cmUgdGhhdCB0aGUgUElN IERSIGlzIGFsd2F5cyBhYmxlIHRvIGZvcndhcmQgUElNIEpvaW4vUHJ1bmUNCj4gPiAgIG1lc3Nh Z2UgdG93YXJkcyBSUCBvciBGSFIsIHRoZSBWUlJQIE1SIGJlY29tZXMgdGhlIFBJTSBEUiAoaWYg dGhlcmUNCj4gPiAgIGlzIG9ubHkgb25lIFZSUlAgZ3JvdXApLi4uLiINCj4gPj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCj4gPg0KPiA+QmVzdCByZWdhcmRzLA0KPiA+WGlhb2h1DQo+ ID4NCj4gPj4gSWYgdGhlIFdHIHRoaW5rIHRoZSB1cHN0cmVhbSBsaW5rIGZhaWx1cmUgc2NlbmFy aW8gc2hvdWxkIGJlIGRpc2N1c3NlZA0KPiA+PmluDQo+ID4+IGRldGFpbCBpbiB0aGUgbmV3IGRy YWZ0LCB0aGVuIEknbSBjb21wbGV0ZWx5IGZpbmUgd2l0aCBtZXJnaW5nLg0KPiA+Pk1vcmVvdmVy LA0KPiA+PiBpZiB0aGUgbmV3IGRyYWZ0IGlzIGFkb3B0ZWQgaW4gaXRzIGN1cnJlbnQgc2hhcGUs IHRoZW4gdGhlIFdHIGNhbiBhbHdheXMNCj4gPj4gZGVjaWRlIHRvIGluY2x1ZGUgdGhlIHVwc3Ry ZWFtIGxpbmsgZmFpbHVyZSBzY2VuYXJpbyBsYXRlci4NCj4gPj4NCj4gPj4gVGhhbmtzLA0KPiA+ PiBXZWkNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gNS8zMS8xMyAxMjow NiBBTSwgIk1pa2UgTWNCcmlkZSIgPG1tY2JyaWRlN0BnbWFpbC5jb20+IHdyb3RlOg0KPiA+Pg0K PiA+PiA+VGhhbmsgeW91IGZvciB0aGUgcmVzcG9uc2VzLg0KPiA+PiA+DQo+ID4+ID5Tb21lIGZl ZWwgdGhlIHR3byBkcmFmdHMgYXJlIGNvbXBsZXRlbHkgdW5yZWxhdGVkIHdoaWxlIG90aGVycyBm ZWVsDQo+ID4+ID50aGV5IGFyZSBjb21wbGV0ZWx5IHJlbGF0ZWQuIEluIGVpdGhlciBjYXNlLCBh cmUgeW91LCB3aG8gZmVlbCB0aGV5DQo+ID4+ID5hcmUgcmVsYXRlZCwgc2F5aW5nIHlvdSBvcHBv c2UgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0LXpob3UtcGltLXZycnAtMDE/DQo+ID4+ID5XZSBjYW4g aW5mZXIgdGhhdCBpcyB0aGUgY2FzZSBidXQgSSBoYXZlbid0IGhlYXJkIGV4cGxpY2l0bHkgc3Rh dGVkDQo+ID4+ID5vcHBvc2l0aW9uIHRvIGFkb3B0aW9uLiBXZSBub3cgaGF2ZSBzZXZlcmFsIGNo b2ljZXMgZm9yDQo+ID4+ID5kcmFmdC16aG91LXBpbS12cnJwLCBsZXQgbWUgdHJ5IGJvaWxpbmcg aXQgZG93biB0byAzOg0KPiA+PiA+DQo+ID4+ID4xLiBhZG9wdCBkcmFmdC16aG91LXBpbS12cnJw LTAxIGFzIGlzDQo+ID4+ID4yLiBhZG9wdCBkcmFmdC16aG91LXBpbS12cnJwLTAxIG9ubHkgYWZ0 ZXINCj4gPj4gPmRyYWZ0LXh1LXBpbS1kcnByaW9yaXR5LWF1dG8tYWRqdXN0bWVudCBpcyByZWZl cmVuY2VkLg0KPiA+PiA+My4gbWVyZ2UgdGhlIGRyYWZ0cw0KPiA+PiA+DQo+ID4+ID5JbiBlaXRo ZXIgY2FzZSB0aGUgYXV0aG9ycyBzaG91bGQgcmV2aXZlIHRoZSBleHBpcmVkDQo+ID4+ID5kcmFm dC14dS1waW0tZHJwcmlvcml0eS1hdXRvLWFkanVzdG1lbnQtMDMgZm9yIGNvbnNpZGVyYXRpb24g d2l0aGluDQo+ID4+ID50aGUgd2cgaXJyZWdhcmRsZXNzIG9mIHZycnAtMDEgYWRvcHRpb24gb3V0 Y29tZS4NCj4gPj4gPg0KPiA+PiA+V2hhdCBzYXkgeWU/DQo+ID4+ID4NCj4gPj4gPm1pa2UNCj4g Pj4gPg0KPiA+PiA+T24gVGh1LCBNYXkgMjMsIDIwMTMgYXQgMjowOCBBTSwgUHJhc2hhbnQgSmhp bmdyYW4gKHBqaGluZ3JhKQ0KPiA+PiA+PHBqaGluZ3JhQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+ ID4+IEhpIE1pa2UsDQo+ID4+ID4+DQo+ID4+ID4+IEkgYWdyZWUgd2l0aCBSYWppdiwgYm90aCBk cmFmdHMgYXJlIHRyeWluZyB0byBzb2x2ZSB0aGUgc2FtZQ0KPiA+PiA+Pmlzc3VlLi4uLnRoYXQg dG9vIGluIGFsbW9zdCBzaW1pbGFyIHdheS4NCj4gPj4gPj4NCj4gPj4gPj4gLQ0KPiA+PiA+PiBS ZWdhcmRzLA0KPiA+PiA+PiBQcmFzaGFudCBKaGluZ3Jhbg0KPiA+PiA+PiBOT1NURyBUTUUgLSBT UCBXaS1GaQ0KPiA+PiA+Pg0KPiA+PiA+PiBodHRwOi8vd3d3aW4uY2lzY28uY29tL2lvcy90ZWNo L21vYmlsZS9wcm94eWlwdjYvDQo+ID4+ID4+IGh0dHA6Ly93d3dpbi5jaXNjby5jb20vaW9zL3Rl Y2gvYnJvYWRiYW5kDQo+ID4+ID4+DQo+ID4+ID4+DQo+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4+ID4+IEZyb206IFJhaml2IEFzYXRpIChyYWppdmEpDQo+ID4+ID4+IFNl bnQ6IFRodXJzZGF5LCBNYXkgMjMsIDIwMTMgMzowNiBBTQ0KPiA+PiA+PiBUbzogTWlrZSBNY0Jy aWRlOyBYdXhpYW9odTsgc2dhbmVzYW5AZXh0cmVtZW5ldHdvcmtzLmNvbTsNCj4gUHJhc2hhbnQN Cj4gPj4gPj5KaGluZ3JhbiAocGpoaW5ncmEpOyBXZWkgWmhvdSAod2VpemhvMikNCj4gPj4gPj4g Q2M6IFN0aWcgVmVuYWFzOyBwaW1AaWV0Zi5vcmcNCj4gPj4gPj4gU3ViamVjdDogUkU6IFtwaW1d IGNhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16aG91LXBpbS12cnJwLTAxDQo+ID4+ID4+DQo+ID4+ ID4+IEhpIE1pa2UsDQo+ID4+ID4+DQo+ID4+ID4+IEl0IHNlZW1zIHRoYXQgYm90aCBkcmFmdHMg c2VlbSB0byBzb2x2ZSBuZWFybHkgdGhlIHNhbWUgcHJvYmxlbQ0KPiA+PiA+PihtdWx0aXBsZSBy b3V0ZXJzIG9uIHRoZSBtdWx0aS1hY2Nlc3MgaW50ZXJmYWNlIGFuZCBleGlzdGVuY2Ugb2YNCj4g Pj4gPj5maXJzdC1ob3AgcmVkdW5kYW5jeSBwcm90b2NvbHMgZS5nLiBWUlJQKS4NCj4gPj4gPj4N Cj4gPj4gPj4gQ2hlZXJzLA0KPiA+PiA+PiBSYWppdg0KPiA+PiA+Pg0KPiA+PiA+Pg0KPiA+PiA+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gPj4+IEZyb206IE1pa2UgTWNCcmlk ZSBbbWFpbHRvOm1tY2JyaWRlN0BnbWFpbC5jb21dDQo+ID4+ID4+PiBTZW50OiBXZWRuZXNkYXks IE1heSAyMiwgMjAxMyAyOjE3IEFNDQo+ID4+ID4+PiBUbzogWHV4aWFvaHU7IHNnYW5lc2FuQGV4 dHJlbWVuZXR3b3Jrcy5jb207IFJhaml2IEFzYXRpIChyYWppdmEpOw0KPiA+PiA+Pj4gUHJhc2hh bnQgSmhpbmdyYW4gKHBqaGluZ3JhKTsgV2VpIFpob3UgKHdlaXpobzIpDQo+ID4+ID4+PiBDYzog U3RpZyBWZW5hYXM7IE1pa2UgTWNCcmlkZTsgcGltQGlldGYub3JnDQo+ID4+ID4+PiBTdWJqZWN0 OiBSZTogW3BpbV0gY2FsbCBmb3IgYWRvcHRpb246IGRyYWZ0LXpob3UtcGltLXZycnAtMDENCj4g Pj4gPj4+DQo+ID4+ID4+PiBGb2xrcywNCj4gPj4gPj4+DQo+ID4+ID4+PiBXZSBoYXZlIHRoaXMg bmV3IGRyYWZ0LXpob3UtcGltLXZycnAtMDEgd2hpY2ggd2UgYXJlIGFib3V0IHRvIGFkb3B0DQo+ ID4+ID4+PiBpbnRvIHRoZSBwaW0gd2cuIEl0IGhhcyBiZWVuIGJyb3VnaHQgdG8gdGhlIFdHcyBh dHRlbnRpb24gdGhhdCB0aGVyZQ0KPiA+PiA+Pj4gaXMgYSBvbGRlciBkcmFmdCAoZHJhZnQteHUt cGltLWRycHJpb3JpdHktYXV0by1hZGp1c3RtZW50LTAzKSB3aGljaA0KPiA+PiA+Pj4gbWF5IGhh dmUgc29tZSBvdmVybGFwIHdpdGggdGhlIG5ldyBvbmUuIFRoYXQgb2xkZXIgZHJhZnQgZG9lcw0K PiA+PmNvbnRhaW4NCj4gPj4gPj4+IGluZm9ybWF0aW9uIGFib3V0IFZSUlAgYXdhcmUgUElNIHdo aWNoIGlzIGF0dHJpYnV0ZWQgdG8gU3RpZyBpbiB0aGUNCj4gPj4gPj4+IGFja25vd2xlZGdlbWVu dHMuIElmIHRoZSBmaXZlIG9mIHlvdSBhdXRob3JzIGZlZWwgdGhhdCB0aGVyZSBpcyBzb21lDQo+ ID4+ID4+PiB2YWxpZGl0eSB0aGF0IHRoZSBvbGRlciBkcmFmdCBjb250YWlucyBzb21lIGluZm9y bWF0aW9uIGJlaW5nIHVzZWQNCj4gPj5pbg0KPiA+PiA+Pj4gdGhlIG5ldyBkcmFmdCwgeW91IG1h eSB3YW50IHRvIGFja25vd2xlZGdlIHRoYXQgaW4gdGhlIHJlZmVyZW5jZXMgb3INCj4gPj4gPj4+ IGFja25vd2xlZGdlbWVudHMuIEl0IGFwcGVhcnMgdGhlIGRyYWZ0cyBhcmUgZGlzc2ltaWxhciBl bm91Z2ggdG8gbm90DQo+ID4+ID4+PiBiZSBtZXJnZWQgYnV0IEkgbWF5IGJlIHdyb25nLiBQbGVh c2Ugc2hhcmUgeW91ciBvcGluaW9ucyBvbiB0aGlzIHNvDQo+ID4+d2UNCj4gPj4gPj4+IGNhbiBl c3RhYmxpc2ggY29uc2Vuc3VzIHdpdGhpbiB0aGUgZ3JvdXAgYW5kIG1vdmUgdGhlIGRvY3VtZW50 DQo+ID4+YWxvbmcuDQo+ID4+ID4+Pg0KPiA+PiA+Pj4gSWYgdGhlIGJyb2FkZXIgV0cgcGFydGlj aXBhbnRzIGhhdmUgYW4gb3BpbmlvbiBvbiB0aGlzIHBsZWFzZSBzcGVhaw0KPiA+PnVwLg0KPiA+ PiA+Pj4NCj4gPj4gPj4+IHRoYW5rcywNCj4gPj4gPj4+IG1pa2UNCj4gPj4gPj4+DQo+ID4+ID4+ PiBPbiBUaHUsIE1heSA5LCAyMDEzIGF0IDc6MzIgUE0sIFh1eGlhb2h1IDx4dXhpYW9odUBodWF3 ZWkuY29tPg0KPiA+PiB3cm90ZToNCj4gPj4gPj4+ID4gSGkgYWxsLA0KPiA+PiA+Pj4gPg0KPiA+ PiA+Pj4gPiBUaGlzIGRyYWZ0IHJlbWluZHMgbWUgdGhhdCB0aGVyZSBoYXMgYmVlbiBhIGRyYWZ0 DQo+ID4+ID4+Pg0KPiA+PihodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1waW0t ZHJwcmlvcml0eS1hdXRvLWFkanVzdG1lbnQtMDMNCj4gPj4gPj4+ICkgdGhyZWUgeWVhcnMgYmVm b3JlIHdoaWNoIHVzZXMgYWxtb3N0IHRoZSBzYW1lIHRlY2hub2xvZ3kgdG8gc2F2ZQ0KPiA+PiA+ Pj4gYWxtb3N0IHRoZSBzYW1lIHByb2JsZW0uDQo+ID4+ID4+PiA+DQo+ID4+ID4+PiA+IFRoZSBm b2xsb3dpbmcgaXMgcXVvdGVkIGZyb20gdGhlIGFib3ZlIGRyYWZ0Og0KPiA+PiA+Pj4gPg0KPiA+ PiA+Pj4gPiAgICAiSW4gZmFjdCwgaWYgVlJSUCBpcyBydW4gb24gdGhlIFBJTSByb3V0ZXJzIGFu ZCB0aGUgVlJSUCBoYXMNCj4gPj4gPj4+ZW5hYmxlZA0KPiA+PiA+Pj4gPiAgICB0aGUgdXBzdHJl YW0gbGluayB0cmFja2luZyBtZWNoYW5pc20sIHRoZSBQSU0gRFIgZmFpbG92ZXINCj4gPj4gPj4+ bWVjaGFuaXNtDQo+ID4+ID4+PiA+ICAgIGNvdWxkIGJlIGNvdXBsZWQgd2l0aCB0aGUgVlJSUCBz byBhcyB0byByZXVzZSB0aGUgdXBzdHJlYW0gbGluaw0KPiA+PiA+Pj4gPiAgICB0cmFja2luZyBt ZWNoYW5pc20gb2YgVlJSUC4gT25lIG9wdGlvbiBpcyB0byBzeW5jaHJvbml6ZSB0aGUNCj4gPj5Q SU0NCj4gPj4gPj4+RFINCj4gPj4gPj4+ID4gICAgcHJpb3JpdHkgdmFsdWUgdG8gdGhlIFZSUlAg cHJpb3JpdHkgdmFsdWUgYWx3YXlzLiBJbiB0aGlzIHdheSwNCj4gPj50aGUNCj4gPj4gPj4+ID4g ICAgUElNIERSIGFuZCB0aGUgVlJSUCBtYXN0ZXIgd2lsbCBhbHdheXMgcnVuIG9uIGFuIGlkZW50 aWNhbA0KPiA+PnJvdXRlcg0KPiA+PiA+Pj5pZg0KPiA+PiA+Pj4gPiAgICB0aGUgVlJSUCBQcmVl bXB0X01vZGUgaXMgc2V0IHRvIFRydWUuIEFub3RoZXIgb3B0aW9uIGlzIHRvDQo+IG1ha2UNCj4g Pj4gPj4+dGhlDQo+ID4+ID4+PiA+ICAgIFBJTSBEUiBhbmQgdGhlIFZSUlAgbWFzdGVyIHJ1biBv biBhbiBpZGVudGljYWwgcm91dGVyIGFueXdheQ0KPiA+PiA+Pj4oaS5lLiwNCj4gPj4gPj4+ID4g ICAgcmVnYXJkbGVzcyB3aGV0aGVyIG9yIG5vdCB0aGUgVlJSUCBQcmVlbXB0X01vZGUgaXMgVHJ1 ZSkuIFRvDQo+ID4+ID4+PmFjaGlldmUNCj4gPj4gPj4+ID4gICAgdGhpcyBnb2FsLCB0aGUgUElN IERSIHByaW9yaXR5IG9mIHRoZSBWUlJQIG1hc3RlciByb3V0ZXIgU0hPVUxEDQo+ID4+ID4+PiA+ ICAgIGFsd2F5cyBiZSBzZXQgdG8gYSBoaWdoZXIgZml4ZWQgdmFsdWUgdGhhbiB0aGF0IG9mIHRo ZSBWUlJQDQo+ID4+c2xhdmUNCj4gPj4gPj4+ID4gICAgcm91dGVyIGF1dG9tYXRpY2FsbHkuIg0K PiA+PiA+Pj4gPg0KPiA+PiA+Pj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4+ID4+PiA+IFhpYW9odQ0K PiA+PiA+Pj4gPg0KPiA+PiA+Pj4gPj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ID4+ID4+PiA+PiC3 orz+yMs6IHBpbS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGltLWJvdW5jZXNAaWV0Zi5vcmdd ILT6se0NCj4gPj4gPj4+IE1pa2UNCj4gPj4gPj4+ID4+IE1jQnJpZGUNCj4gPj4gPj4+ID4+ILei y83KsbzkOiAyMDEzxOo11MIxMMjVIDM6NDgNCj4gPj4gPj4+ID4+IMrVvP7IyzogcGltQGlldGYu b3JnDQo+ID4+ID4+PiA+PiDW98ziOiBbcGltXSBjYWxsIGZvciBhZG9wdGlvbjogZHJhZnQtemhv dS1waW0tdnJycC0wMQ0KPiA+PiA+Pj4gPj4NCj4gPj4gPj4+ID4+IGRyYWZ0LXpob3UtcGltLXZy cnAtMDEgd2FzIHByZXNlbnRlZCBpbiBvdXIgbW9zdCByZWNlbnQgcGltDQo+ID4+bWVldGluZw0K PiA+PiA+Pj4gPj4gaW4gT3JsYW5kby4gNCBwZW9wbGUgd2VyZSBpbiBmYXZvciBvZiBhZG9wdGlu ZyB0aGUgZHJhZnQuIFplcm8NCj4gPj4gPj4+YWdhaW5zdC4NCj4gPj4gPj4+ID4+IFBsZWFzZSBy ZWFkIHRoZSBkcmFmdCAoaXRzIHNob3J0KSBhbmQgcHJvdmlkZSBhbiBvcGluaW9uIGVpdGhlcg0K PiA+PndheQ0KPiA+PiA+Pj4gPj4gYnkgdGhlIGVuZCBvZiBuZXh0IEZyaWRheSB0aGUgMTd0aC4N Cj4gPj4gPj4+ID4+DQo+ID4+ID4+PiA+PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXpo b3UtcGltLXZycnAtMDEudHh0DQo+ID4+ID4+PiA+Pg0KPiA+PiA+Pj4gPj4gdGhhbmtzLA0KPiA+ PiA+Pj4gPj4gbWlrZQ0KPiA+PiA+Pj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4gPj4+ID4+IHBpbSBtYWlsaW5nIGxpc3QNCj4gPj4gPj4+ ID4+IHBpbUBpZXRmLm9yZw0KPiA+PiA+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9waW0NCj4gPg0KDQo= From weizho2@cisco.com Thu Jun 6 19:35:17 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747AD21F9133 for ; Thu, 6 Jun 2013 19:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.057 X-Spam-Level: X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 do58BNXEkqYF for ; Thu, 6 Jun 2013 19:35:12 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 57C6521F9121 for ; Thu, 6 Jun 2013 19:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16858; q=dns/txt; s=iport; t=1370572512; x=1371782112; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iVZuNhSsOiiuIE+m70sPKsp/n9CHDfUcmPipGpR4AWY=; b=AoKGIKeLZqrgQPdLS4CHdpMvlOsph8R6Okw7pLbG0xjq3n2EchGpGwij 7beybZbi9xS2jh9SMCnlCHsHfMibaUTK0dDVRE+2TnjmTHwbY27lvxYwk Z4+5SHZDzLeJB3ExFfmoQOlOm9QVma1PU5tZCAGmyi4qHFW3NWXM0zWNK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAHxFsVGtJV2Z/2dsb2JhbABZgwkwgzy7NQ1vFnSCIwEBAQQBAQEaFzoLDAYBBgIRBAEBAQQGHQUEHwYLFAkIAgQBDQUIARKHYAMPDI5BmzYIiHINiFKBIoszgRuBERYbBwaCPTdhA5NtgWuDEIp0hSODD4FxNg X-IronPort-AV: E=Sophos;i="4.87,818,1363132800"; d="scan'208";a="219820836" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jun 2013 02:35:11 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r572ZBOr000801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Jun 2013 02:35:11 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.201]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 6 Jun 2013 21:35:10 -0500 From: "Wei Zhou (weizho2)" To: Xuxiaohu , Mike McBride , "Prashant Jhingran (pjhingra)" Thread-Topic: [pim] call for adoption: draft-zhou-pim-vrrp-01 Thread-Index: AQHOVrP+uggkeQnYAUax3C6a4z91JZkSDz2AgADBXYCADHCgAIAAULMAgAdLhgCAAgidgIAA+F6A//+h5IA= Date: Fri, 7 Jun 2013 02:35:10 +0000 Message-ID: <23EF39780ADBDE42806FAEE7B8578690183E6ABD@xmb-rcd-x05.cisco.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C5E10@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.209.193] Content-Type: text/plain; charset="gb2312" Content-ID: <044EBB2AA860FD49838345693D55060D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sganesan@extremenetworks.com" , "pim@ietf.org" Subject: Re: [pim] call for adoption: draft-zhou-pim-vrrp-01 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 02:35:17 -0000 SGkgeGlhb2h1LA0KDQpBcyBJIG1lbnRpb25lZCBpbiBwcmV2aW91cyBlbWFpbHMsIGFueSBzY2Vu YXJpbyB0aGF0IFZSUlAgbWF5IHRyYWNrLA0KaW5jbHVkaW5nIGludGVyZmFjZSBzdGF0ZSwgbGlu ZSBwcm90b2NvbCwgYmFuZHdpZHRoIGV0YywgY2FuIGJlIHRoZQ0KaW50ZXJlc3RlZCBldmVudC4g QWdhaW4sIHRoZSBuZXcgc29sdXRpb24gaXMgKm5vdCogdHJ5aW5nIHRvIGRpc2N1c3MgdGhlDQpk ZXRhaWxzIG9mIGFueSBzcGVjaWZpYyBldmVudCBzdWNoIGFzIHVwc3RyZWFtIGxpbmsgZmFpbHVy ZSBkZXNjcmliZWQgaW4NCnlvdXIgcHJldmlvdXMgZHJhZnQuDQoNCk1vcmUgaW1wb3J0YW50bHks IEkgYmVsaWV2ZSBpdCBpcyBpbmNvcnJlY3Qgb3IgYXQgbGVhc3QgaW5hY2N1cmF0ZSB0byBzYXkN CnRoYXQgIm1ha2luZyBWUlJQIE1hc3RlciBhbmQgUElNIERSIHRvIHJ1biBvbmUgc2FtZSByb3V0 ZXIgaXMgdGhlICpvbmx5Kg0KcHJhY3RpY2FsIHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSBzb2x2 ZWQiLCB0aGF0IGlzIHdoeSB0aGUgbmV3IGRyYWZ0DQp0cmllcyB0byBhZGRyZXNzIG90aGVyIHBy YWN0aWNhbCBwcm9ibGVtcyBsaWtlIEJJRElSLCBBc3NlcnQgYW5kIG11bHRpcGxlDQp2aXJ0dWFs IGdyb3VwcywgaW4gb3JkZXIgdG8gcHJvdmlkZSBhIGNvbXBsZXRlIHBpbS12cnJwIGludGVyYWN0 aW9uDQpzb2x1dGlvbiAtIHJhdGhlciB0aGFuIHNpbXBseSBhZGp1c3RpbmcgdGhlIFBJTSBEUiBw cmlvcml0eS4gQW5kIHRoYXQncw0Kd2h5IEknZCBsaWtlIHRvIGtub3cgd2hhdCB5b3Ugd291bGQg c3VnZ2VzdCB0byBtZXJnZSB3aXRoIHRoZSBuZXcgZHJhZnQNCmZyb20gdGVjaG5pY2FsIHBvaW50 IG9mIHZpZXcuDQoNClJlZ2FyZGluZyB0aGUgdHJhbnNpdCBuZXR3b3JrIHNjZW5hcmlvLCBJIGFt IHN0aWxsIG5vdCBxdWl0ZSBzdXJlIGFib3V0DQp0aGUgcmVhc29uIHdoeSB5b3UgZGVzY3JpYmVk IGl0IGFzIGEgImZha2UiIHNjZW5hcmlvIGZyb20geW91ciBwcmV2aW91cw0KY29tbWVudHMuIEFy ZSB5b3Ugc2F5aW5nIHRoYXQgdGhlcmUgaXMgYWJzb2x1dGVseSB6ZXJvIGNoYW5jZSB0aGF0IGFu eQ0KY3VzdG9tZXIgd2lsbCBlbmFibGUgVlJSUCBpbiBhbnkgdHJhbnNpdCBuZXR3b3JrIHNjZW5h cmlvIGZvciBhbnkgcmVhc29uPw0KUGxlYXNlIGNvcnJlY3QgbWUgaWYgbXkgdW5kZXJzdGFuZGlu ZyBpcyB3cm9uZyBoZXJlLCBJIGJlbGlldmUgaXQgaXMNCmFjdHVhbGx5IGFuIGludGVyZXN0aW5n IHRvcGljIHRvIGRpc2N1c3Mgb24gdGhlIHBvc3NpYmxlIHVzZSBjYXNlcyBoZXJlLg0KIA0KDQpU aGFua3MsDQpXZWkNCg0KDQoNCg0KDQpPbiA2LzYvMTMgNjoxMSBQTSwgIlh1eGlhb2h1IiA8eHV4 aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5IaSBXZWksDQo+DQo+PiAtLS0tLdPKvP7Urbz+ LS0tLS0NCj4+ILeivP7IyzogV2VpIFpob3UgKHdlaXpobzIpIFttYWlsdG86d2VpemhvMkBjaXNj by5jb21dDQo+PiC3osvNyrG85DogMjAxM8TqNtTCN8jVIDE6MjMNCj4+IMrVvP7IyzogWHV4aWFv aHU7IE1pa2UgTWNCcmlkZTsgUHJhc2hhbnQgSmhpbmdyYW4gKHBqaGluZ3JhKQ0KPj4gs63LzTog UmFqaXYgQXNhdGkgKHJhaml2YSk7IHNnYW5lc2FuQGV4dHJlbWVuZXR3b3Jrcy5jb207IFN0aWcg VmVuYWFzOw0KPj4gcGltQGlldGYub3JnDQo+PiDW98ziOiBSZTogW3BpbV0gY2FsbCBmb3IgYWRv cHRpb246IGRyYWZ0LXpob3UtcGltLXZycnAtMDENCj4+IA0KPj4gSGkgWGlhb2h1LA0KPj4gDQo+ PiBBY3R1YWxseSBJIHdvdWxkIHNheSBpdCBpcyBub3QgdHJ1ZSB0aGF0IHRoZSBuZXcgZHJhZnQg aXMgImlycmVsZXZhbnQiDQo+PnRvDQo+PiB1cHN0cmVhbSBsaW5rIGZhaWx1cmUsIHdoaWNoIGlz IG9uZSBvZiB0aGUgbWFueSBzY2VuYXJpb3MgdGhhdCB0aGUgbmV3DQo+PiBnZW5lcmFsIHNvbHV0 aW9uIGlzIHRyeWluZyB0byBhZGRyZXNzLg0KPg0KPldoYXQgYXJlIHRoZSBvdGhlciBzY2VuYXJp b3MgdGhhdCB0aGUgZ2VuZXJhbCBzb2x1dGlvbiBpcyB0cnlpbmcgdG8NCj5hZGRyZXNzPw0KPiAN Cj4+IElmIGN1c3RvbWVyIHJ1bnMgYW4gSUdQLCB0aGVuIHVwc3RyZWFtIGZhaWx1cmUgaXMgbm90 IGFuIGlzc3VlLiBPbiB0aGUNCj4+IG90aGVyIGhhbmQgaWYgcGVvcGxlIHdhbnQgdG8gdGhleSBj YW4gY29uZmlndXJlIFZSUlAgdG8gdHJhY2sgbGluaw0KPj4gZmFpbHVyZXMsIGJ1dCB0aGF0IHdh cyBub3QgdGhlIGZvY3VzIG9mIHRoZSBuZXcgZHJhZnQuIERpc2N1c3NpbmcgdGhlDQo+PiBkaWZm ZXJlbnQgb2JqZWN0cyB0aGF0IGRpZmZlcmVudCBWUlJQIGltcGxlbWVudGF0aW9ucyBtYXkgYWxs b3cgdXNlcnMgdG8NCj4+IHRyYWNrIGlzIG5vdCBvbmUgb2YgdGhlIHB1cnBvc2VzIG9mIHRoZSBu ZXcgZHJhZnQsIGFzIHRoYXQgaXMgbm90IG5lZWRlZA0KPj4gdG8gZXhwbGFpbiBob3cgVlJSUCBp bnRlcmFjdHMgd2l0aCBQSU0uDQo+PiANCj4+IE1vcmVvdmVyLCBpdCBpcyBkZWZpbml0ZWx5IHRy dWUgdGhhdCB0aGUgbmV3IGRyYWZ0IGlzIHByb3Bvc2luZyB0byBtYWtlDQo+PiBQSU0gRFIgYW5k IFZSUlAgTWFzdGVyIHJ1biBvbiB0aGUgc2FtZSByb3V0ZXIgYnkgYWRqdXN0aW5nIFBJTSBEUg0K Pj4gcHJpb3JpdHksIHdoaWNoIEkgYmVsaWV2ZSBpcyB0aGUgb2J2aW91cyB3YXkgdG8gbWFrZSBQ SU0gcmVzcG9uZCB0byBWUlJQDQo+PiBzdGF0ZSBjaGFuZ2UgYW5kIHNvbWV0aGluZyBib3RoIGRy YWZ0cyBzdXBwb3J0LiBJZiB5b3UgaGF2ZQ0KPj5uZXcvZGlmZmVyZW50DQo+PiB0aG91Z2h0cyBv biB0aGlzLCBwbGVhc2Ugc2hhcmUuDQo+PiANCj4+IFNvIGluIGFkZGl0aW9uIHRvIHRoYXQgb2J2 aW91cyBwYXJ0IHNoYXJlZCBieSBib3RoIGRyYWZ0cywgbWF5IEkga25vdw0KPj53aGF0DQo+PiB0 ZWNobmljYWwgY29udGVudC9kZXRhaWxzIHlvdSdkIHN1Z2dlc3QgdG8gbWVyZ2UgYmV0d2VlbiB0 aGUgdHdvIGRyYWZ0cz8NCj4NCj5JTUhPLCB0aGF0ICJvYnZpb3VzIiBwYXJ0IGlzIHRoZSBvbmx5 IHByYWN0aWNhbCBwcm9ibGVtIHRoYXQgbmVlZHMgdG8gYmUNCj5zb2x2ZWQuIFRoZSB0cmFuc2l0 IExBTiBzY2VuYXJpbyBpcyBhIGZha2Ugb25lLCB3aGljaCBoYXMgYmVlbiBleHBsYWluZWQNCj5p biBhIHByZXZpb3VzIGVtYWlsLg0KPg0KPkJlc3QgcmVnYXJkcywNCj5YaWFvaHUNCj4gDQo+PiBU aGFua3MsDQo+PiBXZWkNCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IE9uIDYvNC8x MyA4OjE5IFBNLCAiWHV4aWFvaHUiIDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4+IA0K Pj4gPkhpIFdlaSwNCj4+ID4NCj4+ID4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4gPj4gt6K8/sjL OiBXZWkgWmhvdSAod2VpemhvMikgW21haWx0bzp3ZWl6aG8yQGNpc2NvLmNvbV0NCj4+ID4+ILei y83KsbzkOiAyMDEzxOo21MIxyNUgMjo1Ng0KPj4gPj4gytW8/sjLOiBNaWtlIE1jQnJpZGU7IFBy YXNoYW50IEpoaW5ncmFuIChwamhpbmdyYSkNCj4+ID4+ILOty806IFJhaml2IEFzYXRpIChyYWpp dmEpOyBYdXhpYW9odTsgc2dhbmVzYW5AZXh0cmVtZW5ldHdvcmtzLmNvbTsNCj4+U3RpZw0KPj4g Pj4gVmVuYWFzOyBwaW1AaWV0Zi5vcmcNCj4+ID4+INb3zOI6IFJlOiBbcGltXSBjYWxsIGZvciBh ZG9wdGlvbjogZHJhZnQtemhvdS1waW0tdnJycC0wMQ0KPj4gPj4NCj4+ID4+IEhpLA0KPj4gPj4N Cj4+ID4+IFRoYW5rIHlvdSBhbGwgZm9yIHRoZSBjb21tZW50cyBhbmQgdGhvdWdodHMuIEkgYmVs aWV2ZSB0aGF0IHRoZSBvbGQNCj4+ID4+ZHJhZnQNCj4+ID4+IGlzIGFib3V0IHVwc3RyZWFtIGxp bmsgZmFpbHVyZXMsIHdoaWNoIGlzIG5vdCB3aGF0IHRoZSBuZXcgZHJhZnQgaXMNCj4+ID4+YWJv dXQuDQo+PiA+PiBUaGUgbmV3IGRyYWZ0IGlzIGFib3V0IGhvdyB0byBzdXBwb3J0IFBJTSBhbmQg VlJSUCBpbiBnZW5lcmFsDQo+Pmluc3RlYWQgb2YNCj4+ID4+IGZvY3VzaW5nIG9uIHRoZSBvYmpl Y3QgYmVpbmcgdHJhY2tlZC4NCj4+ID4NCj4+ID5JZiB5b3VyIGRyYWZ0IGlzIGlycmVsZXZhbnQg dG8gdXBzdHJlYW0gbGluayBmYWlsdXJlIHNjZW5hcmlvLCB3aGF0J3MNCj4+dGhlDQo+PiA+bW90 aXZhdGlvbiBmb3IgbWFraW5nIHRoZSBQSU0gRFIgYW5kIHRoZSBWUlJQIG1hc3RlciBhbHdheXMg cnVuIG9uIHRoZQ0KPj4gPnNhbWUgcm91dGVyPyBJbiBvdGhlciB3b3Jkcywgd2hhdCdzIHRoZSBw cm9ibGVtIHdoZW4gdGhlIFBJTSBEUiBkb2Vzbid0DQo+PiA+cnVuIG9uIHRoZSBWUlJQIG1hc3Rl ciByb3V0ZXI/IEl0IHNlZW1zIHRoYXQgdGhlIGJlbG93IHRleHQgcXVvdGVkIGZyb20NCj4+ID55 b3VyIGRyYWZ0IGRvZXNuJ3QgcmVhbGx5IHN0YXRlIHRoZSBGSU5BTCBwcm9ibGVtLiBJTUhPLCBp dCBkb2Vzbid0DQo+PiA+bWF0dGVyIHdoZXRoZXIgb3Igbm90IHRoZSBtdWx0aWNhc3QgdHJhZmZp YyBpcyBmb3J3YXJkZWQgYnkgdGhlIFZSUlANCj4+ID5tYXN0ZXIgcm91dGVyLiBJbiBhZGRpdGlv biwgInRvIGVuc3VyZSB0aGF0IHRoZSBQSU0gRFIgaXMgYWx3YXlzIGFibGUNCj4+dG8NCj4+ID5m b3J3YXJkIFBJTSBKb2luL1BydW5lIG1lc3NhZ2UgdG93YXJkcyBSUCBvciBGSFIiLCBpdCBkb2Vz bid0IHJlcXVpcmUNCj4+dGhlDQo+PiA+UElNIERSIHJ1bnMgb24gdGhlIFZSUlAgbWFzdGVyIHJv dXRlciBlaXRoZXIuDQo+PiA+DQo+PiA+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K Pj4gPiAgIlBJTSBoYXMgbm8gaW5oZXJlbnQgcmVkdW5kYW5jeSBjYXBhYmlsaXRpZXMgYW5kIGl0 cyBvcGVyYXRpb24gaXMNCj4+ID4gICBjb21wbGV0ZWx5IGluZGVwZW5kZW50IG9mIFZSUlAgZ3Jv dXAgc3RhdGVzLiAgQXMgYSByZXN1bHQsIElQDQo+PiA+ICAgbXVsdGljYXN0IHRyYWZmaWMgaXMg Zm9yd2FyZGVkIG5vdCBuZWNlc3NhcmlseSBieSB0aGUgc2FtZSBkZXZpY2UgYXMNCj4+ID4gICBp cyBlbGVjdGVkIGJ5IFZSUlAuICBUaGUgVlJSUCBBd2FyZSBQSU0gZmVhdHVyZSBwcm92aWRlcyBj b25zaXN0ZW50DQo+PiA+ICAgSVAgbXVsdGljYXN0IGZvcndhcmRpbmcgaW4gYSByZWR1bmRhbnQg bmV0d29yayB3aXRoIHZpcnR1YWwgcm91dGluZw0KPj4gPiAgIGdyb3VwcyBlbmFibGVkLg0KPj4g Pg0KPj4gPiAgIEluIGEgbXVsdGktYWNjZXNzIHNlZ21lbnQgKHN1Y2ggYXMgTEFOKSwgUElNIGRl c2lnbmF0ZWQgcm91dGVyIChEUikNCj4+ID4gICBlbGVjdGlvbiBpcyB1bmF3YXJlIG9mIHRoZSBy ZWR1bmRhbmN5IGNvbmZpZ3VyYXRpb24sIGFuZCB0aGUgZWxlY3RlZA0KPj4gPiAgIERSIGFuZCBW UlJQIG1hc3RlciByb3V0ZXIgKE1SKSBtYXkgbm90IGJlIHRoZSBzYW1lIHJvdXRlci4gIEluIG9y ZGVyDQo+PiA+ICAgdG8gZW5zdXJlIHRoYXQgdGhlIFBJTSBEUiBpcyBhbHdheXMgYWJsZSB0byBm b3J3YXJkIFBJTSBKb2luL1BydW5lDQo+PiA+ICAgbWVzc2FnZSB0b3dhcmRzIFJQIG9yIEZIUiwg dGhlIFZSUlAgTVIgYmVjb21lcyB0aGUgUElNIERSIChpZiB0aGVyZQ0KPj4gPiAgIGlzIG9ubHkg b25lIFZSUlAgZ3JvdXApLi4uLiINCj4+ID49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQo+PiA+DQo+PiA+QmVzdCByZWdhcmRzLA0KPj4gPlhpYW9odQ0KPj4gPg0KPj4gPj4gSWYgdGhl IFdHIHRoaW5rIHRoZSB1cHN0cmVhbSBsaW5rIGZhaWx1cmUgc2NlbmFyaW8gc2hvdWxkIGJlDQo+ PmRpc2N1c3NlZA0KPj4gPj5pbg0KPj4gPj4gZGV0YWlsIGluIHRoZSBuZXcgZHJhZnQsIHRoZW4g SSdtIGNvbXBsZXRlbHkgZmluZSB3aXRoIG1lcmdpbmcuDQo+PiA+Pk1vcmVvdmVyLA0KPj4gPj4g aWYgdGhlIG5ldyBkcmFmdCBpcyBhZG9wdGVkIGluIGl0cyBjdXJyZW50IHNoYXBlLCB0aGVuIHRo ZSBXRyBjYW4NCj4+YWx3YXlzDQo+PiA+PiBkZWNpZGUgdG8gaW5jbHVkZSB0aGUgdXBzdHJlYW0g bGluayBmYWlsdXJlIHNjZW5hcmlvIGxhdGVyLg0KPj4gPj4NCj4+ID4+IFRoYW5rcywNCj4+ID4+ IFdlaQ0KPj4gPj4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBPbiA1LzMxLzEz IDEyOjA2IEFNLCAiTWlrZSBNY0JyaWRlIiA8bW1jYnJpZGU3QGdtYWlsLmNvbT4gd3JvdGU6DQo+ PiA+Pg0KPj4gPj4gPlRoYW5rIHlvdSBmb3IgdGhlIHJlc3BvbnNlcy4NCj4+ID4+ID4NCj4+ID4+ ID5Tb21lIGZlZWwgdGhlIHR3byBkcmFmdHMgYXJlIGNvbXBsZXRlbHkgdW5yZWxhdGVkIHdoaWxl IG90aGVycyBmZWVsDQo+PiA+PiA+dGhleSBhcmUgY29tcGxldGVseSByZWxhdGVkLiBJbiBlaXRo ZXIgY2FzZSwgYXJlIHlvdSwgd2hvIGZlZWwgdGhleQ0KPj4gPj4gPmFyZSByZWxhdGVkLCBzYXlp bmcgeW91IG9wcG9zZSB0aGUgYWRvcHRpb24gb2YNCj4+ZHJhZnQtemhvdS1waW0tdnJycC0wMT8N Cj4+ID4+ID5XZSBjYW4gaW5mZXIgdGhhdCBpcyB0aGUgY2FzZSBidXQgSSBoYXZlbid0IGhlYXJk IGV4cGxpY2l0bHkgc3RhdGVkDQo+PiA+PiA+b3Bwb3NpdGlvbiB0byBhZG9wdGlvbi4gV2Ugbm93 IGhhdmUgc2V2ZXJhbCBjaG9pY2VzIGZvcg0KPj4gPj4gPmRyYWZ0LXpob3UtcGltLXZycnAsIGxl dCBtZSB0cnkgYm9pbGluZyBpdCBkb3duIHRvIDM6DQo+PiA+PiA+DQo+PiA+PiA+MS4gYWRvcHQg ZHJhZnQtemhvdS1waW0tdnJycC0wMSBhcyBpcw0KPj4gPj4gPjIuIGFkb3B0IGRyYWZ0LXpob3Ut cGltLXZycnAtMDEgb25seSBhZnRlcg0KPj4gPj4gPmRyYWZ0LXh1LXBpbS1kcnByaW9yaXR5LWF1 dG8tYWRqdXN0bWVudCBpcyByZWZlcmVuY2VkLg0KPj4gPj4gPjMuIG1lcmdlIHRoZSBkcmFmdHMN Cj4+ID4+ID4NCj4+ID4+ID5JbiBlaXRoZXIgY2FzZSB0aGUgYXV0aG9ycyBzaG91bGQgcmV2aXZl IHRoZSBleHBpcmVkDQo+PiA+PiA+ZHJhZnQteHUtcGltLWRycHJpb3JpdHktYXV0by1hZGp1c3Rt ZW50LTAzIGZvciBjb25zaWRlcmF0aW9uIHdpdGhpbg0KPj4gPj4gPnRoZSB3ZyBpcnJlZ2FyZGxl c3Mgb2YgdnJycC0wMSBhZG9wdGlvbiBvdXRjb21lLg0KPj4gPj4gPg0KPj4gPj4gPldoYXQgc2F5 IHllPw0KPj4gPj4gPg0KPj4gPj4gPm1pa2UNCj4+ID4+ID4NCj4+ID4+ID5PbiBUaHUsIE1heSAy MywgMjAxMyBhdCAyOjA4IEFNLCBQcmFzaGFudCBKaGluZ3JhbiAocGpoaW5ncmEpDQo+PiA+PiA+ PHBqaGluZ3JhQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiA+PiA+PiBIaSBNaWtlLA0KPj4gPj4gPj4N Cj4+ID4+ID4+IEkgYWdyZWUgd2l0aCBSYWppdiwgYm90aCBkcmFmdHMgYXJlIHRyeWluZyB0byBz b2x2ZSB0aGUgc2FtZQ0KPj4gPj4gPj5pc3N1ZS4uLi50aGF0IHRvbyBpbiBhbG1vc3Qgc2ltaWxh ciB3YXkuDQo+PiA+PiA+Pg0KPj4gPj4gPj4gLQ0KPj4gPj4gPj4gUmVnYXJkcywNCj4+ID4+ID4+ IFByYXNoYW50IEpoaW5ncmFuDQo+PiA+PiA+PiBOT1NURyBUTUUgLSBTUCBXaS1GaQ0KPj4gPj4g Pj4NCj4+ID4+ID4+IGh0dHA6Ly93d3dpbi5jaXNjby5jb20vaW9zL3RlY2gvbW9iaWxlL3Byb3h5 aXB2Ni8NCj4+ID4+ID4+IGh0dHA6Ly93d3dpbi5jaXNjby5jb20vaW9zL3RlY2gvYnJvYWRiYW5k DQo+PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ID4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiA+PiA+PiBGcm9tOiBSYWppdiBBc2F0aSAocmFqaXZhKQ0KPj4gPj4gPj4gU2VudDogVGh1 cnNkYXksIE1heSAyMywgMjAxMyAzOjA2IEFNDQo+PiA+PiA+PiBUbzogTWlrZSBNY0JyaWRlOyBY dXhpYW9odTsgc2dhbmVzYW5AZXh0cmVtZW5ldHdvcmtzLmNvbTsNCj4+IFByYXNoYW50DQo+PiA+ PiA+PkpoaW5ncmFuIChwamhpbmdyYSk7IFdlaSBaaG91ICh3ZWl6aG8yKQ0KPj4gPj4gPj4gQ2M6 IFN0aWcgVmVuYWFzOyBwaW1AaWV0Zi5vcmcNCj4+ID4+ID4+IFN1YmplY3Q6IFJFOiBbcGltXSBj YWxsIGZvciBhZG9wdGlvbjogZHJhZnQtemhvdS1waW0tdnJycC0wMQ0KPj4gPj4gPj4NCj4+ID4+ ID4+IEhpIE1pa2UsDQo+PiA+PiA+Pg0KPj4gPj4gPj4gSXQgc2VlbXMgdGhhdCBib3RoIGRyYWZ0 cyBzZWVtIHRvIHNvbHZlIG5lYXJseSB0aGUgc2FtZSBwcm9ibGVtDQo+PiA+PiA+PihtdWx0aXBs ZSByb3V0ZXJzIG9uIHRoZSBtdWx0aS1hY2Nlc3MgaW50ZXJmYWNlIGFuZCBleGlzdGVuY2Ugb2YN Cj4+ID4+ID4+Zmlyc3QtaG9wIHJlZHVuZGFuY3kgcHJvdG9jb2xzIGUuZy4gVlJSUCkuDQo+PiA+ PiA+Pg0KPj4gPj4gPj4gQ2hlZXJzLA0KPj4gPj4gPj4gUmFqaXYNCj4+ID4+ID4+DQo+PiA+PiA+ Pg0KPj4gPj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+Pj4gRnJvbTog TWlrZSBNY0JyaWRlIFttYWlsdG86bW1jYnJpZGU3QGdtYWlsLmNvbV0NCj4+ID4+ID4+PiBTZW50 OiBXZWRuZXNkYXksIE1heSAyMiwgMjAxMyAyOjE3IEFNDQo+PiA+PiA+Pj4gVG86IFh1eGlhb2h1 OyBzZ2FuZXNhbkBleHRyZW1lbmV0d29ya3MuY29tOyBSYWppdiBBc2F0aSAocmFqaXZhKTsNCj4+ ID4+ID4+PiBQcmFzaGFudCBKaGluZ3JhbiAocGpoaW5ncmEpOyBXZWkgWmhvdSAod2VpemhvMikN Cj4+ID4+ID4+PiBDYzogU3RpZyBWZW5hYXM7IE1pa2UgTWNCcmlkZTsgcGltQGlldGYub3JnDQo+ PiA+PiA+Pj4gU3ViamVjdDogUmU6IFtwaW1dIGNhbGwgZm9yIGFkb3B0aW9uOiBkcmFmdC16aG91 LXBpbS12cnJwLTAxDQo+PiA+PiA+Pj4NCj4+ID4+ID4+PiBGb2xrcywNCj4+ID4+ID4+Pg0KPj4g Pj4gPj4+IFdlIGhhdmUgdGhpcyBuZXcgZHJhZnQtemhvdS1waW0tdnJycC0wMSB3aGljaCB3ZSBh cmUgYWJvdXQgdG8NCj4+YWRvcHQNCj4+ID4+ID4+PiBpbnRvIHRoZSBwaW0gd2cuIEl0IGhhcyBi ZWVuIGJyb3VnaHQgdG8gdGhlIFdHcyBhdHRlbnRpb24gdGhhdA0KPj50aGVyZQ0KPj4gPj4gPj4+ IGlzIGEgb2xkZXIgZHJhZnQgKGRyYWZ0LXh1LXBpbS1kcnByaW9yaXR5LWF1dG8tYWRqdXN0bWVu dC0wMykNCj4+d2hpY2gNCj4+ID4+ID4+PiBtYXkgaGF2ZSBzb21lIG92ZXJsYXAgd2l0aCB0aGUg bmV3IG9uZS4gVGhhdCBvbGRlciBkcmFmdCBkb2VzDQo+PiA+PmNvbnRhaW4NCj4+ID4+ID4+PiBp bmZvcm1hdGlvbiBhYm91dCBWUlJQIGF3YXJlIFBJTSB3aGljaCBpcyBhdHRyaWJ1dGVkIHRvIFN0 aWcgaW4NCj4+dGhlDQo+PiA+PiA+Pj4gYWNrbm93bGVkZ2VtZW50cy4gSWYgdGhlIGZpdmUgb2Yg eW91IGF1dGhvcnMgZmVlbCB0aGF0IHRoZXJlIGlzDQo+PnNvbWUNCj4+ID4+ID4+PiB2YWxpZGl0 eSB0aGF0IHRoZSBvbGRlciBkcmFmdCBjb250YWlucyBzb21lIGluZm9ybWF0aW9uIGJlaW5nDQo+ PnVzZWQNCj4+ID4+aW4NCj4+ID4+ID4+PiB0aGUgbmV3IGRyYWZ0LCB5b3UgbWF5IHdhbnQgdG8g YWNrbm93bGVkZ2UgdGhhdCBpbiB0aGUNCj4+cmVmZXJlbmNlcyBvcg0KPj4gPj4gPj4+IGFja25v d2xlZGdlbWVudHMuIEl0IGFwcGVhcnMgdGhlIGRyYWZ0cyBhcmUgZGlzc2ltaWxhciBlbm91Z2gg dG8NCj4+bm90DQo+PiA+PiA+Pj4gYmUgbWVyZ2VkIGJ1dCBJIG1heSBiZSB3cm9uZy4gUGxlYXNl IHNoYXJlIHlvdXIgb3BpbmlvbnMgb24gdGhpcw0KPj5zbw0KPj4gPj53ZQ0KPj4gPj4gPj4+IGNh biBlc3RhYmxpc2ggY29uc2Vuc3VzIHdpdGhpbiB0aGUgZ3JvdXAgYW5kIG1vdmUgdGhlIGRvY3Vt ZW50DQo+PiA+PmFsb25nLg0KPj4gPj4gPj4+DQo+PiA+PiA+Pj4gSWYgdGhlIGJyb2FkZXIgV0cg cGFydGljaXBhbnRzIGhhdmUgYW4gb3BpbmlvbiBvbiB0aGlzIHBsZWFzZQ0KPj5zcGVhaw0KPj4g Pj51cC4NCj4+ID4+ID4+Pg0KPj4gPj4gPj4+IHRoYW5rcywNCj4+ID4+ID4+PiBtaWtlDQo+PiA+ PiA+Pj4NCj4+ID4+ID4+PiBPbiBUaHUsIE1heSA5LCAyMDEzIGF0IDc6MzIgUE0sIFh1eGlhb2h1 IDx4dXhpYW9odUBodWF3ZWkuY29tPg0KPj4gPj4gd3JvdGU6DQo+PiA+PiA+Pj4gPiBIaSBhbGws DQo+PiA+PiA+Pj4gPg0KPj4gPj4gPj4+ID4gVGhpcyBkcmFmdCByZW1pbmRzIG1lIHRoYXQgdGhl cmUgaGFzIGJlZW4gYSBkcmFmdA0KPj4gPj4gPj4+DQo+PiA+PihodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC14dS1waW0tZHJwcmlvcml0eS1hdXRvLWFkanVzdG1lbnQtMDMNCj4+ID4+ ID4+PiApIHRocmVlIHllYXJzIGJlZm9yZSB3aGljaCB1c2VzIGFsbW9zdCB0aGUgc2FtZSB0ZWNo bm9sb2d5IHRvDQo+PnNhdmUNCj4+ID4+ID4+PiBhbG1vc3QgdGhlIHNhbWUgcHJvYmxlbS4NCj4+ ID4+ID4+PiA+DQo+PiA+PiA+Pj4gPiBUaGUgZm9sbG93aW5nIGlzIHF1b3RlZCBmcm9tIHRoZSBh Ym92ZSBkcmFmdDoNCj4+ID4+ID4+PiA+DQo+PiA+PiA+Pj4gPiAgICAiSW4gZmFjdCwgaWYgVlJS UCBpcyBydW4gb24gdGhlIFBJTSByb3V0ZXJzIGFuZCB0aGUgVlJSUCBoYXMNCj4+ID4+ID4+PmVu YWJsZWQNCj4+ID4+ID4+PiA+ICAgIHRoZSB1cHN0cmVhbSBsaW5rIHRyYWNraW5nIG1lY2hhbmlz bSwgdGhlIFBJTSBEUiBmYWlsb3Zlcg0KPj4gPj4gPj4+bWVjaGFuaXNtDQo+PiA+PiA+Pj4gPiAg ICBjb3VsZCBiZSBjb3VwbGVkIHdpdGggdGhlIFZSUlAgc28gYXMgdG8gcmV1c2UgdGhlIHVwc3Ry ZWFtDQo+PmxpbmsNCj4+ID4+ID4+PiA+ICAgIHRyYWNraW5nIG1lY2hhbmlzbSBvZiBWUlJQLiBP bmUgb3B0aW9uIGlzIHRvIHN5bmNocm9uaXplIHRoZQ0KPj4gPj5QSU0NCj4+ID4+ID4+PkRSDQo+ PiA+PiA+Pj4gPiAgICBwcmlvcml0eSB2YWx1ZSB0byB0aGUgVlJSUCBwcmlvcml0eSB2YWx1ZSBh bHdheXMuIEluIHRoaXMNCj4+d2F5LA0KPj4gPj50aGUNCj4+ID4+ID4+PiA+ICAgIFBJTSBEUiBh bmQgdGhlIFZSUlAgbWFzdGVyIHdpbGwgYWx3YXlzIHJ1biBvbiBhbiBpZGVudGljYWwNCj4+ID4+ cm91dGVyDQo+PiA+PiA+Pj5pZg0KPj4gPj4gPj4+ID4gICAgdGhlIFZSUlAgUHJlZW1wdF9Nb2Rl IGlzIHNldCB0byBUcnVlLiBBbm90aGVyIG9wdGlvbiBpcyB0bw0KPj4gbWFrZQ0KPj4gPj4gPj4+ dGhlDQo+PiA+PiA+Pj4gPiAgICBQSU0gRFIgYW5kIHRoZSBWUlJQIG1hc3RlciBydW4gb24gYW4g aWRlbnRpY2FsIHJvdXRlciBhbnl3YXkNCj4+ID4+ID4+PihpLmUuLA0KPj4gPj4gPj4+ID4gICAg cmVnYXJkbGVzcyB3aGV0aGVyIG9yIG5vdCB0aGUgVlJSUCBQcmVlbXB0X01vZGUgaXMgVHJ1ZSku IFRvDQo+PiA+PiA+Pj5hY2hpZXZlDQo+PiA+PiA+Pj4gPiAgICB0aGlzIGdvYWwsIHRoZSBQSU0g RFIgcHJpb3JpdHkgb2YgdGhlIFZSUlAgbWFzdGVyIHJvdXRlcg0KPj5TSE9VTEQNCj4+ID4+ID4+ PiA+ICAgIGFsd2F5cyBiZSBzZXQgdG8gYSBoaWdoZXIgZml4ZWQgdmFsdWUgdGhhbiB0aGF0IG9m IHRoZSBWUlJQDQo+PiA+PnNsYXZlDQo+PiA+PiA+Pj4gPiAgICByb3V0ZXIgYXV0b21hdGljYWxs eS4iDQo+PiA+PiA+Pj4gPg0KPj4gPj4gPj4+ID4gQmVzdCByZWdhcmRzLA0KPj4gPj4gPj4+ID4g WGlhb2h1DQo+PiA+PiA+Pj4gPg0KPj4gPj4gPj4+ID4+IC0tLS0t08q8/tStvP4tLS0tLQ0KPj4g Pj4gPj4+ID4+ILeivP7IyzogcGltLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwaW0tYm91bmNl c0BpZXRmLm9yZ10gtPqx7Q0KPj4gPj4gPj4+IE1pa2UNCj4+ID4+ID4+PiA+PiBNY0JyaWRlDQo+ PiA+PiA+Pj4gPj4gt6LLzcqxvOQ6IDIwMTPE6jXUwjEwyNUgMzo0OA0KPj4gPj4gPj4+ID4+IMrV vP7IyzogcGltQGlldGYub3JnDQo+PiA+PiA+Pj4gPj4g1vfM4jogW3BpbV0gY2FsbCBmb3IgYWRv cHRpb246IGRyYWZ0LXpob3UtcGltLXZycnAtMDENCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+ID4+ IGRyYWZ0LXpob3UtcGltLXZycnAtMDEgd2FzIHByZXNlbnRlZCBpbiBvdXIgbW9zdCByZWNlbnQg cGltDQo+PiA+Pm1lZXRpbmcNCj4+ID4+ID4+PiA+PiBpbiBPcmxhbmRvLiA0IHBlb3BsZSB3ZXJl IGluIGZhdm9yIG9mIGFkb3B0aW5nIHRoZSBkcmFmdC4gWmVybw0KPj4gPj4gPj4+YWdhaW5zdC4N Cj4+ID4+ID4+PiA+PiBQbGVhc2UgcmVhZCB0aGUgZHJhZnQgKGl0cyBzaG9ydCkgYW5kIHByb3Zp ZGUgYW4gb3Bpbmlvbg0KPj5laXRoZXINCj4+ID4+d2F5DQo+PiA+PiA+Pj4gPj4gYnkgdGhlIGVu ZCBvZiBuZXh0IEZyaWRheSB0aGUgMTd0aC4NCj4+ID4+ID4+PiA+Pg0KPj4gPj4gPj4+ID4+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtemhvdS1waW0tdnJycC0wMS50eHQNCj4+ID4+ID4+ PiA+Pg0KPj4gPj4gPj4+ID4+IHRoYW5rcywNCj4+ID4+ID4+PiA+PiBtaWtlDQo+PiA+PiA+Pj4g Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ ID4+PiA+PiBwaW0gbWFpbGluZyBsaXN0DQo+PiA+PiA+Pj4gPj4gcGltQGlldGYub3JnDQo+PiA+ PiA+Pj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9waW0NCj4+ID4N Cj4NCg0K From mmcbride7@gmail.com Mon Jun 10 23:27:13 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9D821F9967 for ; Mon, 10 Jun 2013 23:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7unsc5h3xtzf for ; Mon, 10 Jun 2013 23:27:11 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D116921F9949 for ; Mon, 10 Jun 2013 23:27:11 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so5418250pbb.6 for ; Mon, 10 Jun 2013 23:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=K8OTfoU1xdlEkPeWU3MecrEID2BoWQdMGRLxCaRzNxQ=; b=I0vH9pdfwXNjrG3DFWkelLull7kZpVM0x5OBitSJ18kJSJdzNkb1K0Littl5QuUD+0 Z5s7xQIlDRQFBzS9CZ2/Xzd1yssZGqUjFaYdVKeBp1xuUiFudSdPHS4k3rIr4z5mab24 a6xl91bhchT7ASZRcf08rMbdpKdAE551aFnjtwZZtDz/eTXHLIA+p7DkaIzRqVUTQnzm LVvE047Pt3lsn9gpgyV/zzBneLbcMpuUQtJHfhV/A/l6v/leeza+P/Il5gzCBz3OE1vi w9e9QauSmCggxUbY+AKpXk4koD4roJ+bJgL5yZU2skRu/XlEBuXb6vRT64uVHBZjzjzu Kk+A== MIME-Version: 1.0 X-Received: by 10.66.37.43 with SMTP id v11mr17112346paj.108.1370932031615; Mon, 10 Jun 2013 23:27:11 -0700 (PDT) Received: by 10.68.59.232 with HTTP; Mon, 10 Jun 2013 23:27:11 -0700 (PDT) Date: Mon, 10 Jun 2013 23:27:11 -0700 Message-ID: From: Mike McBride To: pim@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 06:27:13 -0000 This is a recently adopted draft and the authors feel it is now ready for progression. Its a short draft so we likely don't have a good excuse to not read it over the next week. And then please express an opinion on this drafts readiness for being sent to the IESG as an Informational RFC: http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt We will end this WGLC on June 24th. Please speak up before then. thanks, mike From william.atwood@concordia.ca Tue Jun 11 11:40:05 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CB521F9980 for ; Tue, 11 Jun 2013 11:40:05 -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 tZeYASVgAXfT for ; Tue, 11 Jun 2013 11:40:01 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id EA8B021F9412 for ; Tue, 11 Jun 2013 11:40:00 -0700 (PDT) Received: from [127.0.0.1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id r5BIdwvr029793 for ; Tue, 11 Jun 2013 14:39:58 -0400 Message-ID: <51B76F02.3080607@concordia.ca> Date: Tue, 11 Jun 2013 14:40:02 -0400 From: William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pim@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2013/06/11 14:39:58 EDT Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:40:05 -0000 Question: Is this document really "Informational"? It defines new protocol pieces and their semantics, and it requires IANA action. This sounds to me as if it should be standards track... Bill On 11/06/2013 2:27 AM, Mike McBride wrote: > This is a recently adopted draft and the authors feel it is now ready > for progression. Its a short draft so we likely don't have a good > excuse to not read it over the next week. And then please express an > opinion on this drafts readiness for being sent to the IESG as an > Informational RFC: > > http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt > > We will end this WGLC on June 24th. Please speak up before then. > > thanks, > mike > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From IPark@DIRECTV.com Tue Jun 11 13:22:21 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5792821F99F0 for ; Tue, 11 Jun 2013 13:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAOqR70JMvWX for ; Tue, 11 Jun 2013 13:22:02 -0700 (PDT) Received: from mx2.directv.com (mx2-out2.directv.com [147.21.176.200]) by ietfa.amsl.com (Postfix) with ESMTP id 42BC921F99F3 for ; Tue, 11 Jun 2013 13:21:37 -0700 (PDT) Received: from DMPEMPE005.LA.FRD.DIRECTV.com (147.22.180.232) by DMPEMPE002.prd.ext.directv.com (147.22.129.22) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 11 Jun 2013 14:21:34 -0600 Received: from DMPEMPE009.LA.FRD.DIRECTV.com ([169.254.2.226]) by DMPEMPE005.LA.FRD.DIRECTV.com ([147.22.180.232]) with mapi id 14.02.0309.002; Tue, 11 Jun 2013 14:21:35 -0600 From: "Park, Insik" To: "pim@ietf.org" Thread-Topic: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 Thread-Index: Ac5m4UP33pm3YSa1QqKyoU4ZsLOeGg== Date: Tue, 11 Jun 2013 20:21:35 +0000 Message-ID: <0EBB817028706B41BCA5DE213B8BB73F0374C9@DMPEMPE009.LA.FRD.DIRECTV.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.23.50.48] Content-Type: multipart/alternative; boundary="_000_0EBB817028706B41BCA5DE213B8BB73F0374C9DMPEMPE009LAFRDDI_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19936.001 X-TM-AS-Result: No--13.205800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 20:22:21 -0000 --_000_0EBB817028706B41BCA5DE213B8BB73F0374C9DMPEMPE009LAFRDDI_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I vote yes for WGLC. Insik --_000_0EBB817028706B41BCA5DE213B8BB73F0374C9DMPEMPE009LAFRDDI_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I vote yes for WGLC.

 

Insik

--_000_0EBB817028706B41BCA5DE213B8BB73F0374C9DMPEMPE009LAFRDDI_-- From PCHuang@DIRECTV.com Tue Jun 11 13:29:39 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D9B21F9A1F for ; Tue, 11 Jun 2013 13:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxIPfo60RXbA for ; Tue, 11 Jun 2013 13:29:33 -0700 (PDT) Received: from mx1.directv.com (mx1-out2.directv.com [147.21.65.100]) by ietfa.amsl.com (Postfix) with ESMTP id 05F0D21F9A19 for ; Tue, 11 Jun 2013 13:29:32 -0700 (PDT) Received: from PMPEMPE006.LA.FRD.DIRECTV.com (147.22.118.136) by PMPEMPE002.prd.ext.directv.com (147.22.12.68) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 11 Jun 2013 14:29:32 -0600 Received: from PMPEMPE008.LA.FRD.DIRECTV.com ([169.254.1.121]) by PMPEMPE006.LA.FRD.DIRECTV.com ([147.22.118.136]) with mapi id 14.02.0309.002; Tue, 11 Jun 2013 14:29:31 -0600 From: "Huang, Pang Chan (Daniel)" To: "pim@ietf.org" Thread-Topic: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 Thread-Index: Ac5m4mB4bAd0si/nSS+MjTLY+f5PZg== Date: Tue, 11 Jun 2013 20:29:31 +0000 Message-ID: <8F922AF23379B44BB8E4E28CF2B2EB5207543F@PMPEMPE008.LA.FRD.DIRECTV.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.23.50.134] Content-Type: multipart/alternative; boundary="_000_8F922AF23379B44BB8E4E28CF2B2EB5207543FPMPEMPE008LAFRDDI_" MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19936.002 X-TM-AS-Result: No--13.205800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 20:29:39 -0000 --_000_8F922AF23379B44BB8E4E28CF2B2EB5207543FPMPEMPE008LAFRDDI_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I say "YES" to the progress of this draft which is what we need for solving= some issues in our environment. Pang Chan (Daniel) --_000_8F922AF23379B44BB8E4E28CF2B2EB5207543FPMPEMPE008LAFRDDI_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I say “YES” to the progress of this draf= t which is what we need for solving some issues in our environment.

 

Pang Chan (Daniel)

--_000_8F922AF23379B44BB8E4E28CF2B2EB5207543FPMPEMPE008LAFRDDI_-- From Vsingh@directv.com Tue Jun 11 13:43:06 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2746921F99BC for ; Tue, 11 Jun 2013 13:43:06 -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 x4HXAflgzljS for ; Tue, 11 Jun 2013 13:43:00 -0700 (PDT) Received: from mx1.directv.com (mx1-out1.directv.com [147.21.65.99]) by ietfa.amsl.com (Postfix) with ESMTP id 50FBC21F957B for ; Tue, 11 Jun 2013 13:43:00 -0700 (PDT) Received: from PMPEMPE007.LA.FRD.DIRECTV.com (147.22.118.137) by PMPEMPE001.prd.ext.directv.com (147.22.12.67) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 11 Jun 2013 14:42:59 -0600 Received: from PMPEMPE010.LA.FRD.DIRECTV.com ([169.254.3.7]) by PMPEMPE007.LA.FRD.DIRECTV.com ([147.22.118.137]) with mapi id 14.02.0309.002; Tue, 11 Jun 2013 14:43:00 -0600 From: "Singh, Vaibhav" To: "pim@ietf.org" Thread-Topic: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 Thread-Index: Ac5m5EK1EbC8U96XRVy9nHKmiolJxQ== Date: Tue, 11 Jun 2013 20:42:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-10.2.0.2087-7.000.1014-19936.002 X-TM-AS-Result: No--1.722200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Singh, Vaibhav" List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 20:43:06 -0000 SGVsbG8sDQoNCkkgdm90ZSAieWVzIiB0b28uDQoNClRoYW5rcywNClZhaWJoYXYgU2luZ2gNCg== From agahian@yahoo.com Tue Jun 11 13:55:21 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B754621F901F for ; Tue, 11 Jun 2013 13:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neK6WGl5Z9Wq for ; Tue, 11 Jun 2013 13:54:47 -0700 (PDT) Received: from nm23-vm0.bullet.mail.ne1.yahoo.com (nm23-vm0.bullet.mail.ne1.yahoo.com [98.138.91.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAE721F8EF7 for ; Tue, 11 Jun 2013 13:54:46 -0700 (PDT) Received: from [98.138.226.176] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jun 2013 20:54:46 -0000 Received: from [98.138.89.168] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 11 Jun 2013 20:54:45 -0000 Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 11 Jun 2013 20:54:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 972795.94884.bm@omp1024.mail.ne1.yahoo.com Received: (qmail 94991 invoked by uid 60001); 11 Jun 2013 20:54:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1370984085; bh=4o9qU485U22V+Evehd4pfFHC9DtR/eXRvU/artaAkdo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=hLGGt9K1QM/8ryoXSrc4+FNOeSecg/fVzYAL32OIvGyH/qrKIM3plFXj0HX7hP6/FCqE0wZ46OAu3bVzebc35Khrx3cP7Id+6ya4DqO+CSTSJenSmMJuXkHqvMjl1eNvM9LRO+eYPYnwb6KL325Wm3GqIW0NrXRwCY62hsH+oCY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=XQO0jssYLNtu+rVIwAhKpB+L3usgHPQOfFGhS5onRSjizugZqbTf2Zmb+9054hurkEvutmibQWHPagb796CjJy+IdiLAWRzwwb6pAmYI36wcVLdphaktNj8HikS0/n1VNVNDwzWYri/EIK3YYEt29r6UBf9zA28xeYqeZXLrSgE=; X-YMail-OSG: MNiost8VM1km_3gpfODczouVAhMptxMN8PD67seK1zwWLV7 gKZ7OFWk5zni5mdsLoZLjq0tBiMV09i8l1OHerr0C90P_LzsZcAY.r0PCFss iWhkFMP3wIymwHFnHLfOuRWBXlqDDsGpBkQRGz6MGd2DoLsEgch7My1VEfgQ jY8BKZ.r5.K0VAYBbk1J4HLvQM5vDnWqWAZaxmR5KzpSA_V.Z5L4FjHK2ArS 3Y1331ki5zLe7eCsc6Oz_XjUTBOG4Pm.Yx6E75na.YUZQdIddVoN.yHef0VS smG9gq5xAiXPJsXxQ52jZxIc76tTIsBGeBjb0pCSf3Nme4iuMHFxybQRDwCB BLe1GISoh6WUngxr7Ba2lOCBZJtelYLTWWrTyUOgqKgk1GG46LVudc7He4mY UmL5QznCNlYhd0szInCLFSAXLJYKTr5HfZR.ry7d_g52ETMCVxYDskZ44_OX OROwO6PlXSr36myCl6ZP9LhIIfOa1qzgN0olhvf0XLHn6xMVJznjmBCuNw9f ln.XOX1DroBuQ Received: from [54.240.196.186] by web124704.mail.ne1.yahoo.com via HTTP; Tue, 11 Jun 2013 13:54:45 PDT X-Rocket-MIMEInfo: 002.001, SGVsbG8sCgpJIHZvdGUgaW4gZmF2b3Igb2YgdGhlwqBkcmFmdC1pZXRmLXBpbS1leHBsaWNpdC1ycGYtdmVjdG9yLTAwLgoKVGhhbmtzCkthbWJpeiBBZ2FoaWFuCkNDSUUjMjUzNDEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.146.552 Message-ID: <1370984085.82388.YahooMailNeo@web124704.mail.ne1.yahoo.com> Date: Tue, 11 Jun 2013 13:54:45 -0700 (PDT) From: Kambiz Agahian To: "pim@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1128933012-1852277482-1370984085=:82388" Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Kambiz Agahian List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 20:55:22 -0000 --1128933012-1852277482-1370984085=:82388 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello,=0A=0AI vote in favor of the=A0draft-ietf-pim-explicit-rpf-vector-00.= =0A=0AThanks=0AKambiz Agahian=0ACCIE#25341 --1128933012-1852277482-1370984085=:82388 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

I vote in favor of the draft-ietf-pim-explicit-rpf-vector-00.

Thanks
Kambiz Agahian
CCIE#25341
= --1128933012-1852277482-1370984085=:82388-- From stig@venaas.com Tue Jun 11 19:25:02 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E10C21F9B64 for ; Tue, 11 Jun 2013 19:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 JHBbH6Rpy+32 for ; Tue, 11 Jun 2013 19:25:01 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id B57BB21F9AD9 for ; Tue, 11 Jun 2013 19:25:01 -0700 (PDT) Received: from [10.21.89.205] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id E717282D4; Wed, 12 Jun 2013 04:24:56 +0200 (CEST) Message-ID: <51B7DD31.3090508@venaas.com> Date: Tue, 11 Jun 2013 19:30:09 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: William Atwood References: <51B76F02.3080607@concordia.ca> In-Reply-To: <51B76F02.3080607@concordia.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 02:25:02 -0000 Hi On 11.06.2013 11:40, William Atwood wrote: > Question: > > Is this document really "Informational"? It defines new protocol pieces > and their semantics, and it requires IANA action. This sounds to me as > if it should be standards track... I'm not sure if I see much need for this to be standards track. The solution has some shortcomings, and we may find better ways in the future to achieve what this attribute is trying to do. Also, when the WG decided to adopt the draft, it assumed to be Informational. This can certainly be changed if the WG wants though. Another question is whether this should be informational or experimental. It's not very clear to me, but after reading http://www.ietf.org/iesg/informational-vs-experimental.html I think informational is appropriate. I don't have a strong opinion though, and great if others in the WG can also state their opinion. I recommend reading the doc I linked to first though. Stig > Bill > > > On 11/06/2013 2:27 AM, Mike McBride wrote: >> This is a recently adopted draft and the authors feel it is now ready >> for progression. Its a short draft so we likely don't have a good >> excuse to not read it over the next week. And then please express an >> opinion on this drafts readiness for being sent to the IESG as an >> Informational RFC: >> >> http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt >> >> We will end this WGLC on June 24th. Please speak up before then. >> >> thanks, >> mike >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim >> > From internet-drafts@ietf.org Wed Jun 12 05:56:36 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69D021F8EEA; Wed, 12 Jun 2013 05:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, 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 jJYFGkOlauqt; Wed, 12 Jun 2013 05:56:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBFA21F9C05; Wed, 12 Jun 2013 05:56:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130612125635.6135.78869.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2013 05:56:35 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-rfc4601-update-survey-report-02.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 12:56:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Working Gr= oup of the IETF. Title : Survey Report on PIM-SM Implementations and Deployments Author(s) : Lianshu Zheng Zhaohui Zhang Rishabh Parekh Filename : draft-ietf-pim-rfc4601-update-survey-report-02.txt Pages : 15 Date : 2013-06-05 Abstract: This document provides supporting documentation to advance the Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol from IETF Proposed Standard to Internet Standard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601-update-survey-report There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-report-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pim-rfc4601-update-survey-rep= ort-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stig@venaas.com Wed Jun 12 09:54:13 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA2A21F9700 for ; Wed, 12 Jun 2013 09:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 1sxFnCOXatm4 for ; Wed, 12 Jun 2013 09:54:12 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 1C49121E804C for ; Wed, 12 Jun 2013 09:53:59 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 9094F8411; Wed, 12 Jun 2013 18:53:54 +0200 (CEST) Message-ID: <51B8A798.9000700@venaas.com> Date: Wed, 12 Jun 2013 09:53:44 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pim@ietf.org, Bharat Joshi , Bill Atwood References: <519BA747.1030201@venaas.com> <51A4F72C.9040507@venaas.com> <51AF982C.70408@venaas.com> In-Reply-To: <51AF982C.70408@venaas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-pim-rfc4601-update-survey-report@tools.ietf.org Subject: Re: [pim] Reminder: pim WGLC for draft-ietf-pim-rfc4601-update-survey-report-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 16:54:13 -0000 On 6/5/2013 12:57 PM, Stig Venaas wrote: > On 5/28/2013 11:27 AM, Stig Venaas wrote: >> This last call ends Sunday, we need more people to review this. > > Not many responses, but we got a few people responding asking for > some minor changes and stating that they think the doc is ready with > those changes. As this report has been presented to the WG and > discussed and the process is something we know the WG is behind, and > that this draft is in no way controversial (according to Mike and I), > the chairs agree that the document passed last call. > > We would in general like more responses, but at least in this case, > we believe it is sufficient. > > The WGLC comments need to be addressed though. Authors, please submit > a new version that addresses the comments as needed. If possible, we > want a new version that makes everyone who commented happy. We now got a new version http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-report-02 that I believe addresses the last call comments. Bharat and Bill, can you please confirm that this version addresses your concerns? Stig > Stig > >> Stig >> >> On 5/21/2013 9:56 AM, Stig Venaas wrote: >>> Hi >>> >>> We, the chairs, want to speed up the process of updating RFC 4601 >>> and as a next step we want to make sure that you, the working group, >>> are happy with the implementation report. Once the group is happy, we >>> want to get the report published, and then finalize the updates to >>> 4601 based on that. >>> >>> The report results have been presented to the group. There were some >>> comments in the adoption call, and the adopted version took them into >>> account. The draft is available at >>> http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-report-00 >>> >>> >>> With this email we're starting a working group last call, ending >>> Sunday June 2nd. This is important work and we need your review. It >>> is the bases for updating one of our core RFCs, please read through >>> the report and tell us whether it is ready to be published. >>> >>> Stig >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From stig@venaas.com Wed Jun 12 10:10:56 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A39521F99FA for ; Wed, 12 Jun 2013 10:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 reY++Gosw5xx for ; Wed, 12 Jun 2013 10:10:56 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id CC63921F99F8 for ; Wed, 12 Jun 2013 10:10:55 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 3338F8420; Wed, 12 Jun 2013 19:10:53 +0200 (CEST) Message-ID: <51B8AB97.6020903@venaas.com> Date: Wed, 12 Jun 2013 10:10:47 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: William Atwood References: <51B76F02.3080607@concordia.ca> In-Reply-To: <51B76F02.3080607@concordia.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:10:56 -0000 On 6/11/2013 11:40 AM, William Atwood wrote: > Question: > > Is this document really "Informational"? It defines new protocol pieces > and their semantics, and it requires IANA action. This sounds to me as > if it should be standards track... Just want to add a comment regarding the IANA action. In this case it is OK to not be Standards Track because the registry requires "IETF Review". It does not require "Standards Action". These terms are explained in RFC 5226. Stig > Bill > > > On 11/06/2013 2:27 AM, Mike McBride wrote: >> This is a recently adopted draft and the authors feel it is now ready >> for progression. Its a short draft so we likely don't have a good >> excuse to not read it over the next week. And then please express an >> opinion on this drafts readiness for being sent to the IESG as an >> Informational RFC: >> >> http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt >> >> We will end this WGLC on June 24th. Please speak up before then. >> >> thanks, >> mike >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim >> > From bharat_joshi@infosys.com Wed Jun 12 10:14:40 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D7C11E80CC for ; Wed, 12 Jun 2013 10:14:40 -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 ifStG5gcp+AQ for ; Wed, 12 Jun 2013 10:14:35 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 162DC21F95EF for ; Wed, 12 Jun 2013 10:14:09 -0700 (PDT) X-TM-IMSS-Message-ID: <4f52888800004e09@infosys.com> Received: from BLRKECHUB05.ad.infosys.com ([10.66.236.45]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 4f52888800004e09 ; Wed, 12 Jun 2013 22:51:18 +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:50 +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:49 +0530 From: Bharat Joshi To: Stig Venaas , "pim@ietf.org" , Bill Atwood Thread-Topic: [pim] Reminder: pim WGLC for draft-ietf-pim-rfc4601-update-survey-report-00 Thread-Index: AQHOZ41kC1uXLE6S40CpL2jAkGcPcpkyUTFQ Date: Wed, 12 Jun 2013 17:13:48 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E67065@BLRKECMBX13.ad.infosys.com> References: <519BA747.1030201@venaas.com> <51A4F72C.9040507@venaas.com> <51AF982C.70408@venaas.com>,<51B8A798.9000700@venaas.com> In-Reply-To: <51B8A798.9000700@venaas.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 Cc: "draft-ietf-pim-rfc4601-update-survey-report@tools.ietf.org" Subject: Re: [pim] Reminder: pim WGLC for draft-ietf-pim-rfc4601-update-survey-report-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 17:14:40 -0000 I do not have anything more on this draft. I think we are now ready to move this to next stage. Regards, Bharat ________________________________________ From: Stig Venaas [stig@venaas.com] Sent: Wednesday, June 12, 2013 10:23 PM To: pim@ietf.org; Bharat Joshi; Bill Atwood Cc: draft-ietf-pim-rfc4601-update-survey-report@tools.ietf.org Subject: Re: [pim] Reminder: pim WGLC for draft-ietf-pim-rfc4601-update-s= urvey-report-00 On 6/5/2013 12:57 PM, Stig Venaas wrote: > On 5/28/2013 11:27 AM, Stig Venaas wrote: >> This last call ends Sunday, we need more people to review this. > > Not many responses, but we got a few people responding asking for > some minor changes and stating that they think the doc is ready with > those changes. As this report has been presented to the WG and > discussed and the process is something we know the WG is behind, and > that this draft is in no way controversial (according to Mike and I), > the chairs agree that the document passed last call. > > We would in general like more responses, but at least in this case, > we believe it is sufficient. > > The WGLC comments need to be addressed though. Authors, please submit > a new version that addresses the comments as needed. If possible, we > want a new version that makes everyone who commented happy. We now got a new version http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-report-02 that I believe addresses the last call comments. Bharat and Bill, can you please confirm that this version addresses your concerns? Stig > Stig > >> Stig >> >> On 5/21/2013 9:56 AM, Stig Venaas wrote: >>> Hi >>> >>> We, the chairs, want to speed up the process of updating RFC 4601 >>> and as a next step we want to make sure that you, the working group, >>> are happy with the implementation report. Once the group is happy, we >>> want to get the report published, and then finalize the updates to >>> 4601 based on that. >>> >>> The report results have been presented to the group. There were some >>> comments in the adoption call, and the adopted version took them into >>> account. The draft is available at >>> http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-repor= t-00 >>> >>> >>> With this email we're starting a working group last call, ending >>> Sunday June 2nd. This is important work and we need your review. It >>> is the bases for updating one of our core RFCs, please read through >>> the report and tell us whether it is ready to be published. >>> >>> Stig >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim **************** 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 william.atwood@concordia.ca Thu Jun 13 08:38:39 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD3B21F9A26 for ; Thu, 13 Jun 2013 08:38:39 -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 HmeOgbkSAoCo for ; Thu, 13 Jun 2013 08:38:35 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 23C9921F9A29 for ; Thu, 13 Jun 2013 08:38:31 -0700 (PDT) Received: from [127.0.0.1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id r5DFcSYR012861; Thu, 13 Jun 2013 11:38:28 -0400 Message-ID: <51B9E77C.70308@concordia.ca> Date: Thu, 13 Jun 2013 11:38:36 -0400 From: William Atwood Organization: Concordia University, Montreal User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stig Venaas , pim@ietf.org References: <519BA747.1030201@venaas.com> <51A4F72C.9040507@venaas.com> <51AF982C.70408@venaas.com> <51B8A798.9000700@venaas.com> In-Reply-To: <51B8A798.9000700@venaas.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2013/06/13 11:38:28 EDT Subject: Re: [pim] Reminder: pim WGLC for draft-ietf-pim-rfc4601-update-survey-report-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 15:38:39 -0000 I have read the two diff reports. Draft-01 resolved my concerns, and draft-02 has resolved all additional concerns raised by others. It is ready to be pushed to the IESG. Bill On 12/06/2013 12:53 PM, Stig Venaas wrote: > On 6/5/2013 12:57 PM, Stig Venaas wrote: >> On 5/28/2013 11:27 AM, Stig Venaas wrote: >>> This last call ends Sunday, we need more people to review this. >> >> Not many responses, but we got a few people responding asking for >> some minor changes and stating that they think the doc is ready with >> those changes. As this report has been presented to the WG and >> discussed and the process is something we know the WG is behind, and >> that this draft is in no way controversial (according to Mike and I), >> the chairs agree that the document passed last call. >> >> We would in general like more responses, but at least in this case, >> we believe it is sufficient. >> >> The WGLC comments need to be addressed though. Authors, please submit >> a new version that addresses the comments as needed. If possible, we >> want a new version that makes everyone who commented happy. > > We now got a new version > http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-report-02 > that I believe addresses the last call comments. Bharat and Bill, can > you please confirm that this version addresses your concerns? > > Stig > >> Stig >> >>> Stig >>> >>> On 5/21/2013 9:56 AM, Stig Venaas wrote: >>>> Hi >>>> >>>> We, the chairs, want to speed up the process of updating RFC 4601 >>>> and as a next step we want to make sure that you, the working group, >>>> are happy with the implementation report. Once the group is happy, we >>>> want to get the report published, and then finalize the updates to >>>> 4601 based on that. >>>> >>>> The report results have been presented to the group. There were some >>>> comments in the adoption call, and the adopted version took them into >>>> account. The draft is available at >>>> http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-report-00 >>>> >>>> >>>> >>>> With this email we're starting a working group last call, ending >>>> Sunday June 2nd. This is important work and we need your review. It >>>> is the bases for updating one of our core RFCs, please read through >>>> the report and tell us whether it is ready to be published. >>>> >>>> Stig >>>> _______________________________________________ >>>> pim mailing list >>>> pim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pim >>> >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >> >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From stig@venaas.com Thu Jun 13 11:03:02 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F90421F9A4E for ; Thu, 13 Jun 2013 11:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndHAWGGjXPs6 for ; Thu, 13 Jun 2013 11:03:01 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id CC93921F9A43 for ; Thu, 13 Jun 2013 11:03:00 -0700 (PDT) Received: from [10.154.208.99] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 867B785CF; Thu, 13 Jun 2013 20:02:58 +0200 (CEST) Message-ID: <51BA094B.9000008@venaas.com> Date: Thu, 13 Jun 2013 11:02:51 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: William Atwood References: <519BA747.1030201@venaas.com> <51A4F72C.9040507@venaas.com> <51AF982C.70408@venaas.com> <51B8A798.9000700@venaas.com> <51B9E77C.70308@concordia.ca> In-Reply-To: <51B9E77C.70308@concordia.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pim@ietf.org Subject: Re: [pim] Reminder: pim WGLC for draft-ietf-pim-rfc4601-update-survey-report-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 18:03:02 -0000 On 6/13/2013 8:38 AM, William Atwood wrote: > I have read the two diff reports. Draft-01 resolved my concerns, and > draft-02 has resolved all additional concerns raised by others. It is > ready to be pushed to the IESG. Thanks, we'll send this off to the IESG then. Of course if anyone else wants to have a look and respond, please do. But I believe it is ready then. Stig From jodahl@cisco.com Fri Jun 14 14:29:06 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF12021F9AA1 for ; Fri, 14 Jun 2013 14:29:06 -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 tnzV9VTzV7Ay for ; Fri, 14 Jun 2013 14:29:02 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B091521F9A16 for ; Fri, 14 Jun 2013 14:29:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13302; q=dns/txt; s=iport; t=1371245341; x=1372454941; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bygWR5/ENcxWX8gBq6cCYAvFjBc1yupc+54ff8VvRbY=; b=LBpstK0vVFaWQpW/ZqbqUCm5Mjz9ZD9BGsBk2/8TYl9bmCGQtUtL7+fS 4xKB9CRkEiOhwxCg9AOgE7SEq0Lv/uP0vE7O0Pb44ioM7eiKteAN1hgiB 8T5J684+S7PVUwvxUl1bcY/YiB5fgb8EJ1Zq0IAyDgzCYfoAZv3or8mta g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFABWKu1GtJXG+/2dsb2JhbABbgwkwrG2SIoELFnSCIwEBAQMBAQEBFSIUIAsFCwIBCBEDAQIBDAEICRAnCgETCggCBA4FCRICBIdbAwkGDLElA4hcjGOBIxCBBysHBgSCdWEDlV6BY4EpinWFJIMPgXE X-IronPort-AV: E=Sophos;i="4.87,868,1363132800"; d="scan'208";a="223036500" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 14 Jun 2013 21:29:00 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5ELT0Lu028358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 14 Jun 2013 21:29:00 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.169]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 14 Jun 2013 16:29:00 -0500 From: "Josh Dahl (jodahl)" To: "" CC: "pim@ietf.org" Thread-Topic: WGLC on draft-ietf-pim-explicit-rpf-vector-00 Thread-Index: AQHOaUYu222ebx67BEKwFEe97nNB0g== Date: Fri, 14 Jun 2013 21:28:59 +0000 Message-ID: <1F4C0D74-1277-44DE-A06B-45FA3DBDAA4A@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 21:29:06 -0000 I have reviewed and vote 'yes' for WGLC. Josh Dahl On Jun 12, 2013, at 11:11 AM, "pim-request@ietf.org" = wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to=20 >=20 > https://www.ietf.org/mailman/listinfo/pim >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send pim mailing list submissions to > pim@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/pim > or, via email, send a message with subject or body 'help' to > pim-request@ietf.org >=20 > You can reach the person managing the list at > pim-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of pim digest..." >=20 >=20 > Today's Topics: >=20 > 1. WGLC on draft-ietf-pim-explicit-rpf-vector-00 (Park, Insik) > 2. WGLC on draft-ietf-pim-explicit-rpf-vector-00 > (Huang, Pang Chan (Daniel)) > 3. WGLC on draft-ietf-pim-explicit-rpf-vector-00 (Singh, Vaibhav) > 4. WGLC on draft-ietf-pim-explicit-rpf-vector-00 (Kambiz Agahian) > 5. Re: WGLC on draft-ietf-pim-explicit-rpf-vector-00 (Stig Venaas) > 6. I-D Action: > draft-ietf-pim-rfc4601-update-survey-report-02.txt > (internet-drafts@ietf.org) > 7. Re: Reminder: pim WGLC for > draft-ietf-pim-rfc4601-update-survey-report-00 (Stig Venaas) > 8. Re: WGLC on draft-ietf-pim-explicit-rpf-vector-00 (Stig Venaas) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 11 Jun 2013 20:21:35 +0000 > From: "Park, Insik" > To: "pim@ietf.org" > Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 > Message-ID: > <0EBB817028706B41BCA5DE213B8BB73F0374C9@DMPEMPE009.LA.FRD.DIRECTV.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hello, >=20 > I vote yes for WGLC. >=20 > Insik > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: >=20 > ------------------------------ >=20 > Message: 2 > Date: Tue, 11 Jun 2013 20:29:31 +0000 > From: "Huang, Pang Chan (Daniel)" > To: "pim@ietf.org" > Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 > Message-ID: > <8F922AF23379B44BB8E4E28CF2B2EB5207543F@PMPEMPE008.LA.FRD.DIRECTV.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > All, >=20 > I say "YES" to the progress of this draft which is what we need for solvi= ng some issues in our environment. >=20 > Pang Chan (Daniel) > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: >=20 > ------------------------------ >=20 > Message: 3 > Date: Tue, 11 Jun 2013 20:42:59 +0000 > From: "Singh, Vaibhav" > To: "pim@ietf.org" > Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 > Message-ID: > Content-Type: text/plain; charset=3D"utf-8" >=20 > Hello, >=20 > I vote "yes" too. >=20 > Thanks, > Vaibhav Singh >=20 > ------------------------------ >=20 > Message: 4 > Date: Tue, 11 Jun 2013 13:54:45 -0700 (PDT) > From: Kambiz Agahian > To: "pim@ietf.org" > Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 > Message-ID: > <1370984085.82388.YahooMailNeo@web124704.mail.ne1.yahoo.com> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 > Hello, >=20 > I vote in favor of the?draft-ietf-pim-explicit-rpf-vector-00. >=20 > Thanks > Kambiz Agahian > CCIE#25341 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: >=20 > ------------------------------ >=20 > Message: 5 > Date: Tue, 11 Jun 2013 19:30:09 -0700 > From: Stig Venaas > To: William Atwood > Cc: pim@ietf.org > Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 > Message-ID: <51B7DD31.3090508@venaas.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > Hi >=20 > On 11.06.2013 11:40, William Atwood wrote: >> Question: >>=20 >> Is this document really "Informational"? It defines new protocol pieces >> and their semantics, and it requires IANA action. This sounds to me as >> if it should be standards track... >=20 > I'm not sure if I see much need for this to be standards track. The > solution has some shortcomings, and we may find better ways in the > future to achieve what this attribute is trying to do. Also, when the > WG decided to adopt the draft, it assumed to be Informational. This > can certainly be changed if the WG wants though. >=20 > Another question is whether this should be informational or=20 > experimental. It's not very clear to me, but after reading > http://www.ietf.org/iesg/informational-vs-experimental.html > I think informational is appropriate. >=20 > I don't have a strong opinion though, and great if others in the > WG can also state their opinion. I recommend reading the doc I > linked to first though. >=20 > Stig >=20 >> Bill >>=20 >>=20 >> On 11/06/2013 2:27 AM, Mike McBride wrote: >>> This is a recently adopted draft and the authors feel it is now ready >>> for progression. Its a short draft so we likely don't have a good >>> excuse to not read it over the next week. And then please express an >>> opinion on this drafts readiness for being sent to the IESG as an >>> Informational RFC: >>>=20 >>> http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt >>>=20 >>> We will end this WGLC on June 24th. Please speak up before then. >>>=20 >>> thanks, >>> mike >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >=20 >=20 >=20 > ------------------------------ >=20 > Message: 6 > Date: Wed, 12 Jun 2013 05:56:35 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: pim@ietf.org > Subject: [pim] I-D Action: > draft-ietf-pim-rfc4601-update-survey-report-02.txt > Message-ID: <20130612125635.6135.78869.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset=3D"utf-8" >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Protocol Independent Multicast Working G= roup of the IETF. >=20 > Title : Survey Report on PIM-SM Implementations and Deployme= nts > Author(s) : Lianshu Zheng > Zhaohui Zhang > Rishabh Parekh > Filename : draft-ietf-pim-rfc4601-update-survey-report-02.txt > Pages : 15 > Date : 2013-06-05 >=20 > Abstract: > This document provides supporting documentation to advance the > Protocol Independent Multicast - Sparse Mode (PIM-SM) > protocol from IETF Proposed Standard to Internet Standard. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-pim-rfc4601-update-survey-rep= ort >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-report-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pim-rfc4601-update-survey-r= eport-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 >=20 > ------------------------------ >=20 > Message: 7 > Date: Wed, 12 Jun 2013 09:53:44 -0700 > From: Stig Venaas > To: pim@ietf.org, Bharat Joshi , Bill > Atwood > Cc: draft-ietf-pim-rfc4601-update-survey-report@tools.ietf.org > Subject: Re: [pim] Reminder: pim WGLC for > draft-ietf-pim-rfc4601-update-survey-report-00 > Message-ID: <51B8A798.9000700@venaas.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > On 6/5/2013 12:57 PM, Stig Venaas wrote: >> On 5/28/2013 11:27 AM, Stig Venaas wrote: >>> This last call ends Sunday, we need more people to review this. >>=20 >> Not many responses, but we got a few people responding asking for >> some minor changes and stating that they think the doc is ready with >> those changes. As this report has been presented to the WG and >> discussed and the process is something we know the WG is behind, and >> that this draft is in no way controversial (according to Mike and I), >> the chairs agree that the document passed last call. >>=20 >> We would in general like more responses, but at least in this case, >> we believe it is sufficient. >>=20 >> The WGLC comments need to be addressed though. Authors, please submit >> a new version that addresses the comments as needed. If possible, we >> want a new version that makes everyone who commented happy. >=20 > We now got a new version > http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-report-02 > that I believe addresses the last call comments. Bharat and Bill, can > you please confirm that this version addresses your concerns? >=20 > Stig >=20 >> Stig >>=20 >>> Stig >>>=20 >>> On 5/21/2013 9:56 AM, Stig Venaas wrote: >>>> Hi >>>>=20 >>>> We, the chairs, want to speed up the process of updating RFC 4601 >>>> and as a next step we want to make sure that you, the working group, >>>> are happy with the implementation report. Once the group is happy, we >>>> want to get the report published, and then finalize the updates to >>>> 4601 based on that. >>>>=20 >>>> The report results have been presented to the group. There were some >>>> comments in the adoption call, and the adopted version took them into >>>> account. The draft is available at >>>> http://tools.ietf.org/html/draft-ietf-pim-rfc4601-update-survey-report= -00 >>>>=20 >>>>=20 >>>> With this email we're starting a working group last call, ending >>>> Sunday June 2nd. This is important work and we need your review. It >>>> is the bases for updating one of our core RFCs, please read through >>>> the report and tell us whether it is ready to be published. >>>>=20 >>>> Stig >>>> _______________________________________________ >>>> pim mailing list >>>> pim@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pim >>>=20 >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >>=20 >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim >=20 >=20 >=20 > ------------------------------ >=20 > Message: 8 > Date: Wed, 12 Jun 2013 10:10:47 -0700 > From: Stig Venaas > To: William Atwood > Cc: pim@ietf.org > Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 > Message-ID: <51B8AB97.6020903@venaas.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > On 6/11/2013 11:40 AM, William Atwood wrote: >> Question: >>=20 >> Is this document really "Informational"? It defines new protocol pieces >> and their semantics, and it requires IANA action. This sounds to me as >> if it should be standards track... >=20 > Just want to add a comment regarding the IANA action. In this case it > is OK to not be Standards Track because the registry requires "IETF > Review". It does not require "Standards Action". These terms are > explained in RFC 5226. >=20 > Stig >=20 >> Bill >>=20 >>=20 >> On 11/06/2013 2:27 AM, Mike McBride wrote: >>> This is a recently adopted draft and the authors feel it is now ready >>> for progression. Its a short draft so we likely don't have a good >>> excuse to not read it over the next week. And then please express an >>> opinion on this drafts readiness for being sent to the IESG as an >>> Informational RFC: >>>=20 >>> http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt >>>=20 >>> We will end this WGLC on June 24th. Please speak up before then. >>>=20 >>> thanks, >>> mike >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim >=20 >=20 > End of pim Digest, Vol 110, Issue 8 > *********************************** From bharat_joshi@infosys.com Sat Jun 15 02:10:49 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F054421F9B98 for ; Sat, 15 Jun 2013 02:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, 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 5uadZd82OzFS for ; Sat, 15 Jun 2013 02:10:43 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6070821F99FB for ; Sat, 15 Jun 2013 02:10:42 -0700 (PDT) X-TM-IMSS-Message-ID: <5d3fe9a7000fab98@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 5d3fe9a7000fab98 ; Sat, 15 Jun 2013 14:39:22 +0530 Received: from BLRKECHUB11.ad.infosys.com (10.66.236.46) by BLRKECHUB05.ad.infosys.com (10.66.236.45) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sat, 15 Jun 2013 14:40:12 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB11.ad.infosys.com ([fe80::883d:4303:7980:1456%11]) with mapi id 14.02.0318.004; Sat, 15 Jun 2013 14:40:12 +0530 From: Bharat Joshi To: "pim@ietf.org" Thread-Topic: Some questions/suggestions on draft-kurapati-dynamicrp-bgpmvpn Thread-Index: Ac5pp8/OvFl9U5owTaOi15Bc07I+OA== Date: Sat, 15 Jun 2013 09:10:11 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E7266A@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.37.13] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pim] Some questions/suggestions on draft-kurapati-dynamicrp-bgpmvpn X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 09:10:49 -0000 Hi, I read through this draft and have some questions/suggestions on the= same. Regards, Bharat =95 In BGP-MVPN RFC 6513, it says BSR messages may be transmitted over an= y PMSI. The only requirement is that it should be delivered to all the ot= her PEs in that MVPN. Now the abstract of this draft says, it can be done= using either I-PMSI or S-PMSI. I am not sure how it can be done using S-= PMSI. Is the selective PMSI is for ALL-PIM-ROUTERs IP address here. =95 In Abstract, can we replace 'this information' by 'BSR messages'? Its= mentioned at couple of places and I think it brings in more clarity. =95 In Introduction, "can access this RP information" -> "can access this= Group-to-RP mapping information". Or reword the sentence if it meant som= ething else. =95 In sentence, "However, carrying control messages like BSR in the data= tunnels is not always desirable", can we justify why it is not always de= sirable? =95 In Introduction, we just mention Group-to-RP mapping information mess= ages. Should we call this Bootstrap Messages? =95 In terminology, for existing terms, is not it better to refer to the = RFC where they are actually defined instead of defining them here again? =95 What is the need of passing BSR priority in BSR parameters? =95 There is one advantage PMSI has over using BGP is that PEs need not c= reate the whole BSR messages received from other PEs. Right? =95 The disadvantage of using BGP could be that any PIM extension would n= eed an update of how this new extension is handled in MVPN. Right? =95 Will it make sense to pass PIM native messages in some encapsulation = so that any current messages and future extensions are automatically take= n care of. =95 In section 4.2, 'Group prefix', would not we need a subnet-mask as we= ll because a specific group-to-RP mapping may cover a range of group addr= ess? =95 In all the sections, can all the parameters are clearly defined and h= ow they are populated? For example: in section 4.3, RP priority is not me= ntioned. =95 Can we rename BSR-BGP path attribute to BGP-PIM-BSR path attribute? =95 A small typo "receiver of BSM MUlticast" =95 In section 5, "carry BSR through BGP" -> "carry BSR messages through = BGP" =95 Please define BSM before the first usage? =95 Both BSR messages and BSM has been used. If possible, please use only= one of them. =95 "information carried in BSR is" -> "information carried in BSM is" =95 Please reword the following sentence: This document only describes how the information carried in BSR is redist= ributed into BGP at the ingress PEs, and how the remote PEs redistribute = this information from BGP back into BSR. 'redistribute' does not look like the right word for this. Also BSR shoul= d be BSM. =95 In section 5, it is mentioned that a PE could be a C-RP or BSR. How i= s this possible? PE is not part of a customer network so why can this be = a C-RP or C-BSR? =95 "configured as C-RP or BSR for" -> "configured as C-RP or C-BSR for" =95 "configured as BSR for a specific" -> "configured as C-BSR for a spec= ific" =95 Should not we mention that for how long a PE wait for all fragmented = BSMs for a specific group-range has been received? There should be a time= r running and these fragments should be discarded if all the packets are = not received by this time. If PE does not do this, someone can attack the= PE by sending fragmented BSMs and not sending all the fragments. =95 In section 5.1.3, I am not sure if the statement "The peer to the ing= ress PE can be a BGP route reflector." seems at the right place. =95 In section 5.1.3, what does "BSM Group-to-RP mapping calculation" mea= ns? What kind of calculation the egress PE does? =95 In section 5.2, "dynamic RP group-range-to-RP mappings" -> "dynamic G= roup-to-RP mappings" =95 In section 5.4, what does 'Dynamic RP advertisements' mean? =95 In section 5.4, in following sentence: BSR relies on variations of Reverse Path Forwarding (RPF) to ensure that = advertisement messages do not loop through the network. What does 'variations of RPF' means? =95 In section 5.5, what is the need of passing the BGR message informati= on using BGP if it anyway needs to send them natively using PMSI? Also, h= ow will a BGP route reflector handle such a case? So does not this mean B= GP method should be used only when all the PEs support it? =95 In section 6.1, small typo in "boundary is at at group prefix" =95 In section 6.2.1, at the end of first para, its not clear what needs = to be communicated via BGP. Is it that a RP is no more available for a gr= oup-prefix when the next BSR comes or when the RP expires, that this RP i= s no more available for a group-prefix? =95 In section 6.2.3, in following sentence: When an originating PE's local bootstrap module elects a new BSR, all the= old Group-to-RP mapping entries advertised by the previous BSR MUST be w= ithdrawn. Why does PE needs to withdraw the Group-to-RP mapping, won't it be automa= tically taken care when new BSMs are sent out? If some mappings are not a= vailable with new Elected BSR then they will anyway timeout as it would h= appen in other routers? =95 Should not 'Inter-operation with other methods" be explained in great= er details in section 6. =95 In Security Consideration, I think there should be some text which ta= lks about egress PE not receiving all the fragments and keeping the fragm= ents for some time. **************** 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 linus.luessing@web.de Sat Jun 15 22:30:57 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B63E21F9E4F for ; Sat, 15 Jun 2013 22:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] 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 Iv8Q62pdBbbB for ; Sat, 15 Jun 2013 22:30:51 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.17.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8A33A21F9E46 for ; Sat, 15 Jun 2013 22:30:43 -0700 (PDT) Received: from localhost ([46.246.38.42]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MgO9u-1V0gRk1L4I-00NlDd; Sun, 16 Jun 2013 07:30:24 +0200 Date: Sun, 16 Jun 2013 07:30:11 +0200 From: Linus =?utf-8?Q?L=C3=BCssing?= To: pim@ietf.org Message-ID: <20130616053011.GG28709@Linus-Debian> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Provags-ID: V03:K0:hW50vZl83yxhQBazrjvDWQyIn8hENsOsxBDcZ8JbamrDu6cyJNy vokxzBDrsC1ccewR+vZHb45VXLLuT0IL/R5emmFjfrcy5NluYUAgv8hGoHD3HhS3QJH/1vT lwePdO6MtbfpfY+EkZgFqbcaoepQmYfl8rZI9klmDrcpafU6dMeyA9BpO6tjLy7Y37d5XUi ArjZ4IOVPfLrQkPcVYUng== Subject: [pim] Snooping switches, RFC4541 and unspecified/zero IP source addresses for queries X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 17:50:49 -0000 Hi, I'm currently wondering about the implications of a subtle difference between MLDv1/v2 and IGMPv2/v3: While IGMP seems to have no problem with an all-zeroes IPv4 source address for a Query message, MLD specifically dissallows sending or processing any Query with an unspecified IPv6 source address (::) (RFC2710, section 6, "query received from a router with a lower IP address"; RFC3810, section 5.1.14). I'd therefore conclude, that for one thing an MLD snooping switch may only either perform its snooping and dropping of packets if it is capable of acting as a proper Querier (which means it must not if it has no link-local IPv6 address configured). Or if it is not able to act as a proper Querier then only if it detected a proper Querier on the link. I'd further conclude that RFC4541, section 2.1.1.1b) does not apply for IPv6 because a snooping switch may send valid MLD Queries, too, not just multicast routers, and would end up receiving multicast data it might not be interested in. This would however also mean, that if an MLD snooping switch is not capable of performing MRD according to RFC4286 then it may not perform any snooping and dropping of packets with multicast destination of scope greater than link-scope. (Or, alternatively if we wanted to adhear to RFC4541, section 2.1.1.1b) for IPv6, too, then we must not perform any querying at all and must stop any snooping and dropping if there is no proper Querier on the link - more on that below.) For IPv4 I'm not quite sure what to conclude yet. Does it mean that an IGMP snooping switch: a) Must never perform any querying and must not perform any snooping and dropping if it did not detect any Querier on the link because we would not get any periodic reports. (with the downsides of flooding multicast packets and possible delays when activating ports) b) Must perform querying with a zero-source IPv4 address only. (with the downside of possibly having a noisy link due to many zero-source queries if there are multiple IGMP snooping switches on a link) b.1) And must detect other, valid queriers and must refrain from querying if it detected one. b.2) And should detect other, valid queriers and should refrain from querying if it detected one. c) RFC4541, section 2.1.1.1b) should be ignored and an IGMP snooping switch should behave like the MLD snooping switch described above (except that it must not snoop and drop any IPv4 link-local multicast packets, packets from the 224.0.0.x range, due to RFC4541, section 2.1.2.2); and that it must not perform any snooping and dropping if it is not capable of performing MRD). (which doesn't seem to have any downsides other than violating an informational RFC?) Note that an option d) with an IGMP snooping switch performing a proper, valid IGMP Querier protocol (so with a non-zero IPv4 source address) - which would not have the downside of a)/b)/c) - together with RFC4541, section 2.1.1.1b) is not possible as we might become a black hole for multicast data which is supposed to get routed. I'd be very interested in hearing what others think, which of the stated conclusions and options are correct or wrong, or if there are more. And which of them should be prefered. Cheers, Linus From bharat_joshi@infosys.com Sun Jun 16 22:33:35 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826C321F9A5F for ; Sun, 16 Jun 2013 22:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.563 X-Spam-Level: X-Spam-Status: No, score=-8.563 tagged_above=-999 required=5 tests=[AWL=2.036, 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 r7XK1L-U0fuS for ; Sun, 16 Jun 2013 22:33:30 -0700 (PDT) Received: from kecgate06.infosys.com (kecgate06.infosys.com [122.98.14.33]) by ietfa.amsl.com (Postfix) with ESMTP id B9FA521F9A3F for ; Sun, 16 Jun 2013 22:33:29 -0700 (PDT) X-TM-IMSS-Message-ID: <669fc08a0013a143@infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 669fc08a0013a143 ; Mon, 17 Jun 2013 11:03:09 +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; Mon, 17 Jun 2013 11:02:52 +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; Mon, 17 Jun 2013 11:02:52 +0530 From: Bharat Joshi To: "pim@ietf.org" Thread-Topic: Few questions on RFC 5496 Thread-Index: Ac5rHBygYA4ija0pSPabX6kSxZmiSw== Date: Mon, 17 Jun 2013 05:32:52 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E747D6@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.200.132] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pim] Few questions on RFC 5496 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 05:33:35 -0000 Hi All, I just finished reading RFC 5496 to understand how RPF vector Join = attributes are defined and used. I have some questions on this RFC. I think we need an Errata to take care of some of these comments. Regards, Bharat =95 In section 3, typo in sentence: " Without the PIM extensions specified in this document, the core router = cannot determine where the send the Join, so the tree cannot be construct= ed" should be " Without the PIM extensions specified in this document, the core router = cannot determine where to send the Join, so the tree cannot be constructe= d" =95 In section 3.1, in following sentences: "Use of the attribute is, however, not restricted to the construction of = source trees. It may also be used to construct a shared tree. In this c= ase, the RPF Vector TLV contains the IP address of a Rendezvous Point (RP= )." Should not the RPF vector be using the source address of the Edge router = that should be used to reach the RP address for a given group instead of = RP address? Or am I missing something here? =95 In section 3.2, in following sentence: "The procedures in this document do not define a way for BSR messages to = be forwarded across a core in which the BSP IP address is not routable." What is BSP IP address? Should it be Elected BSR IP address? =95 In section 3.3.1, in following sentence, a small typo: Core 2, and subsequent core routers, will forwarding the Join along the V= ector (i.e., towards Edge 1) instead of trying to forward it towards S. should be Core 2, and subsequent core routers, will be forwarding the Join along th= e Vector (i.e., towards Edge 1) instead of trying to forward it towards S= . =95 RFC 5384 defined the second bit as 'E' 'End of Attributes' while RFC = 5496 defines it as 'S' 'Bottom of Stack'. Why is this different in the tw= o RFCs? **************** 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 Mon Jun 17 01:54:48 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C511621F9AEF for ; Mon, 17 Jun 2013 01:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[AWL=-0.304, 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 cMeaGhu9sHbZ for ; Mon, 17 Jun 2013 01:54:43 -0700 (PDT) Received: from KECGATE03.infosys.com (kecgate03.infosysconsulting.com [122.98.10.31]) by ietfa.amsl.com (Postfix) with ESMTP id A389421F9B2D for ; Mon, 17 Jun 2013 01:54:42 -0700 (PDT) X-TM-IMSS-Message-ID: <67659e1b00132563@infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id 67659e1b00132563 ; Mon, 17 Jun 2013 14:23:31 +0530 Received: from BLRKECHUB11.ad.infosys.com (10.66.236.46) by blrkechub03.ad.infosys.com (10.66.236.43) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Jun 2013 14:24:05 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB11.ad.infosys.com ([fe80::883d:4303:7980:1456%11]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 14:24:05 +0530 From: Bharat Joshi To: "pim@ietf.org" Thread-Topic: Few question/suggestions on 'Explicit RPF Vector' draft Thread-Index: Ac5rODfqFC4mrWLISz670IHBBZ76jA== Date: Mon, 17 Jun 2013 08:54:04 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E74866@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.200.132] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 08:54:48 -0000 Hi, I read through this draft and have some questions/suggestions on t= he same. Regards, Bharat =95 Abstract uses 'explicitly configured path sent in the PIM join'. Shou= ld we call this explicitly configured path or something else as the path = may not be configured in the system. Right? =95 In introduction, "In some applications it might be useful" -> "For so= me applications it might be useful". =95 Should we add a limit on number of RPF vectors in the stack? Is it ok= to have any number of RPF vectors in the stack as long as the maximum IP= packet length is not reached? =95 Should the RPF vector address be PIM neighbor's primary IP address or= it is fine even if it is one of the secondary IP address of a PIM neighb= or? =95 In introduction, in following sentence: If a router receiving an explicit RPF vector does not have a PIM neighbo= r matching the explicit RPF vector address it MUST NOT fall back to loose= ly routing the JOIN. Its not clear what should be done with the JOIN. Should it be discarded? = Should there be some counter maintained for such an action? =95 Can we add some text on what happens at a router when the last entry = in the explicit RPF vector stack is removed? It will have to do unicast r= oute lookup for either source or the RP depending upon the PIM JOIN. Righ= t? =95 What happens if a router does not have a PIM neighbor for the explici= t RPF vector at the top of the stack? Does he keep this information in ca= se this neighbor comes up to expedite the joining process or does he disc= ard this join as refresh will anyway take care of this though there may b= e some delay. =95 Should not this draft talk about join suppression? =95 Should not this draft talk about PIM Asserts and how they should be h= andled? =95 Should not this draft talk about how those PIM neighbors handle the P= IM JOIN which do not understand this particular attribute yet? **************** 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 stig@venaas.com Mon Jun 17 12:00:39 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AC821F8EDF for ; Mon, 17 Jun 2013 12:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 ND5vbICMRY-R for ; Mon, 17 Jun 2013 12:00:27 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 53F8521F9D73 for ; Mon, 17 Jun 2013 12:00:19 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id C5A917FC4; Mon, 17 Jun 2013 21:00:16 +0200 (CEST) Message-ID: <51BF5CBE.3000807@venaas.com> Date: Mon, 17 Jun 2013 12:00:14 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bharat Joshi References: <35347FBF2796F94E936EE76C0E6047ED32E747D6@BLRKECMBX13.ad.infosys.com> In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED32E747D6@BLRKECMBX13.ad.infosys.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "pim@ietf.org" Subject: Re: [pim] Few questions on RFC 5496 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:00:39 -0000 On 6/16/2013 10:32 PM, Bharat Joshi wrote: > Hi All, > > I just finished reading RFC 5496 to understand how RPF vector Join attributes are defined and used. I have some questions on this RFC. > > I think we need an Errata to take care of some of these comments. Thanks, looks like good comments. Please file an errata. Stig > Regards, > Bharat > > • In section 3, typo in sentence: > > " Without the PIM extensions specified in this document, the core router cannot determine where the send the Join, so the tree cannot be constructed" > > should be > > " Without the PIM extensions specified in this document, the core router cannot determine where to send the Join, so the tree cannot be constructed" > > • In section 3.1, in following sentences: > > "Use of the attribute is, however, not restricted to the construction of source trees. It may also be used to construct a shared tree. In this case, the RPF Vector TLV contains the IP address of a Rendezvous Point (RP)." > > Should not the RPF vector be using the source address of the Edge router that should be used to reach the RP address for a given group instead of RP address? Or am I missing something here? > > • In section 3.2, in following sentence: > > "The procedures in this document do not define a way for BSR messages to be forwarded across a core in which the BSP IP address is not routable." > > What is BSP IP address? Should it be Elected BSR IP address? > > • In section 3.3.1, in following sentence, a small typo: > > Core 2, and subsequent core routers, will forwarding the Join along the Vector (i.e., towards Edge 1) instead of trying to forward it towards S. > > should be > > Core 2, and subsequent core routers, will be forwarding the Join along the Vector (i.e., towards Edge 1) instead of trying to forward it towards S. > > • RFC 5384 defined the second bit as 'E' 'End of Attributes' while RFC 5496 defines it as 'S' 'Bottom of Stack'. Why is this different in the two RFCs? > > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > 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 has 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 reserves the > right to monitor and review the content of all messages sent to or from this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > From stig@venaas.com Mon Jun 17 12:20:25 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A7621F9D5C for ; Mon, 17 Jun 2013 12:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o30FrGBTUGhj for ; Mon, 17 Jun 2013 12:20:24 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 51AB921F9D6C for ; Mon, 17 Jun 2013 12:20:12 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 928467FB9; Mon, 17 Jun 2013 21:20:09 +0200 (CEST) Message-ID: <51BF6166.4080506@venaas.com> Date: Mon, 17 Jun 2013 12:20:06 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bharat Joshi References: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com> In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "pim@ietf.org" Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:20:25 -0000 Hi On 6/17/2013 1:54 AM, Bharat Joshi wrote: > Hi, > > I read through this draft and have some questions/suggestions on the same. > > Regards, > Bharat > > • Abstract uses 'explicitly configured path sent in the PIM join'. Should we call this explicitly configured path or something else as the path may not be configured in the system. Right? Right, I think calling it "explicit path" should be sufficient. > • In introduction, "In some applications it might be useful" -> "For some applications it might be useful". > > • Should we add a limit on number of RPF vectors in the stack? Is it ok to have any number of RPF vectors in the stack as long as the maximum IP packet length is not reached? I can't think of any reason to limit it. It wouldn't make sense to have more than 255 of course. > • Should the RPF vector address be PIM neighbor's primary IP address or it is fine even if it is one of the secondary IP address of a PIM neighbor? I think it's good to allow a secondary address, but it should be stated clearly. Note that for IPv6 it says that a global address must be used, hence for IPv6 it cannot be the primary address. > • In introduction, in following sentence: > > If a router receiving an explicit RPF vector does not have a PIM neighbor matching the explicit RPF vector address it MUST NOT fall back to loosely routing the JOIN. > > Its not clear what should be done with the JOIN. Should it be discarded? Should there be some counter maintained for such an action? > > • Can we add some text on what happens at a router when the last entry in the explicit RPF vector stack is removed? It will have to do unicast route lookup for either source or the RP depending upon the PIM JOIN. Right? I would think the last is processed just as the previous vectors. It will send it to that neighbor. But the join it sends, won't have any attributes, right? So the receiving router would then process the join as normal. I don't see that anything needs to be added here. > • What happens if a router does not have a PIM neighbor for the explicit RPF vector at the top of the stack? Does he keep this information in case this neighbor comes up to expedite the joining process or does he discard this join as refresh will anyway take care of this though there may be some delay. I think it could be discarded, waiting for the next periodic join. But it would be a possible optimization. Perhaps this could be a MAY? > • Should not this draft talk about join suppression? > > • Should not this draft talk about PIM Asserts and how they should be handled? Good points. > • Should not this draft talk about how those PIM neighbors handle the PIM JOIN which do not understand this particular attribute yet? I would assume according to 5384 if not specified. It might be good to still mention it though. Thanks for the detailed review. It certainly should help improve the document quality. Stig > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > 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 has 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 reserves the > right to monitor and review the content of all messages sent to or from this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > From stig@venaas.com Mon Jun 17 13:44:22 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F263321F9E55 for ; Mon, 17 Jun 2013 13:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vzAuCxUJ9UD for ; Mon, 17 Jun 2013 13:44:21 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id E83CD21F9E52 for ; Mon, 17 Jun 2013 13:44:20 -0700 (PDT) Received: from [10.154.208.99] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id 9012A7FC4; Mon, 17 Jun 2013 22:44:18 +0200 (CEST) Message-ID: <51BF751E.2050908@venaas.com> Date: Mon, 17 Jun 2013 13:44:14 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bharat Joshi References: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com> <51BF6166.4080506@venaas.com> In-Reply-To: <51BF6166.4080506@venaas.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "pim@ietf.org" Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 20:44:22 -0000 On 6/17/2013 12:20 PM, Stig Venaas wrote: > Hi > > On 6/17/2013 1:54 AM, Bharat Joshi wrote: >> Hi, >> >> I read through this draft and have some questions/suggestions >> on the same. I found one additional issue. It also uses "S" instead of "E" to mark end of stack. Stig >> Regards, >> Bharat >> >> • Abstract uses 'explicitly configured path sent in the PIM join'. >> Should we call this explicitly configured path or something else as >> the path may not be configured in the system. Right? > > Right, I think calling it "explicit path" should be sufficient. > >> • In introduction, "In some applications it might be useful" -> "For >> some applications it might be useful". >> >> • Should we add a limit on number of RPF vectors in the stack? Is it >> ok to have any number of RPF vectors in the stack as long as the >> maximum IP packet length is not reached? > > I can't think of any reason to limit it. It wouldn't make sense > to have more than 255 of course. > >> • Should the RPF vector address be PIM neighbor's primary IP address >> or it is fine even if it is one of the secondary IP address of a PIM >> neighbor? > > I think it's good to allow a secondary address, but it should be stated > clearly. Note that for IPv6 it says that a global address must be used, > hence for IPv6 it cannot be the primary address. > >> • In introduction, in following sentence: >> >> If a router receiving an explicit RPF vector does not have a PIM >> neighbor matching the explicit RPF vector address it MUST NOT fall >> back to loosely routing the JOIN. > > >> Its not clear what should be done with the JOIN. Should it be >> discarded? Should there be some counter maintained for such an action? >> >> • Can we add some text on what happens at a router when the last entry >> in the explicit RPF vector stack is removed? It will have to do >> unicast route lookup for either source or the RP depending upon the >> PIM JOIN. Right? > > I would think the last is processed just as the previous vectors. It > will send it > to that neighbor. But the join it sends, won't have any attributes, > right? So the receiving router would then process the join as normal. > I don't see that anything needs to be added here. > >> • What happens if a router does not have a PIM neighbor for the >> explicit RPF vector at the top of the stack? Does he keep this >> information in case this neighbor comes up to expedite the joining >> process or does he discard this join as refresh will anyway take care >> of this though there may be some delay. > > I think it could be discarded, waiting for the next periodic join. But it > would be a possible optimization. Perhaps this could be a MAY? > >> • Should not this draft talk about join suppression? >> >> • Should not this draft talk about PIM Asserts and how they should be >> handled? > > Good points. > >> • Should not this draft talk about how those PIM neighbors handle the >> PIM JOIN which do not understand this particular attribute yet? > > I would assume according to 5384 if not specified. It might be good to > still mention it though. > > Thanks for the detailed review. It certainly should help improve the > document quality. > > Stig > >> **************** CAUTION - Disclaimer ***************** >> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended >> solely >> for the use of the addressee(s). If you are not the intended >> recipient, please >> 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 has 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 >> reserves the >> right to monitor and review the content of all messages sent to or >> from this e-mail >> address. Messages sent to or from this e-mail address may be stored on >> the >> Infosys e-mail system. >> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim >> > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From bharat_joshi@infosys.com Mon Jun 17 20:43:29 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0706921F9C76 for ; Mon, 17 Jun 2013 20:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.859 X-Spam-Level: X-Spam-Status: No, score=-6.859 tagged_above=-999 required=5 tests=[AWL=-0.260, 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 PZPo++ZICIcQ for ; Mon, 17 Jun 2013 20:43:14 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2374121F9BB3 for ; Mon, 17 Jun 2013 20:43:13 -0700 (PDT) X-TM-IMSS-Message-ID: <6b871087001370ef@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 6b871087001370ef ; Tue, 18 Jun 2013 09:11:46 +0530 Received: from BLRKECHUB07.ad.infosys.com (10.66.236.117) by BLRKECHUB05.ad.infosys.com (10.66.236.45) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 18 Jun 2013 09:12:31 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB07.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 09:13:05 +0530 From: Bharat Joshi To: Stig Venaas Thread-Topic: [pim] Few question/suggestions on 'Explicit RPF Vector' draft Thread-Index: Ac5rODfqFC4mrWLISz670IHBBZ76jAAKVrsAABzdVgI= Date: Tue, 18 Jun 2013 03:43:04 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E74A75@BLRKECMBX13.ad.infosys.com> References: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com>, <51BF6166.4080506@venaas.com> In-Reply-To: <51BF6166.4080506@venaas.com> Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pim@ietf.org" Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 03:43:29 -0000 Hi Stig, Thanks for your response. You did not responsd to few of the quest= ions/suggestions. Please see few responses in line. Regards, Bharat > > =95 Should we add a limit on number of RPF vectors in the stack? Is i= t > ok to have any number of RPF vectors in the stack as long as the maximu= m > IP packet length is not reached? > > I can't think of any reason to limit it. It wouldn't make sense > to have more than 255 of course. Ok. I was looking at it more from restricting someone creating a PIM join= with huge number of explicit RPF vector and sending it out. It might be = unnecessary processing. > > =95 Should the RPF vector address be PIM neighbor's primary IP addres= s > or it is fine even if it is one of the secondary IP address of a PIM > neighbor? > > I think it's good to allow a secondary address, but it should be stated > clearly. Note that for IPv6 it says that a global address must be used, > hence for IPv6 it cannot be the primary address. Ok. I also saw that for IPv6, it clearly mention the global IPv6 address but = does not mention anything about IPv4. Whether it should use secondary addresses or not, it should be clearly st= ated to avoid any misinterpretation. > > =95 Can we add some text on what happens at a router when the last en= try > in the explicit RPF vector stack is removed? It will have to do unicast > route lookup for either source or the RP depending upon the PIM JOIN. > Right? > > I would think the last is processed just as the previous vectors. It > will send it > to that neighbor. But the join it sends, won't have any attributes, > right? So the receiving router would then process the join as normal. > I don't see that anything needs to be added here. I got what you are saying. You are right. The next router need not do any= special processing. > > =95 What happens if a router does not have a PIM neighbor for the > explicit RPF vector at the top of the stack? Does he keep this > information in case this neighbor comes up to expedite the joining > process or does he discard this join as refresh will anyway take care o= f > this though there may be some delay. > > I think it could be discarded, waiting for the next periodic join. But > it > would be a possible optimization. Perhaps this could be a MAY? Ok. > > =95 Should not this draft talk about how those PIM neighbors handle t= he > PIM JOIN which do not understand this particular attribute yet? > > I would assume according to 5384 if not specified. It might be good to > still mention it though. Ok. **************** 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 Mon Jun 17 20:44:48 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF0D21F9C8A for ; Mon, 17 Jun 2013 20:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.827 X-Spam-Level: X-Spam-Status: No, score=-6.827 tagged_above=-999 required=5 tests=[AWL=-0.228, 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 wE+mLiyxk-rV for ; Mon, 17 Jun 2013 20:44:44 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7051121F9C76 for ; Mon, 17 Jun 2013 20:44:43 -0700 (PDT) X-TM-IMSS-Message-ID: <6b53a7360006c0cb@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 6b53a7360006c0cb ; Tue, 18 Jun 2013 09:21:53 +0530 Received: from BLRKECHUB09.ad.infosys.com (10.66.236.139) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 18 Jun 2013 09:13:59 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by Blrkechub09.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 09:14:35 +0530 From: Bharat Joshi To: Stig Venaas Thread-Topic: [pim] Few questions on RFC 5496 Thread-Index: Ac5rHBygYA4ija0pSPabX6kSxZmiSwAQq+4AAB3LwlA= Date: Tue, 18 Jun 2013 03:44:34 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E74A81@BLRKECMBX13.ad.infosys.com> References: <35347FBF2796F94E936EE76C0E6047ED32E747D6@BLRKECMBX13.ad.infosys.com>, <51BF5CBE.3000807@venaas.com> In-Reply-To: <51BF5CBE.3000807@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pim@ietf.org" Subject: Re: [pim] Few questions on RFC 5496 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 03:44:48 -0000 Stig, Thanks for your response. Will file Erratas for these. Thanks, Bharat ________________________________________ From: Stig Venaas [stig@venaas.com] Sent: Tuesday, June 18, 2013 12:30 AM To: Bharat Joshi Cc: pim@ietf.org Subject: Re: [pim] Few questions on RFC 5496 On 6/16/2013 10:32 PM, Bharat Joshi wrote: > Hi All, > > I just finished reading RFC 5496 to understand how RPF vector Join= attributes are defined and used. I have some questions on this RFC. > > I think we need an Errata to take care of some of these comments. Thanks, looks like good comments. Please file an errata. Stig > Regards, > Bharat > > =95 In section 3, typo in sentence: > > " Without the PIM extensions specified in this document, the core router = cannot determine where the send the Join, so the tree cannot be constructed= " > > should be > > " Without the PIM extensions specified in this document, the core router = cannot determine where to send the Join, so the tree cannot be constructed" > > =95 In section 3.1, in following sentences: > > "Use of the attribute is, however, not restricted to the construction of = source trees. It may also be used to construct a shared tree. In this cas= e, the RPF Vector TLV contains the IP address of a Rendezvous Point (RP)." > > Should not the RPF vector be using the source address of the Edge router = that should be used to reach the RP address for a given group instead of RP= address? Or am I missing something here? > > =95 In section 3.2, in following sentence: > > "The procedures in this document do not define a way for BSR messages to = be forwarded across a core in which the BSP IP address is not routable." > > What is BSP IP address? Should it be Elected BSR IP address? > > =95 In section 3.3.1, in following sentence, a small typo: > > Core 2, and subsequent core routers, will forwarding the Join along the V= ector (i.e., towards Edge 1) instead of trying to forward it towards S. > > should be > > Core 2, and subsequent core routers, will be forwarding the Join along th= e Vector (i.e., towards Edge 1) instead of trying to forward it towards S. > > =95 RFC 5384 defined the second bit as 'E' 'End of Attributes' while RFC = 5496 defines it as 'S' 'Bottom of Stack'. Why is this different in the two = RFCs? > > > > **************** 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*** > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > From stig@venaas.com Mon Jun 17 20:50:49 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E568721F8BB7 for ; Mon, 17 Jun 2013 20:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 ANibyzQ2meN2 for ; Mon, 17 Jun 2013 20:50:49 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id EE56A21F9476 for ; Mon, 17 Jun 2013 20:50:48 -0700 (PDT) Received: from [10.21.144.104] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id A45AC7FD2; Tue, 18 Jun 2013 05:50:42 +0200 (CEST) Message-ID: <51BFDA4E.2050802@venaas.com> Date: Mon, 17 Jun 2013 20:55:58 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bharat Joshi References: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com>, <51BF6166.4080506@venaas.com> <35347FBF2796F94E936EE76C0E6047ED32E74A75@BLRKECMBX13.ad.infosys.com> In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED32E74A75@BLRKECMBX13.ad.infosys.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "pim@ietf.org" Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 03:50:50 -0000 On 17.06.2013 20:43, Bharat Joshi wrote: > Hi Stig, > > Thanks for your response. You did not responsd to few of the questions/suggestions. Yes. I just added my thoughts. You had some good questions that I didn't comment on. Let's see what the authors say. Stig > Please see few responses in line. > > Regards, > Bharat > >>> • Should we add a limit on number of RPF vectors in the stack? Is it >> ok to have any number of RPF vectors in the stack as long as the maximum >> IP packet length is not reached? >> >> I can't think of any reason to limit it. It wouldn't make sense >> to have more than 255 of course. > > Ok. I was looking at it more from restricting someone creating a PIM join with huge number of explicit RPF vector and sending it out. It might be unnecessary processing. > >>> • Should the RPF vector address be PIM neighbor's primary IP address >> or it is fine even if it is one of the secondary IP address of a PIM >> neighbor? >> >> I think it's good to allow a secondary address, but it should be stated >> clearly. Note that for IPv6 it says that a global address must be used, >> hence for IPv6 it cannot be the primary address. > > Ok. > > I also saw that for IPv6, it clearly mention the global IPv6 address but does not mention anything about IPv4. > > Whether it should use secondary addresses or not, it should be clearly stated to avoid any misinterpretation. > >>> • Can we add some text on what happens at a router when the last entry >> in the explicit RPF vector stack is removed? It will have to do unicast >> route lookup for either source or the RP depending upon the PIM JOIN. >> Right? >> >> I would think the last is processed just as the previous vectors. It >> will send it >> to that neighbor. But the join it sends, won't have any attributes, >> right? So the receiving router would then process the join as normal. >> I don't see that anything needs to be added here. > > I got what you are saying. You are right. The next router need not do any special processing. > >>> • What happens if a router does not have a PIM neighbor for the >> explicit RPF vector at the top of the stack? Does he keep this >> information in case this neighbor comes up to expedite the joining >> process or does he discard this join as refresh will anyway take care of >> this though there may be some delay. >> >> I think it could be discarded, waiting for the next periodic join. But >> it >> would be a possible optimization. Perhaps this could be a MAY? > > Ok. > >>> • Should not this draft talk about how those PIM neighbors handle the >> PIM JOIN which do not understand this particular attribute yet? >> >> I would assume according to 5384 if not specified. It might be good to >> still mention it though. > > Ok. > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > 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 has 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 reserves the > right to monitor and review the content of all messages sent to or from this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > From wwwrun@rfc-editor.org Mon Jun 17 22:53:27 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E4721F9D06 for ; Mon, 17 Jun 2013 22:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, 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 CCd-9bWDxbec for ; Mon, 17 Jun 2013 22:53:26 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BD5CA21F9D05 for ; Mon, 17 Jun 2013 22:53:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 223736211A; Mon, 17 Jun 2013 22:51:18 -0700 (PDT) To: ice@cisco.com, aboers@cisco.com, erosen@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, stig@venaas.com, mmcbride7@gmail.com From: RFC Errata System Message-Id: <20130618055118.223736211A@rfc-editor.org> Date: Mon, 17 Jun 2013 22:51:18 -0700 (PDT) X-Mailman-Approved-At: Tue, 18 Jun 2013 12:51:09 -0700 Cc: pim@ietf.org, bharat_joshi@infosys.com, rfc-editor@rfc-editor.org Subject: [pim] [Editorial Errata Reported] RFC5496 (3664) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 05:53:27 -0000 The following errata report has been submitted for RFC5496, "The Reverse Path Forwarding (RPF) Vector TLV". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5496&eid=3664 -------------------------------------- Type: Editorial Reported by: Bharat Joshi Section: 3 Original Text ------------- Without the PIM extensions specified in this document, the core router cannot determine where the send the Join, so the tree cannot be constructed. Corrected Text -------------- Without the PIM extensions specified in this document, the core router cannot determine where to send the Join, so the tree cannot be constructed. Notes ----- A small typo in "where the send the join". 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. -------------------------------------- RFC5496 (draft-ietf-pim-rpf-vector-08) -------------------------------------- Title : The Reverse Path Forwarding (RPF) Vector TLV Publication Date : March 2009 Author(s) : IJ. Wijnands, A. Boers, E. Rosen Category : PROPOSED STANDARD Source : Protocol Independent Multicast Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jun 17 22:57:30 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189C821F949F for ; Mon, 17 Jun 2013 22:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, 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 xt1JGa+ZR3B2 for ; Mon, 17 Jun 2013 22:57:29 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0D71121F8F7B for ; Mon, 17 Jun 2013 22:57:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B5A166211A; Mon, 17 Jun 2013 22:55:18 -0700 (PDT) To: ice@cisco.com, aboers@cisco.com, erosen@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, stig@venaas.com, mmcbride7@gmail.com From: RFC Errata System Message-Id: <20130618055518.B5A166211A@rfc-editor.org> Date: Mon, 17 Jun 2013 22:55:18 -0700 (PDT) X-Mailman-Approved-At: Tue, 18 Jun 2013 12:51:09 -0700 Cc: pim@ietf.org, bharat_joshi@infosys.com, rfc-editor@rfc-editor.org Subject: [pim] [Technical Errata Reported] RFC5496 (3665) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 05:57:30 -0000 The following errata report has been submitted for RFC5496, "The Reverse Path Forwarding (RPF) Vector TLV". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5496&eid=3665 -------------------------------------- Type: Technical Reported by: Bharat Joshi Section: 3.1 Original Text ------------- Use of the attribute is, however, not restricted to the construction of source trees. It may also be used to construct a shared tree. In this case, the RPF Vector TLV contains the IP address of a Rendezvous Point (RP). Corrected Text -------------- Use of the attribute is, however, not restricted to the construction of source trees. It may also be used to construct a shared tree. In this case, the RPF Vector TLV contains the IP address of the edge router which is to be used to reach the Rendezvous Point (RP). Notes ----- For a source tree, as per section 3.0, RPF Vector TLV contains the IP address of edge-1 which is to be used to reach the source. Similarly, for shared tree, RPF vector TLV should contain the IP address of the edge router which is to be used to reach RP. 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. -------------------------------------- RFC5496 (draft-ietf-pim-rpf-vector-08) -------------------------------------- Title : The Reverse Path Forwarding (RPF) Vector TLV Publication Date : March 2009 Author(s) : IJ. Wijnands, A. Boers, E. Rosen Category : PROPOSED STANDARD Source : Protocol Independent Multicast Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jun 17 23:05:17 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B242321F9D36 for ; Mon, 17 Jun 2013 23:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.096, 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 tJxe6LfAC5bh for ; Mon, 17 Jun 2013 23:05:17 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 15FD721F9BCC for ; Mon, 17 Jun 2013 23:05:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 515216211A; Mon, 17 Jun 2013 23:03:03 -0700 (PDT) To: ice@cisco.com, aboers@cisco.com, erosen@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, stig@venaas.com, mmcbride7@gmail.com From: RFC Errata System Message-Id: <20130618060308.515216211A@rfc-editor.org> Date: Mon, 17 Jun 2013 23:03:03 -0700 (PDT) X-Mailman-Approved-At: Tue, 18 Jun 2013 12:51:09 -0700 Cc: pim@ietf.org, bharat_joshi@infosys.com, rfc-editor@rfc-editor.org Subject: [pim] [Editorial Errata Reported] RFC5496 (3666) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 06:05:18 -0000 The following errata report has been submitted for RFC5496, "The Reverse Path Forwarding (RPF) Vector TLV". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5496&eid=3666 -------------------------------------- Type: Editorial Reported by: Bharat Joshi Section: 3.2 Original Text ------------- The procedures in this document do not define a way for BSR messages to be forwarded across a core in which the BSP IP address is not routable. Corrected Text -------------- The procedures in this document do not define a way for BSR messages to be forwarded across a core in which the BSR IP address is not routable. Notes ----- BSP IP address is not a term used in PIM BSR. I think it should be BSR IP address. 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. -------------------------------------- RFC5496 (draft-ietf-pim-rpf-vector-08) -------------------------------------- Title : The Reverse Path Forwarding (RPF) Vector TLV Publication Date : March 2009 Author(s) : IJ. Wijnands, A. Boers, E. Rosen Category : PROPOSED STANDARD Source : Protocol Independent Multicast Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jun 17 23:06:26 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C023921F9DBB for ; Mon, 17 Jun 2013 23:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.094, 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 yxxAmKvAacDb for ; Mon, 17 Jun 2013 23:06:26 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 33C4221F9DB6 for ; Mon, 17 Jun 2013 23:06:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9935C6211A; Mon, 17 Jun 2013 23:04:11 -0700 (PDT) To: ice@cisco.com, aboers@cisco.com, erosen@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, stig@venaas.com, mmcbride7@gmail.com From: RFC Errata System Message-Id: <20130618060412.9935C6211A@rfc-editor.org> Date: Mon, 17 Jun 2013 23:04:11 -0700 (PDT) X-Mailman-Approved-At: Tue, 18 Jun 2013 12:51:09 -0700 Cc: pim@ietf.org, bharat_joshi@infosys.com, rfc-editor@rfc-editor.org Subject: [pim] [Editorial Errata Reported] RFC5496 (3667) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 06:06:27 -0000 The following errata report has been submitted for RFC5496, "The Reverse Path Forwarding (RPF) Vector TLV". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5496&eid=3667 -------------------------------------- Type: Editorial Reported by: Bharat Joshi Section: 3.3.1 Original Text ------------- Core 2, and subsequent core routers, will forwarding the Join along the Vector (i.e., towards Edge 1) instead of trying to forward it towards S. Corrected Text -------------- Core 2, and subsequent core routers, will be forwarding the Join along the Vector (i.e., towards Edge 1) instead of trying to forward it towards S. Notes ----- A typo in "will forwarding the Join'. 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. -------------------------------------- RFC5496 (draft-ietf-pim-rpf-vector-08) -------------------------------------- Title : The Reverse Path Forwarding (RPF) Vector TLV Publication Date : March 2009 Author(s) : IJ. Wijnands, A. Boers, E. Rosen Category : PROPOSED STANDARD Source : Protocol Independent Multicast Area : Routing Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jun 17 23:10:58 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435AD21F8ADC for ; Mon, 17 Jun 2013 23:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.092, 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 HWTHGxebGcNS for ; Mon, 17 Jun 2013 23:10:57 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5D82D21F934B for ; Mon, 17 Jun 2013 23:10:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7363D6211A; Mon, 17 Jun 2013 23:08:38 -0700 (PDT) To: ice@cisco.com, aboers@cisco.com, erosen@cisco.com, stbryant@cisco.com, adrian@olddog.co.uk, stig@venaas.com, mmcbride7@gmail.com From: RFC Errata System Message-Id: <20130618060838.7363D6211A@rfc-editor.org> Date: Mon, 17 Jun 2013 23:08:38 -0700 (PDT) X-Mailman-Approved-At: Tue, 18 Jun 2013 12:51:09 -0700 Cc: pim@ietf.org, bharat_joshi@infosys.com, rfc-editor@rfc-editor.org Subject: [pim] [Editorial Errata Reported] RFC5496 (3668) X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 06:10:58 -0000 The following errata report has been submitted for RFC5496, "The Reverse Path Forwarding (RPF) Vector TLV". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5496&eid=3668 -------------------------------------- Type: Editorial Reported by: Bharat Joshi Section: 4 Original Text ------------- S bit: Bottom of Stack. If this bit is set, then this is the last TLV in the stack. Corrected Text -------------- E-bit: End of Attributes. If this bit is set, then this is the last TLV in the stack. Notes ----- RFC 5384 has defined the Join Attribute for PIM. RPF vector is one such Join attribute. RFC 5384 has defined the format for Join Attributes. RFC 5496 is not following that by calling the second bit as 'S bit' instead of 'E bit' though both bits represent the end-of-attributes TLVs. 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. -------------------------------------- RFC5496 (draft-ietf-pim-rpf-vector-08) -------------------------------------- Title : The Reverse Path Forwarding (RPF) Vector TLV Publication Date : March 2009 Author(s) : IJ. Wijnands, A. Boers, E. Rosen Category : PROPOSED STANDARD Source : Protocol Independent Multicast Area : Routing Stream : IETF Verifying Party : IESG From apoorva@cisco.com Wed Jun 19 15:51:00 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9AC21F9C78 for ; Wed, 19 Jun 2013 15:50:59 -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 FPJR6r4eWWt7 for ; Wed, 19 Jun 2013 15:50:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D7CA921F9C51 for ; Wed, 19 Jun 2013 15:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3371; q=dns/txt; s=iport; t=1371682254; x=1372891854; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=n/yLft9VDriPDMP+HfNxVlwwlIkPaX7qdpt9ZffJLOE=; b=j23GgGomhgP9do+H21ODRtDl+Lgp+mxSS06BvbuMx5c3lJQdV187FYQ9 F9XxymCOj/wa7Scf9yw5niq22NIM1iPQpqYGpullfXKu0ohIsvK2o1imC UdvleAEOIBP/paroyEXktIp4RA5JcXAENwq4CXAaEGXwbhDObhsi35O7t Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFALY0wlGtJV2Y/2dsb2JhbABagwl6vxuBABZ0giMBAQEEJxNLBAIBCBEEAQELFAkHMhQJCAEBBAESCIgGu36OC4EGOAaCemEDqQWDD4FpPw X-IronPort-AV: E=Sophos;i="4.87,900,1363132800"; d="scan'208";a="225019836" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 19 Jun 2013 22:50:53 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5JMorrI017376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 22:50:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 17:50:53 -0500 From: "Apoorva Karan (apoorva)" To: Bharat Joshi , "pim@ietf.org" Thread-Topic: Few question/suggestions on 'Explicit RPF Vector' draft Thread-Index: Ac5rODfqFC4mrWLISz670IHBBZ76jAB26jLw Date: Wed, 19 Jun 2013 22:50:52 +0000 Message-ID: <2CD445E94B8C344289ED02B6582A49DA116E475A@xmb-rcd-x06.cisco.com> References: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com> In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.167.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 22:51:00 -0000 Hi Bharat, Thanks a lot for your comments. Please see responses inline and please let = us know if you have more questions. -----Original Message----- From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of Bhara= t Joshi Sent: Monday, June 17, 2013 1:54 AM To: pim@ietf.org Subject: [pim] Few question/suggestions on 'Explicit RPF Vector' draft Hi, I read through this draft and have some questions/suggestions on the= same. Regards, Bharat * Abstract uses 'explicitly configured path sent in the PIM join'. Should w= e call this explicitly configured path or something else as the path may no= t be configured in the system. Right? =3D> Changed text =20 * In introduction, "In some applications it might be useful" -> "For some a= pplications it might be useful". =3D> Changed text * Should we add a limit on number of RPF vectors in the stack? Is it ok to = have any number of RPF vectors in the stack as long as the maximum IP packe= t length is not reached? =3D> There is no restriction on the number of RPF vectors in the stack. * Should the RPF vector address be PIM neighbor's primary IP address or it = is fine even if it is one of the secondary IP address of a PIM neighbor? =3D> There is no restriction to limit the vector address to the primary IP = address. Corrected the text. * In introduction, in following sentence: If a router receiving an explicit RPF vector does not have a PIM neighbor = matching the explicit RPF vector address it MUST NOT fall back to loosely r= outing the JOIN. Its not clear what should be done with the JOIN. Should it be discarded? Sh= ould there be some counter maintained for such an action? =3D> The packet may be processed and vector stack stored so that the upstre= am join may be triggered as soon as the neighbor comes up. Updated the text= .=20 * Can we add some text on what happens at a router when the last entry in t= he explicit RPF vector stack is removed? It will have to do unicast route l= ookup for either source or the RP depending upon the PIM JOIN. Right? =3D> After the last vector is popped, the PIM join is processed normally. I= believe this is obvious and doesn't need added text ? * What happens if a router does not have a PIM neighbor for the explicit RP= F vector at the top of the stack? Does he keep this information in case thi= s neighbor comes up to expedite the joining process or does he discard this= join as refresh will anyway take care of this though there may be some del= ay.=20 =3D> This is implementation specific. We have changed the wording to say th= at the vector stack may be stored. * Should not this draft talk about join suppression? =3D> Please refer to RFC 5496, same behavior applies to explicit rpf vector= . * Should not this draft talk about PIM Asserts and how they should be handl= ed? =3D> Please refer to RFC 5496, same behavior applies to explicit rpf vector= . * Should not this draft talk about how those PIM neighbors handle the PIM J= OIN which do not understand this particular attribute yet? =3D> RFC 5384 says that an attribute that isn't understood is dropped and n= ot forwarded. The same behavior applies to this attribute too. The result = will be that a regular PIM join will be send upstream of this router. Regards, Apoorva From bharat_joshi@infosys.com Wed Jun 19 20:23:59 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2690121F9048 for ; Wed, 19 Jun 2013 20:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.801 X-Spam-Level: X-Spam-Status: No, score=-6.801 tagged_above=-999 required=5 tests=[AWL=-0.202, 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 TA2Y7adjI7mk for ; Wed, 19 Jun 2013 20:23:54 -0700 (PDT) Received: from KECGATE03.infosys.com (kecgate03.infosysconsulting.com [122.98.10.31]) by ietfa.amsl.com (Postfix) with ESMTP id DEEED21E8054 for ; Wed, 19 Jun 2013 20:23:24 -0700 (PDT) X-TM-IMSS-Message-ID: <75a94b1600165963@infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id 75a94b1600165963 ; Thu, 20 Jun 2013 08:52:07 +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; Thu, 20 Jun 2013 08:53:11 +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; Thu, 20 Jun 2013 08:53:11 +0530 From: Bharat Joshi To: "Apoorva Karan (apoorva)" , "pim@ietf.org" Thread-Topic: Few question/suggestions on 'Explicit RPF Vector' draft Thread-Index: Ac5rODfqFC4mrWLISz670IHBBZ76jAB26jLwABROPWA= Date: Thu, 20 Jun 2013 03:23:10 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E7803B@BLRKECMBX13.ad.infosys.com> References: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com>, <2CD445E94B8C344289ED02B6582A49DA116E475A@xmb-rcd-x06.cisco.com> In-Reply-To: <2CD445E94B8C344289ED02B6582A49DA116E475A@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 03:23:59 -0000 Hi Apoorva, Thanks for your response. Please see few responses in line. Regards, Bharat > * Should we add a limit on number of RPF vectors in the stack? Is it ok > to have any number of RPF vectors in the stack as long as the maximum I= P > packet length is not reached? > =3D> There is no restriction on the number of RPF vectors in the stack. Ok. > * What happens if a router does not have a PIM neighbor for the explici= t > RPF vector at the top of the stack? Does he keep this information in > case this neighbor comes up to expedite the joining process or does he > discard this join as refresh will anyway take care of this though there > may be some delay. > =3D> This is implementation specific. We have changed the wording to sa= y > that the vector stack may be stored. Ok. > * Should not this draft talk about join suppression? > =3D> Please refer to RFC 5496, same behavior applies to explicit rpf > vector. But the draft should at least mention this with a reference to the other = RFC. > * Should not this draft talk about PIM Asserts and how they should be > handled? > =3D> Please refer to RFC 5496, same behavior applies to explicit rpf > vector. Same as above. > * Should not this draft talk about how those PIM neighbors handle the > PIM JOIN which do not understand this particular attribute yet? > =3D> RFC 5384 says that an attribute that isn't understood is dropped a= nd > not forwarded. The same behavior applies to this attribute too. The > result will be that a regular PIM join will be send upstream of this > router. Again, I think the draft should mention this or refer to the RFC. **************** 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 jasghar@cisco.com Thu Jun 20 11:38:11 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C1421F9EE1 for ; Thu, 20 Jun 2013 11:38:11 -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 tIIT2Xz7fzFm for ; Thu, 20 Jun 2013 11:38:02 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 41D0321F9EBC for ; Thu, 20 Jun 2013 11:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1504; q=dns/txt; s=iport; t=1371753478; x=1372963078; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=CVZ0aILBshE0Q4LxXKq9a9to97Ws55HUUp7EXWhvm5c=; b=Ne8tQnNXzc1htWcRFfgeBsx29TrCoRx/PzjzRipBH3/xO23V7CXuzYu/ v8V1cSei6hWAcNMi+VedogpQRBFpwm2t4EZYYEGGSsmpK5W0nAeXqXHnr TkBB4hwqHx7tsmyS1p/teJJfjCizsAYDhm0hkzukdfQJ5mJSkovNDUbkv A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAP9Kw1GrRDoG/2dsb2JhbABbgwkywHsWdIIjAQEBAzlABjcWGAMCAQIBTAwIAQGIBAW8QJMxA4khjiKGIYsjgy8c X-IronPort-AV: E=Sophos;i="4.87,906,1363132800"; d="scan'208";a="81429642" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 20 Jun 2013 18:37:58 +0000 Received: from [10.128.2.48] (dhcp-10-128-2-48.cisco.com [10.128.2.48]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5KIbui4025153; Thu, 20 Jun 2013 18:37:57 GMT Message-ID: <51C34C04.6060205@cisco.com> Date: Thu, 20 Jun 2013 11:37:56 -0700 From: Javed Asghar User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: pim@ietf.org, bharat_joshi@infosys.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 18:38:11 -0000 Hi Bharat, Thanks for your comments. We have minor draft updates which cover your comments. Please see comments inline. Thanks, -Javed. > * Should not this draft talk about join suppression? > => Please refer to RFC 5496, same behavior applies to explicit rpf > vector. > But the draft should at least mention this with a reference to the other RFC. JA>>> Yes, we have added text for join suppression behavior and reference RFC 5496 behavior. Please note that if a router already has multicast state via explicit vector tlv, join suppression will be applied to the same upstream neighbor. > * Should not this draft talk about PIM Asserts and how they should be > handled? > => Please refer to RFC 5496, same behavior applies to explicit rpf > vector. >Same as above. JA>>> Yes, draft updated for completeness based on your comments. Made reference to RFC 5496 section 3.3.3. Please note same behavior applies to all rfp vector types, including explicit rpf vector. > * Should not this draft talk about how those PIM neighbors handle the > PIM JOIN which do not understand this particular attribute yet? > => RFC 5384 says that an attribute that isn't understood is dropped and > not forwarded. The same behavior applies to this attribute too. The > result will be that a regular PIM join will be send upstream of this > router. > Again, I think the draft should mention this or refer to the RFC. JA>>> Yes, draft updated with above reference and comments. From bharat_joshi@infosys.com Thu Jun 20 20:28:06 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E07511E8158 for ; Thu, 20 Jun 2013 20:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.781 X-Spam-Level: X-Spam-Status: No, score=-8.781 tagged_above=-999 required=5 tests=[AWL=1.818, 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 FxRhdYzHmocC for ; Thu, 20 Jun 2013 20:28:01 -0700 (PDT) Received: from kecgate06.infosys.com (kecgate06.infosys.com [122.98.14.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9A56911E80AE for ; Thu, 20 Jun 2013 20:28:00 -0700 (PDT) X-TM-IMSS-Message-ID: <7ac651dd0018b600@infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 7ac651dd0018b600 ; Fri, 21 Jun 2013 08:57:41 +0530 Received: from BLRKECHUB10.ad.infosys.com (10.66.236.120) by blrkechub03.ad.infosys.com (10.66.236.43) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Jun 2013 08:57:44 +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; Fri, 21 Jun 2013 08:57:43 +0530 From: Bharat Joshi To: Javed Asghar , "pim@ietf.org" Thread-Topic: [pim] Few question/suggestions on 'Explicit RPF Vector' draft Thread-Index: AQHObeVFJ0o5oxcbcUuv8R5mCsceTJk/ga+a Date: Fri, 21 Jun 2013 03:27:43 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E78D09@BLRKECMBX13.ad.infosys.com> References: <51C34C04.6060205@cisco.com> In-Reply-To: <51C34C04.6060205@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 03:28:06 -0000 Hi Javed, Thanks for your reply. I hope these changes will improve the draf= t. Regards, Bharat > > * Should not this draft talk about join suppression? > > =3D> Please refer to RFC 5496, same behavior applies to explicit rpf > > vector. > > But the draft should at least mention this with a reference to the > other RFC. > > JA>>> Yes, we have added text for join suppression behavior and > reference RFC 5496 behavior. Please note that if a router already has > multicast state via explicit vector tlv, join suppression will be > applied to the same upstream neighbor. > > > * Should not this draft talk about PIM Asserts and how they should be > > handled? > > =3D> Please refer to RFC 5496, same behavior applies to explicit rpf > > vector. > > >Same as above. > > JA>>> Yes, draft updated for completeness based on your comments. Made > reference to RFC 5496 section 3.3.3. Please note same behavior applies > to all rfp vector types, including explicit rpf vector. > > > > * Should not this draft talk about how those PIM neighbors handle the > > PIM JOIN which do not understand this particular attribute yet? > > =3D> RFC 5384 says that an attribute that isn't understood is dropped > and > > not forwarded. The same behavior applies to this attribute too. The > > result will be that a regular PIM join will be send upstream of this > > router. > > > Again, I think the draft should mention this or refer to the RFC. > > JA>>> Yes, draft updated with above reference and comments. > **************** 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 erosen@cisco.com Mon Jun 24 14:51:10 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@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 Date: Mon, 24 Jun 2013 17:50:59 -0400 Message-ID: <16686.1372110659@erosen-linux> Cc: Marco Rodrigues , "ASIF, SAUD" , "l3vpn@ietf.org" , "pim@ietf.org" Subject: [pim] Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Protocol Independent Multicast 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 internet-drafts@ietf.org Mon Jun 24 20:46:38 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C6021F9D92; Mon, 24 Jun 2013 20:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, 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 Ye3Vj9BeuH30; Mon, 24 Jun 2013 20:46:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A83E21F9D82; Mon, 24 Jun 2013 20:46:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130625034638.29353.18805.idtracker@ietfa.amsl.com> Date: Mon, 24 Jun 2013 20:46:38 -0700 Cc: pim@ietf.org Subject: [pim] I-D Action: draft-ietf-pim-explicit-rpf-vector-01.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 03:46:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol Independent Multicast Working Gr= oup of the IETF. Title : Explicit RPF Vector Author(s) : Javed Asghar IJsbrand Wijnands Sowmya Krishnaswamy Apoorva Karan Vishal Arya Filename : draft-ietf-pim-explicit-rpf-vector-01.txt Pages : 5 Date : 2013-06-24 Abstract: This document describes a use of the Reverse Path Forwarding (RPF) Vector TLV as defined in [RPC 5496] to build multicast trees via an explicit path sent in the PIM join. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pim-explicit-rpf-vector There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pim-explicit-rpf-vector-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-pim-explicit-rpf-vector-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.McBride@huawei.com Mon Jun 24 23:37:44 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F10921F9D5C for ; Mon, 24 Jun 2013 23:37:44 -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 QuG1pk+HeORj for ; Mon, 24 Jun 2013 23:37:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D0BE121F9D5A for ; Mon, 24 Jun 2013 23:37:39 -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 ASV07765; Tue, 25 Jun 2013 06:37:38 +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; Tue, 25 Jun 2013 07:36:53 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 25 Jun 2013 07:37:32 +0100 Received: from DFWEML512-MBS.china.huawei.com ([169.254.2.153]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Mon, 24 Jun 2013 23:37:29 -0700 From: Michael McBride To: Mike McBride , "pim@ietf.org" Thread-Topic: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 Thread-Index: AQHOZmzCcLVgOtShME6OYjSowDCfT5lGCnmg Date: Tue, 25 Jun 2013 06:37:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 06:37:44 -0000 The wglc has ended and we have received solid consensus to progress this dr= aft. Thank you for your responses. The authors have addressed the wglc comm= ents in an updated draft which we will be sending to Adrian and the iesg fo= lks: http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-01.txt=20 Bharat, please make sure this updated draft addresses your comments. We wil= l send to Adrian this Friday. Thanks, mike > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > Mike McBride > Sent: Monday, June 10, 2013 11:27 PM > To: pim@ietf.org > Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 >=20 > This is a recently adopted draft and the authors feel it is now ready > for progression. Its a short draft so we likely don't have a good > excuse to not read it over the next week. And then please express an > opinion on this drafts readiness for being sent to the IESG as an > Informational RFC: >=20 > http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt >=20 > We will end this WGLC on June 24th. Please speak up before then. >=20 > thanks, > mike > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From bharat_joshi@infosys.com Tue Jun 25 01:07:08 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5FB21F93D4 for ; Tue, 25 Jun 2013 01:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.946 X-Spam-Level: X-Spam-Status: No, score=-6.946 tagged_above=-999 required=5 tests=[AWL=-0.347, 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 45rot-higXgP for ; Tue, 25 Jun 2013 01:07:04 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9D34321F91BC for ; Tue, 25 Jun 2013 01:07:03 -0700 (PDT) X-TM-IMSS-Message-ID: <90506263000d6056@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 90506263000d6056 ; Tue, 25 Jun 2013 13:44:16 +0530 Received: from BLRKECHUB12.ad.infosys.com (10.66.236.47) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Jun 2013 13:36:25 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB12.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 13:36:25 +0530 From: Bharat Joshi To: Michael McBride , Mike McBride , "pim@ietf.org" Thread-Topic: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 Thread-Index: AQHOZmzCcLVgOtShME6OYjSowDCfT5lGCnmggAAdk0o= Date: Tue, 25 Jun 2013 08:06:24 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E79439@BLRKECMBX13.ad.infosys.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 08:07:08 -0000 Mike and Authors, I read through the draft. I have some more questions/suggestions= on this. I hope this helps. Regards, Bharat =95 In section 7, "from the first Explicit vector in the stack" -> "from = the topmost Explicit vector in the stack" =95 A small typo in "The Metric will therefore not be a tie breaker in th= e PIM Assert", it should use "not to be a tie" =95 In section 7, in following statement: However, the first Explicit vector should always be directly connected, s= o the Metric will be zero. I think it is not correct to assume that directly connected route's = has a metric of zero. IIRC, some vendors provide means to configure such = a metric. =95 In section 9, "support the Explicit Vector MUST never" -> "support th= e Explicit Vector attribute MUST never" =95 In section 9, in following statement: Routers that don't support the Explicit Vector MUST never forward the vec= tor to their upstream PIM neighbor. With above statement, its not clear if the attribute should not be f= orwarded or the PIM join itself should not be forwarded upstream. A PIM j= oin can still be forwarded using normal means if required. =95 Will things work if both Explicit RPF vector and normal RPF vector at= tributes are available in a PIM join? Or should we say that they cannot b= e used together? =95 If the above is possible, can someone support a PIM join with first f= ew explicit RPF vector attributes, then a normal RPF vector and then agai= n few explicit RPF vector? Such a thing may be required if the customer i= s using a VPN and want to create the tree in his local network as well as= remote network based on his own requirements. I am not sure if such a re= quirement exists or not. I am just checking if such a flexibility is allo= wed. =95 In section 12, "RPF Vector Attribute" -> "Explicit RPF Vector Attribu= te" =95 In security consideration, should not we also mention that Explicit R= PF Vector Attribute itself does not add any security implications on PIM-= SM functioning. =95 In section 5, I think following sentence should be reword: This draft uses vector attribute 4 for specifying an explicit RPF vector. to This draft uses PIM Join attribute type 4 for specifying an Explicit RPF = Vector Attribute. ________________________________________ From: pim-bounces@ietf.org [pim-bounces@ietf.org] on behalf of Michael Mc= Bride [Michael.McBride@huawei.com] Sent: Tuesday, June 25, 2013 12:07 PM To: Mike McBride; pim@ietf.org Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 The wglc has ended and we have received solid consensus to progress this = draft. Thank you for your responses. The authors have addressed the wglc = comments in an updated draft which we will be sending to Adrian and the i= esg folks: http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-01.t= xt Bharat, please make sure this updated draft addresses your comments. We w= ill send to Adrian this Friday. Thanks, mike > -----Original Message----- > From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of > Mike McBride > Sent: Monday, June 10, 2013 11:27 PM > To: pim@ietf.org > Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 > > This is a recently adopted draft and the authors feel it is now ready > for progression. Its a short draft so we likely don't have a good > excuse to not read it over the next week. And then please express an > opinion on this drafts readiness for being sent to the IESG as an > Informational RFC: > > http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt > > We will end this WGLC on June 24th. Please speak up before then. > > thanks, > mike > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim _______________________________________________ pim mailing list pim@ietf.org https://www.ietf.org/mailman/listinfo/pim **************** 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 eckert@cisco.com Tue Jun 25 04:50:05 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B8821F9F33 for ; Tue, 25 Jun 2013 04:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=0.335, 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 gUnhJM7s9so2 for ; Tue, 25 Jun 2013 04:50:00 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9971321F9F0B for ; Tue, 25 Jun 2013 04:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4322; q=dns/txt; s=iport; t=1372161000; x=1373370600; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=uni6eU1amLxWOfUFpNB9otk6DgzTBzSSmTDhlm2+qaQ=; b=hwWE4fzaW4TtVM81Pjz1m8GqCuovMG3NdVICB1n6NifZal29E3srTdVN ClVDmviaaqhU92aRzZPvruCf0bxVidzltXf11JYGs0hmadrCHkcqsXWLG sHQTOWLDUidKzUe2ehkjx6vug3ax6YXipwOzTARA6w9kRDWusgQHPaKry 4=; X-IronPort-AV: E=Sophos;i="4.87,936,1363132800"; d="scan'208";a="81240285" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 25 Jun 2013 11:49:58 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5PBnvBp000887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 11:49:57 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r5PBnvm9001557; Tue, 25 Jun 2013 04:49:57 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r5PBnutK001556; Tue, 25 Jun 2013 04:49:56 -0700 Date: Tue, 25 Jun 2013 04:49:56 -0700 From: Toerless Eckert To: Stig Venaas Message-ID: <20130625114956.GD10214@cisco.com> References: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com> <51BF6166.4080506@venaas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51BF6166.4080506@venaas.com> User-Agent: Mutt/1.4.2.2i Cc: "pim@ietf.org" , Bharat Joshi , Eric Osborne Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 11:50:05 -0000 On Mon, Jun 17, 2013 at 12:20:06PM -0700, Stig Venaas wrote: > I can't think of any reason to limit it. It wouldn't make sense > to have more than 255 of course. Is there really anything today that would limit the scope of an MPLS core to 255 ? IP TTL does not get decrement across an LSP, so it would have to be something in the MPLS control plane, right ? Does anybody know what, if any limitations there are on RSVP-TE EROs ? Adding a TE expert, maybe he can suggest some limit that would be inline with the TE ERO-size limits. Cheers Toerless > >? Should the RPF vector address be PIM neighbor's primary IP address or it > >is fine even if it is one of the secondary IP address of a PIM neighbor? > > I think it's good to allow a secondary address, but it should be stated > clearly. Note that for IPv6 it says that a global address must be used, > hence for IPv6 it cannot be the primary address. > > >? In introduction, in following sentence: > > > >If a router receiving an explicit RPF vector does not have a PIM neighbor > >matching the explicit RPF vector address it MUST NOT fall back to loosely > >routing the JOIN. > > > >Its not clear what should be done with the JOIN. Should it be discarded? > >Should there be some counter maintained for such an action? > > > >? Can we add some text on what happens at a router when the last entry in > >the explicit RPF vector stack is removed? It will have to do unicast route > >lookup for either source or the RP depending upon the PIM JOIN. Right? > > I would think the last is processed just as the previous vectors. It > will send it > to that neighbor. But the join it sends, won't have any attributes, > right? So the receiving router would then process the join as normal. > I don't see that anything needs to be added here. > > >? What happens if a router does not have a PIM neighbor for the explicit > >RPF vector at the top of the stack? Does he keep this information in case > >this neighbor comes up to expedite the joining process or does he discard > >this join as refresh will anyway take care of this though there may be > >some delay. > > I think it could be discarded, waiting for the next periodic join. But it > would be a possible optimization. Perhaps this could be a MAY? > > >? Should not this draft talk about join suppression? > > > >? Should not this draft talk about PIM Asserts and how they should be > >handled? > > Good points. > > >? Should not this draft talk about how those PIM neighbors handle the PIM > >JOIN which do not understand this particular attribute yet? > > I would assume according to 5384 if not specified. It might be good to > still mention it though. > > Thanks for the detailed review. It certainly should help improve the > document quality. > > Stig > > >**************** CAUTION - Disclaimer ***************** > >This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > >solely > >for the use of the addressee(s). If you are not the intended recipient, > >please > >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 > >has 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 reserves > >the > >right to monitor and review the content of all messages sent to or from > >this e-mail > >address. Messages sent to or from this e-mail address may be stored on the > >Infosys e-mail system. > >***INFOSYS******** End of Disclaimer ********INFOSYS*** > >_______________________________________________ > >pim mailing list > >pim@ietf.org > >https://www.ietf.org/mailman/listinfo/pim > > > > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From rajiva@cisco.com Tue Jun 25 06:22:15 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F3B11E80AD for ; Tue, 25 Jun 2013 06:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 TKF37FCBR2rO for ; Tue, 25 Jun 2013 06:22:09 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3110321F9920 for ; Tue, 25 Jun 2013 06:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5278; q=dns/txt; s=iport; t=1372166529; x=1373376129; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=81p3o+vwIFtRyJ/d60ge9sIJ35+oy50v3vuFFKfCuqI=; b=IDP+jOCXftRnIppc4g93WsKaba/wsYc/J/hKYDrGaE5kKSbV8cY/l5Kg RW6YMSOWLJ9Kz7/u9TAS3HZmh2Iq76pzPYRgJBMppntcDPDJ3JMD1pjtg Ye0nyO96UnDCZpFWT8jr+FrQgUMTqWWgYKs5iRHn0vc7fdGabl3H8atDV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAIuYyVGtJXHB/2dsb2JhbABagwkxwAKBARZ0giMBAQEDAQEBATcxAwsFCwIBCBIGHhAnCxcOAgQOBYgIBgy7DwSODgV/MweDAmEDl0ORRIMQgWkIFw X-IronPort-AV: E=Sophos;i="4.87,937,1363132800"; d="scan'208";a="227178642" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 25 Jun 2013 13:22:07 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5PDM7ku013705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Jun 2013 13:22:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.251]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 08:22:06 -0500 From: "Rajiv Asati (rajiva)" To: "Toerless Eckert (eckert)" Thread-Topic: [pim] Few question/suggestions on 'Explicit RPF Vector' draft Thread-Index: AQHOcZomP/8cAp/S6EmFsSwVotavn5lGasUK Date: Tue, 25 Jun 2013 13:22:06 +0000 Message-ID: <6A3F76E9-4A5D-42C8-9C45-A0638DEE9623@cisco.com> References: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com> <51BF6166.4080506@venaas.com>,<20130625114956.GD10214@cisco.com> In-Reply-To: <20130625114956.GD10214@cisco.com> 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 Cc: Bharat Joshi , "pim@ietf.org" , "Eric Osborne \(eosborne\)" Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:22:15 -0000 > Is there really anything today that would limit the scope of an MPLS > core to 255 ? IP TTL does not get decrement across an LSP, so it would ha= ve to be something in the MPLS control plane, right ? MPLS header has TTL, same as that of IP header. > Does anybody know what, if any limitations there are on RSVP-TE EROs ? RFC3209 doesn't place any restriction on number of ERO or RRO sub-objects. Cheers, Rajiv Sent from my Phone On Jun 25, 2013, at 7:50 AM, "Toerless Eckert (eckert)" = wrote: > On Mon, Jun 17, 2013 at 12:20:06PM -0700, Stig Venaas wrote: >> I can't think of any reason to limit it. It wouldn't make sense >> to have more than 255 of course. >=20 > Is there really anything today that would limit the scope of an MPLS > core to 255 ? IP TTL does not get decrement across an LSP, so it > would have to be something in the MPLS control plane, right ? >=20 > Does anybody know what, if any limitations there are on RSVP-TE EROs ? >=20 > Adding a TE expert, maybe he can suggest some limit that would be > inline with the TE ERO-size limits. >=20 > Cheers > Toerless >=20 >>> ? Should the RPF vector address be PIM neighbor's primary IP address or= it=20 >>> is fine even if it is one of the secondary IP address of a PIM neighbor= ? >>=20 >> I think it's good to allow a secondary address, but it should be stated >> clearly. Note that for IPv6 it says that a global address must be used, >> hence for IPv6 it cannot be the primary address. >>=20 >>> ? In introduction, in following sentence: >>>=20 >>> If a router receiving an explicit RPF vector does not have a PIM neigh= bor=20 >>> matching the explicit RPF vector address it MUST NOT fall back to loose= ly=20 >>> routing the JOIN. >>>=20 >>> Its not clear what should be done with the JOIN. Should it be discarded= ?=20 >>> Should there be some counter maintained for such an action? >>>=20 >>> ? Can we add some text on what happens at a router when the last entry = in=20 >>> the explicit RPF vector stack is removed? It will have to do unicast ro= ute=20 >>> lookup for either source or the RP depending upon the PIM JOIN. Right? >>=20 >> I would think the last is processed just as the previous vectors. It=20 >> will send it >> to that neighbor. But the join it sends, won't have any attributes, >> right? So the receiving router would then process the join as normal. >> I don't see that anything needs to be added here. >>=20 >>> ? What happens if a router does not have a PIM neighbor for the explici= t=20 >>> RPF vector at the top of the stack? Does he keep this information in ca= se=20 >>> this neighbor comes up to expedite the joining process or does he disca= rd=20 >>> this join as refresh will anyway take care of this though there may be= =20 >>> some delay. >>=20 >> I think it could be discarded, waiting for the next periodic join. But i= t >> would be a possible optimization. Perhaps this could be a MAY? >>=20 >>> ? Should not this draft talk about join suppression? >>>=20 >>> ? Should not this draft talk about PIM Asserts and how they should be=20 >>> handled? >>=20 >> Good points. >>=20 >>> ? Should not this draft talk about how those PIM neighbors handle the P= IM=20 >>> JOIN which do not understand this particular attribute yet? >>=20 >> I would assume according to 5384 if not specified. It might be good to >> still mention it though. >>=20 >> Thanks for the detailed review. It certainly should help improve the >> document quality. >>=20 >> Stig >>=20 >>> **************** CAUTION - Disclaimer ***************** >>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended=20 >>> solely >>> for the use of the addressee(s). If you are not the intended recipient,= =20 >>> please >>> notify the sender by e-mail and delete the original message. Further, y= ou=20 >>> are not >>> to copy, disclose, or distribute this e-mail or its contents to any oth= er=20 >>> person and >>> any such actions are unlawful. This e-mail may contain viruses. Infosys= =20 >>> has taken >>> every reasonable precaution to minimize this risk, but is not liable fo= r=20 >>> any damage >>> you may sustain as a result of any virus in this e-mail. You should car= ry=20 >>> out your >>> own virus checks before opening the e-mail or attachment. Infosys reser= ves=20 >>> the >>> right to monitor and review the content of all messages sent to or from= =20 >>> this e-mail >>> address. Messages sent to or from this e-mail address may be stored on = the >>> Infosys e-mail system. >>> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >>> _______________________________________________ >>> pim mailing list >>> pim@ietf.org >>> https://www.ietf.org/mailman/listinfo/pim >>=20 >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim >=20 > --=20 > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! >=20 > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim From eckert@cisco.com Tue Jun 25 07:13:20 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284F121F9E50 for ; Tue, 25 Jun 2013 07:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.348 X-Spam-Level: X-Spam-Status: No, score=-10.348 tagged_above=-999 required=5 tests=[AWL=0.252, 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 g6OdYrZ9sXfY for ; Tue, 25 Jun 2013 07:13:15 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6C32021F95D7 for ; Tue, 25 Jun 2013 07:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5737; q=dns/txt; s=iport; t=1372169595; x=1373379195; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=iFGrfFUs2VV8+gMYjPyeFK9aqI2RgjMTIBG2pL0x8nU=; b=c3mJwlCmtxaHkQOvPk9oux4M76yW3TOlT/2Kk9bHHcRqZu/LpzIuenVo j0+brGfUnD7dAkFjuNLwq/IfsvB+MV2LBJfbPA/2BE9jYJ6DiXZwX7Mew A7HNH3l3vFwFpSjoHREvAgnNU4U19t5JoIRx860EeGw3X2WoG95BACDKV s=; X-IronPort-AV: E=Sophos;i="4.87,937,1363132800"; d="scan'208";a="81250138" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 25 Jun 2013 14:13:15 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5PEDEKm003494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Jun 2013 14:13:14 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id r5PEDE8D009454; Tue, 25 Jun 2013 07:13:14 -0700 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id r5PEDDTF009453; Tue, 25 Jun 2013 07:13:13 -0700 Date: Tue, 25 Jun 2013 07:13:13 -0700 From: "Toerless Eckert (eckert)" To: "Rajiv Asati (rajiva)" Message-ID: <20130625141313.GK10214@cisco.com> References: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com> <6A3F76E9-4A5D-42C8-9C45-A0638DEE9623@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A3F76E9-4A5D-42C8-9C45-A0638DEE9623@cisco.com> User-Agent: Mutt/1.4.2.2i Cc: Bharat Joshi , "pim@ietf.org" , "Eric Osborne \(eosborne\)" Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:13:20 -0000 Thanks, Rajiv. Seems then we can easily stay in the same ball park by not specifying any limits either but leave the text as it is. Cheers Toerless On Tue, Jun 25, 2013 at 01:22:06PM +0000, Rajiv Asati (rajiva) wrote: > > Is there really anything today that would limit the scope of an MPLS > > core to 255 ? IP TTL does not get decrement across an LSP, so it would have to be something in the MPLS control plane, right ? > > MPLS header has TTL, same as that of IP header. > > > Does anybody know what, if any limitations there are on RSVP-TE EROs ? > > RFC3209 doesn't place any restriction on number of ERO or RRO sub-objects. > > Cheers, > Rajiv > > Sent from my Phone > > On Jun 25, 2013, at 7:50 AM, "Toerless Eckert (eckert)" wrote: > > > On Mon, Jun 17, 2013 at 12:20:06PM -0700, Stig Venaas wrote: > >> I can't think of any reason to limit it. It wouldn't make sense > >> to have more than 255 of course. > > > > Is there really anything today that would limit the scope of an MPLS > > core to 255 ? IP TTL does not get decrement across an LSP, so it > > would have to be something in the MPLS control plane, right ? > > > > Does anybody know what, if any limitations there are on RSVP-TE EROs ? > > > > Adding a TE expert, maybe he can suggest some limit that would be > > inline with the TE ERO-size limits. > > > > Cheers > > Toerless > > > >>> ? Should the RPF vector address be PIM neighbor's primary IP address or it > >>> is fine even if it is one of the secondary IP address of a PIM neighbor? > >> > >> I think it's good to allow a secondary address, but it should be stated > >> clearly. Note that for IPv6 it says that a global address must be used, > >> hence for IPv6 it cannot be the primary address. > >> > >>> ? In introduction, in following sentence: > >>> > >>> If a router receiving an explicit RPF vector does not have a PIM neighbor > >>> matching the explicit RPF vector address it MUST NOT fall back to loosely > >>> routing the JOIN. > >>> > >>> Its not clear what should be done with the JOIN. Should it be discarded? > >>> Should there be some counter maintained for such an action? > >>> > >>> ? Can we add some text on what happens at a router when the last entry in > >>> the explicit RPF vector stack is removed? It will have to do unicast route > >>> lookup for either source or the RP depending upon the PIM JOIN. Right? > >> > >> I would think the last is processed just as the previous vectors. It > >> will send it > >> to that neighbor. But the join it sends, won't have any attributes, > >> right? So the receiving router would then process the join as normal. > >> I don't see that anything needs to be added here. > >> > >>> ? What happens if a router does not have a PIM neighbor for the explicit > >>> RPF vector at the top of the stack? Does he keep this information in case > >>> this neighbor comes up to expedite the joining process or does he discard > >>> this join as refresh will anyway take care of this though there may be > >>> some delay. > >> > >> I think it could be discarded, waiting for the next periodic join. But it > >> would be a possible optimization. Perhaps this could be a MAY? > >> > >>> ? Should not this draft talk about join suppression? > >>> > >>> ? Should not this draft talk about PIM Asserts and how they should be > >>> handled? > >> > >> Good points. > >> > >>> ? Should not this draft talk about how those PIM neighbors handle the PIM > >>> JOIN which do not understand this particular attribute yet? > >> > >> I would assume according to 5384 if not specified. It might be good to > >> still mention it though. > >> > >> Thanks for the detailed review. It certainly should help improve the > >> document quality. > >> > >> Stig > >> > >>> **************** CAUTION - Disclaimer ***************** > >>> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > >>> solely > >>> for the use of the addressee(s). If you are not the intended recipient, > >>> please > >>> 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 > >>> has 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 reserves > >>> the > >>> right to monitor and review the content of all messages sent to or from > >>> this e-mail > >>> address. Messages sent to or from this e-mail address may be stored on the > >>> Infosys e-mail system. > >>> ***INFOSYS******** End of Disclaimer ********INFOSYS*** > >>> _______________________________________________ > >>> pim mailing list > >>> pim@ietf.org > >>> https://www.ietf.org/mailman/listinfo/pim > >> > >> _______________________________________________ > >> pim mailing list > >> pim@ietf.org > >> https://www.ietf.org/mailman/listinfo/pim > > > > -- > > --- > > Toerless Eckert, eckert@cisco.com > > Cisco NSSTG Systems & Technology Architecture > > SDN: Let me play with the network, mommy! > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim -- --- Toerless Eckert, eckert@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy! From sa9362@att.com Mon Jun 24 15:20:36 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@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 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] X-Mailman-Approved-At: Tue, 25 Jun 2013 11:45:32 -0700 Cc: Marco Rodrigues , "l3vpn@ietf.org" , "pim@ietf.org" Subject: Re: [pim] Comments on draft-kurapati-dynamicrp-bgpmvpn-00.txt X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast 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 eosborne@cisco.com Tue Jun 25 06:40:12 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB5F11E80EC for ; Tue, 25 Jun 2013 06:40:12 -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 tfJ7oXNVq2U0 for ; Tue, 25 Jun 2013 06:40:07 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E184911E80FB for ; Tue, 25 Jun 2013 06:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6928; q=dns/txt; s=iport; t=1372167607; x=1373377207; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KAJVrmOLD9GklcTJ46dZDewPY0kA31UfiV+dnkDJAZ4=; b=XdDVtXJ8taZFb6uxb/B0Ruu4Thw+aQydqJ+92f5EiL+AT8xJwZQclOl1 8aeBziUDdaHEI1L5O5/iLCPEUBSu/fkADkxS+JyL7WGebx9g+dUkd18mm 3INUFv0pZWPoMThWjh2Z9Vm7qvwnKqaQzSDyNq90aZtaEQUfDm9C0LVYN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAAydyVGtJXHA/2dsb2JhbABagwkxSb85gQEWdIIjAQEBAwEBAQE3MQMLBQcEAgEIEQEDAQEBChQQJwsXBggCBAENBQiIAAYMuxUEjg4FgQExBwaCfGEDk3GVFoMQgWkIFyA X-IronPort-AV: E=Sophos;i="4.87,937,1363132800"; d="scan'208";a="227176496" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 25 Jun 2013 13:40:06 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5PDe6KU032685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Jun 2013 13:40:06 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 25 Jun 2013 08:40:05 -0500 From: "Eric Osborne (eosborne)" To: "Toerless Eckert (eckert)" , Stig Venaas Thread-Topic: [pim] Few question/suggestions on 'Explicit RPF Vector' draft Thread-Index: AQHOcZoeCGVdvTERBUueaGcDPCzqaJlGaYvQ Date: Tue, 25 Jun 2013 13:40:05 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721027121D@xmb-rcd-x09.cisco.com> References: <35347FBF2796F94E936EE76C0E6047ED32E74866@BLRKECMBX13.ad.infosys.com> <51BF6166.4080506@venaas.com> <20130625114956.GD10214@cisco.com> In-Reply-To: <20130625114956.GD10214@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.245.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 25 Jun 2013 11:45:32 -0700 Cc: "pim@ietf.org" , Bharat Joshi Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:40:12 -0000 Some offhand answers below...if there are specifics I'm missing in the ques= tion let me know. > Is there really anything today that would limit the scope of an MPLS > core to 255 ? IP TTL does not get decrement across an LSP, so it > would have to be something in the MPLS control plane, right ? An MPLS label stack entry has an 8-bit TTL, and you have to decrement it by= 1 at every hop. There are some hacks we can do ('no-propagate-ttl' is one= vendor's knob) but at the end of the day you have to respect the limit. W= e could come up with further hacks to disregard the limit - maybe nested la= bels and not copying down the outer TTL - but ignoring the TTL is a really = bad idea so in practice I can't see it happening. So TTL is going to be yo= ur limiting factor. As far as ERO, that gets trickier. (for non-TE people; an Explicit Route Object is an ordered list of hops an = RSVP Path message must traverse, and is how we force an LSP across the netw= ork down a path other than the IGP shortest path.) You don't *have* to have an ERO in an RSVP Path message, but of course it's= really handy. You can also have loose hops in a Path which you hairpin th= rough, so you can diverge from the IGP shortest path by only specifying a s= ubset of the hops you want to take. You're going to hit MTU limits first, = and a Path message can have lots of other optional stuff that can eat into = the size you'd otherwise use for ERO hops. But if you have 1,000 bytes for = ERO hops that's still 125 hops and if you make them loose you can probably = cover quite a bit of ground, depending on topology. There are also facilit= ies to specify not IPaddrs but ASes in an ERO, although I've never seen tha= t in the wild. =20 Note that I have not been asked to comment on whether a network with >255 h= ops is realistic. In my experience, though, that's an order of magnitude m= ore than people are doing today, and end-to-end TE tunnels are rarer than c= ore-only tunnels (if that matters to your question). eric > -----Original Message----- > From: Toerless Eckert (eckert) > Sent: Tuesday, June 25, 2013 7:50 AM > To: Stig Venaas > Cc: Bharat Joshi; pim@ietf.org; Eric Osborne (eosborne) > Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector' > draft >=20 > On Mon, Jun 17, 2013 at 12:20:06PM -0700, Stig Venaas wrote: > > I can't think of any reason to limit it. It wouldn't make sense > > to have more than 255 of course. >=20 > Is there really anything today that would limit the scope of an MPLS > core to 255 ? IP TTL does not get decrement across an LSP, so it > would have to be something in the MPLS control plane, right ? >=20 > Does anybody know what, if any limitations there are on RSVP-TE EROs ? >=20 > Adding a TE expert, maybe he can suggest some limit that would be > inline with the TE ERO-size limits. >=20 > Cheers > Toerless >=20 > > >? Should the RPF vector address be PIM neighbor's primary IP address > or it > > >is fine even if it is one of the secondary IP address of a PIM > neighbor? > > > > I think it's good to allow a secondary address, but it should be > stated > > clearly. Note that for IPv6 it says that a global address must be > used, > > hence for IPv6 it cannot be the primary address. > > > > >? In introduction, in following sentence: > > > > > >If a router receiving an explicit RPF vector does not have a PIM > neighbor > > >matching the explicit RPF vector address it MUST NOT fall back to > loosely > > >routing the JOIN. > > > > > >Its not clear what should be done with the JOIN. Should it be > discarded? > > >Should there be some counter maintained for such an action? > > > > > >? Can we add some text on what happens at a router when the last > entry in > > >the explicit RPF vector stack is removed? It will have to do unicast > route > > >lookup for either source or the RP depending upon the PIM JOIN. > Right? > > > > I would think the last is processed just as the previous vectors. It > > will send it > > to that neighbor. But the join it sends, won't have any attributes, > > right? So the receiving router would then process the join as normal. > > I don't see that anything needs to be added here. > > > > >? What happens if a router does not have a PIM neighbor for the > explicit > > >RPF vector at the top of the stack? Does he keep this information in > case > > >this neighbor comes up to expedite the joining process or does he > discard > > >this join as refresh will anyway take care of this though there may > be > > >some delay. > > > > I think it could be discarded, waiting for the next periodic join. But > it > > would be a possible optimization. Perhaps this could be a MAY? > > > > >? Should not this draft talk about join suppression? > > > > > >? Should not this draft talk about PIM Asserts and how they should be > > >handled? > > > > Good points. > > > > >? Should not this draft talk about how those PIM neighbors handle the > PIM > > >JOIN which do not understand this particular attribute yet? > > > > I would assume according to 5384 if not specified. It might be good to > > still mention it though. > > > > Thanks for the detailed review. It certainly should help improve the > > document quality. > > > > Stig > > > > >**************** CAUTION - Disclaimer ***************** > > >This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > > >solely > > >for the use of the addressee(s). If you are not the intended > recipient, > > >please > > >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 > > >has 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 > reserves > > >the > > >right to monitor and review the content of all messages sent to or > from > > >this e-mail > > >address. Messages sent to or from this e-mail address may be stored > on the > > >Infosys e-mail system. > > >***INFOSYS******** End of Disclaimer ********INFOSYS*** > > >_______________________________________________ > > >pim mailing list > > >pim@ietf.org > > >https://www.ietf.org/mailman/listinfo/pim > > > > > > > _______________________________________________ > > pim mailing list > > pim@ietf.org > > https://www.ietf.org/mailman/listinfo/pim >=20 > -- > --- > Toerless Eckert, eckert@cisco.com > Cisco NSSTG Systems & Technology Architecture > SDN: Let me play with the network, mommy! From stig@venaas.com Wed Jun 26 10:15:03 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE7111E8113 for ; Wed, 26 Jun 2013 10:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 aE6E5yhwmLuK for ; Wed, 26 Jun 2013 10:15:02 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id D629611E80F5 for ; Wed, 26 Jun 2013 10:15:01 -0700 (PDT) Received: from [10.33.12.93] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id 7AF5E804B; Wed, 26 Jun 2013 19:14:59 +0200 (CEST) Message-ID: <51CB2178.4040706@venaas.com> Date: Wed, 26 Jun 2013 10:14:32 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Bharat Joshi References: , <35347FBF2796F94E936EE76C0E6047ED32E79439@BLRKECMBX13.ad.infosys.com> In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED32E79439@BLRKECMBX13.ad.infosys.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Mike McBride , "pim@ietf.org" Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:15:03 -0000 On 6/25/2013 1:06 AM, Bharat Joshi wrote: > Mike and Authors, > > I read through the draft. I have some more questions/suggestions on this. > > I hope this helps. I read it once more too and suggested some editorial changes. I would like to see how those are addressed as well. I should probably have sent the comments to the list. I'll send comments on the next revision to the list if I think any additional changes should be made. Stig > Regards, > Bharat > > • In section 7, "from the first Explicit vector in the stack" -> "from the topmost Explicit vector in the stack" > > • A small typo in "The Metric will therefore not be a tie breaker in the PIM Assert", it should use "not to be a tie" > > • In section 7, in following statement: > > However, the first Explicit vector should always be directly connected, so the Metric will be zero. > > I think it is not correct to assume that directly connected route's has a metric of zero. IIRC, some vendors provide means to configure such a metric. > > • In section 9, "support the Explicit Vector MUST never" -> "support the Explicit Vector attribute MUST never" > > • In section 9, in following statement: > > Routers that don't support the Explicit Vector MUST never forward the vector to their upstream PIM neighbor. > > With above statement, its not clear if the attribute should not be forwarded or the PIM join itself should not be forwarded upstream. A PIM join can still be forwarded using normal means if required. > > • Will things work if both Explicit RPF vector and normal RPF vector attributes are available in a PIM join? Or should we say that they cannot be used together? > > • If the above is possible, can someone support a PIM join with first few explicit RPF vector attributes, then a normal RPF vector and then again few explicit RPF vector? Such a thing may be required if the customer is using a VPN and want to create the tree in his local network as well as remote network based on his own requirements. I am not sure if such a requirement exists or not. I am just checking if such a flexibility is allowed. > > • In section 12, "RPF Vector Attribute" -> "Explicit RPF Vector Attribute" > > • In security consideration, should not we also mention that Explicit RPF Vector Attribute itself does not add any security implications on PIM-SM functioning. > > • In section 5, I think following sentence should be reword: > > This draft uses vector attribute 4 for specifying an explicit RPF vector. > > to > > This draft uses PIM Join attribute type 4 for specifying an Explicit RPF Vector Attribute. > > ________________________________________ > From: pim-bounces@ietf.org [pim-bounces@ietf.org] on behalf of Michael McBride [Michael.McBride@huawei.com] > Sent: Tuesday, June 25, 2013 12:07 PM > To: Mike McBride; pim@ietf.org > Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 > > The wglc has ended and we have received solid consensus to progress this draft. Thank you for your responses. The authors have addressed the wglc comments in an updated draft which we will be sending to Adrian and the iesg folks: http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-01.txt > > Bharat, please make sure this updated draft addresses your comments. We will send to Adrian this Friday. > > Thanks, > mike > >> -----Original Message----- >> From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of >> Mike McBride >> Sent: Monday, June 10, 2013 11:27 PM >> To: pim@ietf.org >> Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 >> >> This is a recently adopted draft and the authors feel it is now ready >> for progression. Its a short draft so we likely don't have a good >> excuse to not read it over the next week. And then please express an >> opinion on this drafts readiness for being sent to the IESG as an >> Informational RFC: >> >> http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt >> >> We will end this WGLC on June 24th. Please speak up before then. >> >> thanks, >> mike >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, please > 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 has 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 reserves the > right to monitor and review the content of all messages sent to or from this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim > From bharat_joshi@infosys.com Fri Jun 28 03:40:11 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2FA21F9C49 for ; Fri, 28 Jun 2013 03:40:11 -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 E22j7G7KRhty for ; Fri, 28 Jun 2013 03:40:00 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosys.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 604EE21F9C47 for ; Fri, 28 Jun 2013 03:39:54 -0700 (PDT) X-TM-IMSS-Message-ID: <05503a910001208c@infosys.com> Received: from BLRKECHUB05.ad.infosys.com ([10.66.236.45]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 05503a910001208c ; Fri, 28 Jun 2013 16:17:11 +0530 Received: from BLRKECHUB11.ad.infosys.com (10.66.236.46) by BLRKECHUB05.ad.infosys.com (10.66.236.45) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jun 2013 16:09:42 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB11.ad.infosys.com ([fe80::883d:4303:7980:1456%11]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 16:09:41 +0530 From: Bharat Joshi To: "pim@ietf.org" Thread-Topic: Few questions/suggestion on DR Load Balancing draft Thread-Index: Ac5z68s+2kAKf7nNRUSera4muOzpTA== Date: Fri, 28 Jun 2013 10:39:40 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E85553@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.200.132] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pim] Few questions/suggestion on DR Load Balancing draft X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 10:40:11 -0000 Hi, I just read through the DR Load Balancing draft. I have few questi= ons/suggestion below. Regards, Bharat =95 In Abstract, s/as an Ethernet/as Ethernet/g. This seems to be at coup= le of places. =95 Are 'first hop network' or 'last hop LAN' a well known term? Will it = be easy for people to understand that this is being talked from multicast= source perspective? Can we call them directly connected LAN in both the = cases? =95 In Abstract, s/is operated in PIM SM/is operating in PIM SM/g. This i= s at least at two places. =95 In Abstract, in following sentence: On the last hop network, the PIM DR is responsible for tracking local mul= ticast listeners and forwarding traffic to these listeners if the group i= s operated in PIM SM/SSM/DM. Should we mentioning BIDIR-PIM as well in this list? Or such a group is t= reated differently? =95 In Abstract, s/can be distributed to and handled among these/can be d= istributed among these/ =95 In GDR definition, it talks about that GDR is responsible for a group= . Does this mean that a single GDR will be responsible for all channels (= S,G) for a given group but different sources? =95 s/process received new PIM Hello/process new PIM Hello/ =95 In Introduction, in following sentence: According to [RFC4601], R1 will be responsible for forwarding to the last= hop LAN. Can we replace this sentence by something similar to a sentence fr= om RFC 4601, section 6.1.1 point 2. The sentence is as follows: The designated router on a LAN is (in the absence of asserts) responsible= for forwarding traffic to that LAN on behalf of any local members. =95 There may be a mix of local hosts as well as downstream routers in a = network scenario. Do we still call this the last hop LAN? I guess yes and= I think there can still be GDR candidate and this draft can apply. Right= ? I think this is not coming out well in the draft. So please add/update = some text to reflect this. =95 In section 3, I did not get what 'load balancing' are we talking abou= t in case of 'first hop routers'? =95 In section 3, I also did not understand how ECMP helps in this load b= alancing. If there are multiple routers on a LAN in which the source also= sits, as per PIM, its the DR who is to send the register messages to the= RP. So I am not sure how ECMP helps here in making other router on this = LAN to do this instead of the DR? =95 As per RFC 4601, PIM DR is elected for any type of networks so there = is no need to mention that PIM DR election is done in a multi-access netw= ork. =95 In section 4, in sentence "The PIM DR is responsible for sending Join= /Prune messages to the RP or source.", I think we should mention that thi= s is done for the local host's join/leave. =95 In section 4, para 1, I think it should be enough if the text suggest= that PIM DR election is done as per RFC 4601 instead of describing the a= lgorithm here. =95 s/routers support this specification/routers which support this speci= fication/ =95 In section 4, can we reword the following sentence: Last hop routers who are with the new LBC TLV and with the same DR priori= ty as the PIM DR are GDR Candidates. to Last hop routers which supports the 'Load Balancing Capability' PIM hello= option and uses the same DR priority as the PIM DR, are considered to be= GDR Candidates. =95 In section 4, last para, can we clearly mention that we are referring= to groups joined by local members only. =95 I think section 4.2 should be divided into two, one that defined hash= mask and another that defines the hash function. =95 Apart from the hash value/function, cannot an administrator configure= the mapping statically? This way, an administrator will have more contro= l on which channel is registered by which DR and also, he won't need thes= e new hello options. I agree that such a thing will work only if all vend= ors provide such a mean to the administrators. =95 In section 4.3, its not clear what will be the contents of first PIM = hello message of a router coming up? Will it contain LB GDR option or not= ? At that time, it may not know whether its a DR or not. Actually, it wil= l assume that its the DR until it receives a hello message from a higher = DR priority router. =95 In section 5.2, should we be using encoded format defined in RFC 4601= for GDR addresses or using it in native format is fine? =95 What is the idea of sending the masks from PIM DR to other routers? W= hy cannot they be configured in all the routers? =95 s/When an IGMP join is received/When an IGMP/MLD join is received/ =95 s/a neighbor Hello with/a PIM Hello with/ =95 What happens when a PIM router supporting this new options times out = in PIM DR router? =95 Does PIM DR insert its own address as well in the neighbor's address = into the LBGRD TLV list? =95 In section 6.2, first para talks about router R1. Is it referring to = figure 1? =95 In section 6.2, should not we mention what a GDR candidate does when = a PIM hello from PIM DR is received? I think few last paras at the end of= this section should be in the front. Please check. =95 s/from a non-DR PIM router/from a PIM router which is not DR/ =95 In section 6.2, its not clear if the hash is calculated only for 'X' = or for all the GDR available in the list. I think it needs to be calculat= ed for all of them and then if hash is highest for 'X', its selected, oth= erwise not. =95 In section 6.3, in case of PIM assert, should not we override the exi= sting Assert algorithm completely and suggest that the winner should be s= elected based on the currently selected GDR? =95 What happens when a new router comes up which becomes the DR but does= not support this new PIM hello option? =95 What is the need of sending out the list of GDR by PIM DR to other ro= uters? Other routers can anyway figure this out because they also receive= the PIM hello from other routers. Right? =95 In section 8, "PIM DR Load Balancing Hello message", does not look ri= ght. **************** 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 stig@venaas.com Fri Jun 28 10:55:07 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C75921F9C12 for ; Fri, 28 Jun 2013 10:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 5WPvGRPXuA5O for ; Fri, 28 Jun 2013 10:55:06 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 315B321F9BF5 for ; Fri, 28 Jun 2013 10:55:06 -0700 (PDT) Received: from [10.21.93.143] (128-107-239-234.cisco.com [128.107.239.234]) by ufisa.uninett.no (Postfix) with ESMTPSA id D96E0804B for ; Fri, 28 Jun 2013 19:55:02 +0200 (CEST) Message-ID: <51CDCF1C.6050108@venaas.com> Date: Fri, 28 Jun 2013 10:59:56 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "pim@ietf.org" References: <20130627215038.17941.35680.idtracker@ietfa.amsl.com> In-Reply-To: <20130627215038.17941.35680.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130627215038.17941.35680.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [pim] Fwd: IETF 87 Preliminary Agenda X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 17:55:07 -0000 The preliminary agenda is ready. pim is currently scheduled for Thursday 1300. See details below. Note that the agenda, including the pim slot, may still change. Stig -------- Original Message -------- Subject: IETF 87 Preliminary Agenda Date: Thu, 27 Jun 2013 14:50:38 -0700 From: IETF Agenda Reply-To: IETF Agenda To: Working Group Chairs CC: irsg@irtf.org Hello Everyone, The preliminary agenda for IETF 87 is available for viewing. Please note the cut-off date for requests to reschedule Working Group, IRTF, and BoF meetings is July 1st, 2013. The final agenda will be published on July 5th, 2013. This agenda is extremely full and changes will be difficult to make. Please take that into consideration before requesting any changes. https://datatracker.ietf.org/meeting/87/agenda.html https://datatracker.ietf.org/meeting/87/agenda.txt Thank you! Stephanie McCammon From ice@cisco.com Sat Jun 29 00:13:00 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD0F21F9A2C for ; Sat, 29 Jun 2013 00:13:00 -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 dI0ke3IOxcRy for ; Sat, 29 Jun 2013 00:12:56 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 01A5221F9989 for ; Sat, 29 Jun 2013 00:12:40 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5T7CYpu009431; Sat, 29 Jun 2013 09:12:34 +0200 (CEST) Received: from ams-iwijnand-8719.cisco.com (ams-iwijnand-8719.cisco.com [10.55.191.154]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5T7BbAT002225; Sat, 29 Jun 2013 09:11:53 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=windows-1252 From: IJsbrand Wijnands In-Reply-To: <35347FBF2796F94E936EE76C0E6047ED32E79439@BLRKECMBX13.ad.infosys.com> Date: Sat, 29 Jun 2013 09:11:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <35347FBF2796F94E936EE76C0E6047ED32E79439@BLRKECMBX13.ad.infosys.com> To: Bharat Joshi X-Mailer: Apple Mail (2.1499) Cc: Mike McBride , "pim@ietf.org" Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 07:13:00 -0000 Hi Bharat, Thanks for the comments, see comments inline; > =95 In section 7, "from the first Explicit vector in the stack" -> = "from the topmost Explicit vector in the stack" Ice: Ok. > =95 A small typo in "The Metric will therefore not be a tie breaker in = the PIM Assert", it should use "not to be a tie" Ice: Your suggestion does not read to well IMO. > =95 In section 7, in following statement: >=20 > However, the first Explicit vector should always be directly = connected, so the Metric will be zero. >=20 > I think it is not correct to assume that directly connected = route's has a metric of zero. IIRC, some vendors provide means to = configure such a metric. >=20 Ice: We can change 'will' into 'may likely'. > =95 In section 9, "support the Explicit Vector MUST never" -> "support = the Explicit Vector attribute MUST never" Ice: The draft is about documenting 'Explicit Vector' as a new PIM = attribute. Is it not obvious that if we talk about 'Explicit Vector', = this is an attribute? >=20 > =95 In section 9, in following statement: >=20 > Routers that don't support the Explicit Vector MUST never forward the = vector to their upstream PIM neighbor.=20 >=20 > With above statement, its not clear if the attribute should not be = forwarded or the PIM join itself should not be forwarded upstream. A PIM = join can still be forwarded using normal means if required. Ice: We can clarify, a normal PIM join is allowed. >=20 > =95 Will things work if both Explicit RPF vector and normal RPF vector = attributes are available in a PIM join? Or should we say that they = cannot be used together? Ice: Nothing prevents that. > =95 If the above is possible, can someone support a PIM join with = first few explicit RPF vector attributes, then a normal RPF vector and = then again few explicit RPF vector? Such a thing may be required if the = customer is using a VPN and want to create the tree in his local network = as well as remote network based on his own requirements. I am not sure = if such a requirement exists or not. I am just checking if such a = flexibility is allowed. Ice: Yes. >=20 > =95 In section 12, "RPF Vector Attribute" -> "Explicit RPF Vector = Attribute" >=20 > =95 In security consideration, should not we also mention that = Explicit RPF Vector Attribute itself does not add any security = implications on PIM-SM functioning. Ice: Does -01 not already address this? > =95 In section 5, I think following sentence should be reword: >=20 > This draft uses vector attribute 4 for specifying an explicit RPF = vector. >=20 > to >=20 > This draft uses PIM Join attribute type 4 for specifying an Explicit = RPF Vector Attribute. Ice: Ok. Thx, Ice. >=20 > ________________________________________ > From: pim-bounces@ietf.org [pim-bounces@ietf.org] on behalf of Michael = McBride [Michael.McBride@huawei.com] > Sent: Tuesday, June 25, 2013 12:07 PM > To: Mike McBride; pim@ietf.org > Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 >=20 > The wglc has ended and we have received solid consensus to progress = this draft. Thank you for your responses. The authors have addressed the = wglc comments in an updated draft which we will be sending to Adrian and = the iesg folks: = http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-01.txt >=20 > Bharat, please make sure this updated draft addresses your comments. = We will send to Adrian this Friday. >=20 > Thanks, > mike >=20 >> -----Original Message----- >> From: pim-bounces@ietf.org [mailto:pim-bounces@ietf.org] On Behalf Of >> Mike McBride >> Sent: Monday, June 10, 2013 11:27 PM >> To: pim@ietf.org >> Subject: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 >>=20 >> This is a recently adopted draft and the authors feel it is now ready >> for progression. Its a short draft so we likely don't have a good >> excuse to not read it over the next week. And then please express an >> opinion on this drafts readiness for being sent to the IESG as an >> Informational RFC: >>=20 >> http://www.ietf.org/id/draft-ietf-pim-explicit-rpf-vector-00.txt >>=20 >> We will end this WGLC on June 24th. Please speak up before then. >>=20 >> thanks, >> mike >> _______________________________________________ >> pim mailing list >> pim@ietf.org >> https://www.ietf.org/mailman/listinfo/pim > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim >=20 > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended = solely=20 > for the use of the addressee(s). If you are not the intended = recipient, please=20 > notify the sender by e-mail and delete the original message. Further, = you are not=20 > to copy, disclose, or distribute this e-mail or its contents to any = other person and=20 > any such actions are unlawful. This e-mail may contain viruses. = Infosys has taken=20 > every reasonable precaution to minimize this risk, but is not liable = for any damage=20 > you may sustain as a result of any virus in this e-mail. You should = carry out your=20 > own virus checks before opening the e-mail or attachment. Infosys = reserves the=20 > right to monitor and review the content of all messages sent to or = from this e-mail=20 > address. Messages sent to or from this e-mail address may be stored on = the=20 > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > pim mailing list > pim@ietf.org > https://www.ietf.org/mailman/listinfo/pim >=20 From bharat_joshi@infosys.com Sun Jun 30 20:58:56 2013 Return-Path: X-Original-To: pim@ietfa.amsl.com Delivered-To: pim@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D34321F9CDD for ; Sun, 30 Jun 2013 20:58:56 -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 doSRG8nHfccT for ; Sun, 30 Jun 2013 20:58:51 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 66C0421F9CD0 for ; Sun, 30 Jun 2013 20:58:50 -0700 (PDT) X-TM-IMSS-Message-ID: <1354219e000239db@infosys.com> Received: from BLRKECHUB05.ad.infosys.com ([10.66.236.45]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 1354219e000239db ; Mon, 1 Jul 2013 09:36:08 +0530 Received: from BLRKECHUB06.ad.infosys.com (10.66.236.116) by BLRKECHUB05.ad.infosys.com (10.66.236.45) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 1 Jul 2013 09:28:26 +0530 Received: from BLRKECMBX13.ad.infosys.com ([fe80::c43d:ba67:abc0:11c3]) by BLRKECHUB06.ad.infosys.com ([::1]) with mapi id 14.02.0318.004; Mon, 1 Jul 2013 09:28:25 +0530 From: Bharat Joshi To: IJsbrand Wijnands Thread-Topic: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 Thread-Index: AQHOZmzCcLVgOtShME6OYjSowDCfT5lGCnmggAAdk0qABd6wgIADSU0A Date: Mon, 1 Jul 2013 03:58:25 +0000 Message-ID: <35347FBF2796F94E936EE76C0E6047ED32E89922@BLRKECMBX13.ad.infosys.com> References: , <35347FBF2796F94E936EE76C0E6047ED32E79439@BLRKECMBX13.ad.infosys.com>, In-Reply-To: Accept-Language: en-US, en-IN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.132] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mike McBride , "pim@ietf.org" Subject: Re: [pim] WGLC on draft-ietf-pim-explicit-rpf-vector-00 X-BeenThere: pim@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Protocol Independent Multicast List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 03:58:56 -0000 Hi, Please see few replies in line with . Regards, Bharat > =95 A small typo in "The Metric will therefore not be a tie breaker in = the PIM Assert", it should use "not to be a tie" Ice: Your suggestion does not read to well IMO. : Ok. Will leave this to authors. > =95 In section 7, in following statement: > > However, the first Explicit vector should always be directly connected,= so the Metric will be zero. > > I think it is not correct to assume that directly connected route's= has a metric of zero. IIRC, some vendors provide means to configure such= a metric. > Ice: We can change 'will' into 'may likely'. : That may not solve the problem. My thinking is that we should a= llow it to compare metrics as it is. If they are same, they will anyway f= allback on the other parameters like IP address. So why to add a special = case here? > =95 In section 9, "support the Explicit Vector MUST never" -> "support = the Explicit Vector attribute MUST never" Ice: The draft is about documenting 'Explicit Vector' as a new PIM attrib= ute. Is it not obvious that if we talk about 'Explicit Vector', this is a= n attribute? : While I agree that it is obvious but my thinking is that it is = better to be consistent across. I suggested this because most of the plac= es this draft uses 'Attribute' as well. > =95 In section 9, in following statement: > > Routers that don't support the Explicit Vector MUST never forward the v= ector to their upstream PIM neighbor. > > With above statement, its not clear if the attribute should not be = forwarded or the PIM join itself should not be forwarded upstream. A PIM = join can still be forwarded using normal means if required. Ice: We can clarify, a normal PIM join is allowed. : Ok. > =95 Will things work if both Explicit RPF vector and normal RPF vector = attributes are available in a PIM join? Or should we say that they cannot= be used together? Ice: Nothing prevents that. : I think it is better to clarify this in the document. This will= help an implementor as well as a reader. > =95 If the above is possible, can someone support a PIM join with first= few explicit RPF vector attributes, then a normal RPF vector and then ag= ain few explicit RPF vector? Such a thing may be required if the customer= is using a VPN and want to create the tree in his local network as well = as remote network based on his own requirements. I am not sure if such a = requirement exists or not. I am just checking if such a flexibility is al= lowed. Ice: Yes. : Ok. > > =95 In section 12, "RPF Vector Attribute" -> "Explicit RPF Vector Attri= bute" : I am assuming that this one will be taken care of. > =95 In security consideration, should not we also mention that Explicit= RPF Vector Attribute itself does not add any security implications on PI= M-SM functioning. Ice: Does -01 not already address this? : It is mentioned but not from this new attribute perspective, pl= ease relook at that text. **************** 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***