From nobody Wed Apr 1 04:58:33 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CE21A89A3 for ; Wed, 1 Apr 2015 04:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZforrumLeoh for ; Wed, 1 Apr 2015 04:58:31 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E1F1A890F for ; Wed, 1 Apr 2015 04:58:30 -0700 (PDT) Received: by qgf60 with SMTP id 60so39641613qgf.3 for ; Wed, 01 Apr 2015 04:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oO1P/Ys9+2Te1f0+y9Jp1cTW35+Fuzqo44l0JoaZ3w4=; b=dpuOLlR4Eamoybme0hGwLYlzTjRoFZ6QSCAAmn1zuAkP2SzIG9YikJjCZqHQ35zugq VQ3xyasoA5NAOxpM0mXFg99wAkfitqhXC79BpvCr9ug9GlotU9ZK/rDjaxhSX1IJ9Tj0 bPe2pkEgRnWJcaVnJSjFlih6XlFUL3AAjXfhApBscvdJ2A0Q2nw1p2xm+rkP195ByR1E LItyhI+ANcQPH75NsfHQyz/bu4yZE+/qB8J5abvjmWDm7gF3K07g9mQqYDJWo76b1jNY rD2IcKt2ANd0mqWK8Gk8kp5BZsVSZqyCj6tA8wLWX0k70MVAhWfioMHWr56s9evaxFff J+yQ== X-Received: by 10.55.51.77 with SMTP id z74mr88944630qkz.84.1427889510266; Wed, 01 Apr 2015 04:58:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.104.170 with HTTP; Wed, 1 Apr 2015 04:58:08 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Wed, 1 Apr 2015 07:58:08 -0400 Message-ID: To: Vishnu Pavan Beeram Content-Type: multipart/alternative; boundary=001a1149011609be7e0512a86fa7 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 11:58:33 -0000 --001a1149011609be7e0512a86fa7 Content-Type: text/plain; charset=UTF-8 Pavan, Thanks for the recommendations. They could certainly be addressed by bringing back RFC 3212 (but note today's date, I deliberately waited six days to send this email :-). Cheers, Andy On Thu, Mar 26, 2015 at 3:09 PM, Vishnu Pavan Beeram wrote: > https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01 > > Folks, Hi! > > was presented earlier today in the > TEAS WG session. There wasn't sufficient time to take in questions at the > end of the presentation (apologize for that). So, I'm opening up this > thread to make sure that all those questions get answered. > > A few points to note: > > 1. These recommendations were put together for catering to current MPLS > RSVP-TE Scalability needs. But since most of them have generic > applicability, this draft is being discussed in TEAS. > > 2. There are 3 underlying principles driving these recommendations > - Completely eliminate the reliance on refreshes for state sync. > - Completely eliminate the reliance on refresh timeouts for stale state > cleanup. > - Implement per-peer flow control. > > 3. This is not a theoretical exercise. We have an implementation that > religiously adopts these recommendations -- and the savings in terms of > processing cycles for the control-plane (as a result of the significant > reduction in I/O overhead) is quite significant. > > Please do give these recommendations some serious consideration and let us > know your questions/comments. > > Regards, > -Pavan > (on behalf of the authors) > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > --001a1149011609be7e0512a86fa7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pavan,

Thanks for the recommendations. = They could certainly be addressed by bringing back RFC 3212 (but note today= 's date, I deliberately waited six days to send this email :-).

Cheers,
Andy


On Thu, Mar 26, 2015 at 3= :09 PM, Vishnu Pavan Beeram <vishnupavan@gmail.com> wrot= e:
<draft-beeram-mpls-rsvp-te-scaling>= was presented earlier today in the TEAS WG session. There wasn't suffi= cient time to take in questions at the end of the presentation (apologize f= or that). So, I'm opening up this thread to make sure that all those qu= estions get answered.

A few points to note:

=
1. These recommendations were put together for catering to current MPL= S RSVP-TE Scalability needs. But since most of them have generic applicabil= ity, this draft is being discussed in TEAS.

2. There are = 3 underlying principles driving these recommendations
- Comp= letely eliminate the reliance on refreshes for state sync.
- = Completely eliminate the reliance on refresh timeouts for stale state clean= up.
- Implement per-peer flow control.

3. T= his is not a theoretical exercise. We have an implementation that religious= ly adopts these recommendations -- and the savings in terms of processing c= ycles for the control-plane (as a result of the significant reduction in I/= O overhead) is quite significant.

Please do give these re= commendations some serious consideration and let us know your questions/com= ments.

Regards,
-Pavan
(on be= half of the authors)




_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--001a1149011609be7e0512a86fa7-- From nobody Wed Apr 1 05:48:35 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C2E1A8AB2 for ; Wed, 1 Apr 2015 05:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPi-2KY7_oII for ; Wed, 1 Apr 2015 05:48:30 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F9A1A8ACD for ; Wed, 1 Apr 2015 05:48:29 -0700 (PDT) Received: from MUC-SRV-MBX2.advaoptical.com ([172.20.1.96]) by muc-vsrv-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t31CmQpE025108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 14:48:26 +0200 Received: from MUC-S-EX13B.advaoptical.com (172.20.1.17) by MUC-SRV-MBX2.advaoptical.com (172.20.1.96) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 1 Apr 2015 14:48:26 +0200 Received: from MUC-S-EX13B.advaoptical.com (172.20.1.17) by MUC-S-EX13B.advaoptical.com (172.20.1.17) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 1 Apr 2015 14:48:25 +0200 Received: from MUC-S-EX13B.advaoptical.com ([fe80::f1d8:4863:55fc:7577]) by MUC-S-EX13B.advaoptical.com ([fe80::f1d8:4863:55fc:7577%15]) with mapi id 15.00.1076.000; Wed, 1 Apr 2015 14:48:25 +0200 From: =?utf-8?B?UGF3ZcWCIEJyem96b3dza2k=?= To: Vishnu Pavan Beeram Thread-Topic: [Teas] RSVP TE Scalability - Recommendations Thread-Index: AQHQZ/hymseFyKa2RUWbwO6Imiz9GZ0vFkiAgAAGq4CACAG94IAAVDaAgACwPsA= Date: Wed, 1 Apr 2015 12:48:25 +0000 Message-ID: <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> References: <55145EA1.3010905@pi.nu> <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> In-Reply-To: Accept-Language: pl-PL, de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.27.50] Content-Type: multipart/alternative; boundary="_000_79bd84a38c964717a963da3223359266MUCSEX13Badvaopticalcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-01_04:2015-04-01,2015-04-01,1970-01-01 signatures=0 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 12:48:34 -0000 --_000_79bd84a38c964717a963da3223359266MUCSEX13Badvaopticalcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGF2YW4sDQoNCnlvdSB3cm90ZToNCg0K4oCcVlBCPD0+IElmIHRoZSBlbGVtZW50cyBpbiB0aGlz IHRyYW5zcG9ydCBuZXR3b3JrIG9mIHlvdXJzIGFyZSBydW5uaW5nIHN0YW5kYXJkIEdNUExTIENv bnRyb2wtUGxhbmUgKG5vdCBzb21lIEdNUExTIGJhc2VkIHByb3ByaWV0YXJ5IHZlcnNpb24pLCBw bGVhc2UgZWxhYm9yYXRlIHdoeSB5b3UgY2FuJ3QgY291cGxlIHRoZSBzdGF0ZSBvZiBpbmRpdmlk dWFsIExTUHMgd2l0aCB0aGUgc3RhdGUgb2YgdGhlIGNvcnJlc3BvbmRpbmcgUlNWUC1URSBzaWdu YWxpbmcgYWRqYWNlbmN5LiBJZiBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2xlYW51cCB0aGUgTFNQ LXN0YXRlIHdoZW4gdGhlIHJlZnJlc2ggdGltZXMgb3V0LCB0aGVuIGl0IHNob3VsZCBhbHNvIGJl IGFibGUgdG8gY2xlYW51cCB0aGUgTFNQLXN0YXRlIHdoZW4gdGhlIGhlbGxvLWFkamFjZW5jeSBn b2VzIGRvd24uIEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGFyZSBwcm9wcmlldGFyeSBpbXBsZW1l bnRhdGlvbnMgdGhhdCBkbyBub3QgY2xlYW51cCB0aGUgTFNQLXN0YXRlIHdoZW4gdGhlIHJlZnJl c2ggdGltZXMgb3V0IC0tIHRob3NlIHByb3ByaWV0YXJ5IGltcGxlbWVudGF0aW9ucyBtaWdodCBu ZWVkIHNvbWUgYWRkaXRpb25hbCBwcm9jZWR1cmVzICh0aGlzIGRyYWZ0IHdpbGwgbm90IGZ1cm5p c2ggdGhvc2UpLuKAnQ0KSSBndWVzcyB0aGlzIGlzIHdoZXJlIG91ciBkaXNjb25uZWN0IGNvbWVz IGZyb20uIFlvdSBjZXJ0YWlubHkga25vdyBSRkNzIGJldHRlciB0aGFuIG1lLiBJIGFzc3VtZWQg dGhhdCBJRVRGIHJlY29tbWVuZGF0aW9uIGZvciBHTVBMUyBydW5uaW5nIGluIHRyYW5zcG9ydCBu ZXR3b3JrcyB3b3VsZCBiZSBOT1QgdG8gY2xlYW51cCBsc3Agc3RhdGUgd2hlbiByZWZyZXNoZXMg dGltZSBvdXQuIElzIGl0IG5vdCB0aGUgY2FzZT8NCg0KVGhhbmtzLA0KUGF3ZWwNCg0KRnJvbTog VmlzaG51IFBhdmFuIEJlZXJhbSBbbWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgQXByaWwgMDEsIDIwMTUgMTI6MTMgQU0NClRvOiBQYXdlxYIgQnJ6b3pvd3Nr aQ0KQ2M6IHRlYXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVGVhc10gUlNWUCBURSBTY2FsYWJp bGl0eSAtIFJlY29tbWVuZGF0aW9ucw0KDQpQYXdlbCwgSGkhDQpUaGFua3MgZm9yIHRoZSByZXNw b25zZS4gUGxlYXNlIHNlZSBpbmxpbmUuDQpSZWdhcmRzLA0KLVBhdmFuDQoNCk9uIFR1ZSwgTWFy IDMxLCAyMDE1IGF0IDU6MzAgUE0sIFBhd2XFgiBCcnpvem93c2tpIDxQQnJ6b3pvd3NraUBhZHZh b3B0aWNhbC5jb208bWFpbHRvOlBCcnpvem93c2tpQGFkdmFvcHRpY2FsLmNvbT4+IHdyb3RlOg0K UGF2YW4sDQoNCkkgdGhpbmsgdGhpcyBpcyBncmVhdCB3b3JrIGFuZCBhcHBsaWVzIHdlbGwgdG8g dGhlIHBhY2tldCBuZXR3b3Jrcy4gSW1obyB0aGUgZHJhZnQgc2hvdWxkIGJlIGF1Z21lbnRlZCB0 byByZWZsZWN0IHRvIHdoYXQgaXMgdGhlIGRlZ3JlZSBvZiBhcHBsaWNhYmlsaXR5IHRvIHRyYW5z cG9ydCBuZXR3b3Jrcy4NCg0KVlBCIDw9PiBBcyBtZW50aW9uZWQgZWFybGllciwgdGhlIHJlY29t bWVuZGF0aW9ucyBpbiB0aGUgZHJhZnQgd2VyZSBwdXQgdG9nZXRoZXIgdG8gY2F0ZXIgdG8gTVBM UyBSU1ZQLVRFIExTUHMuIFRoZSBhdXRob3JzIGRpZG4ndCBjb25zaWRlciB0aGUgYXBwbGljYWJp bGl0eSBvZiB0aGVzZSByZWNvbW1lbmRhdGlvbnMgdG8gbm9uLXBzYyBHTVBMUyBMU1BzIGF0IGFs bCBpbiB0aGUgaW5pdGlhbCByZXZpc2lvbiAtLSB3ZSBzaW1wbHkgZGlkbid0IGNhcmUgOikuIEJ1 dCBzaW5jZSBpdCB3YXMgcG9pbnRlZCBvdXQgdG8gdXMgdGhhdCBtb3N0IG9mIHRoZXNlIHJlY29t bWVuZGF0aW9ucyBoYXZlIGdlbmVyaWMgYXBwbGljYWJpbGl0eSwgSSBhZ3JlZSB0aGF0IGl0IHdv dWxkIGJlIHVzZWZ1bCB0byBjbGFyaWZ5IHRoZSBkZWdyZWUgb2YgYXBwbGljYWJpbGl0eSB0byBz dWNoIG5ldHdvcmtzIGluIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkcmFmdC4gQXQgYSBoaWdo LWxldmVsLCBldmVyeXRoaW5nIGV4Y2VwdCBTZWN0aW9uIDIuNSAoR01QTFMgUlNWUC1URSBMU1Bz IGRvIG5vdCB1c2UgUm91dGVyLUFsZXJ0IGZvciBQYXRocykgYW5kIFNlY3Rpb24gMi42ICh0aGVy ZSBhcmUgZGlmZmVyZW50IHdheXMgb2YgY2hlY2tpbmcgZGF0YS1wbGFuZSByZWFkaW5lc3MgZm9y IG5vbiBwc2MgTFNQcykgc2hvdWxkIGhhdmUgZ2VuZXJpYyBhcHBsaWNhYmlsaXR5Lg0KDQpZb3Ug c2FpZDoNCg0K4oCcVGhlcmUgYXJlIDMgdW5kZXJseWluZyBwcmluY2lwbGVzIGRyaXZpbmcgdGhl c2UgcmVjb21tZW5kYXRpb25zOg0KLSBDb21wbGV0ZWx5IGVsaW1pbmF0ZSB0aGUgcmVsaWFuY2Ug b24gcmVmcmVzaGVzIGZvciBzdGF0ZSBzeW5jLg0KLSBDb21wbGV0ZWx5IGVsaW1pbmF0ZSB0aGUg cmVsaWFuY2Ugb24gcmVmcmVzaCB0aW1lb3V0cyBmb3Igc3RhbGUgc3RhdGUNCmNsZWFudXAuDQot IEltcGxlbWVudCBwZXItcGVlciBmbG93IGNvbnRyb2wu4oCdDQoNCkluIG9yZGVyIHRvIGFjaGll dmUgdGhlc2UgcHJpbmNpcGxlcyB5b3UgcmVjb21tZW5kIOKAnEltcGxlbWVudGluZyBjb3VwbGlu ZyB0aGUgc3RhdGUgb2YgaW5kaXZpZHVhbCBMU1BzIHdpdGggdGhlIHN0YXRlIG9mIHRoZSBjb3Jy ZXNwb25kaW5nIFJTVlAtVEUgc2lnbmFsaW5nIGFkamFjZW5jeS7igJ0gKGNvcGllZCBmcm9tIHRo ZSBkcmFmdCkuIFNpbmNlIGluIHRoZSB0cmFuc3BvcnQgbmV0d29yayB5b3UgcmVhbGx5IHNob3Vs ZG7igJl0IGRvIHRoYXQsIEnigJltIGludGVyZXN0ZWQgaG93IHlvdSBjYW4gZnVsZmlsbCBhYm92 ZSBtZW50aW9uZWQgcHJpbmNpcGxlcyB3aXRob3V0IGl0Lg0KDQpWUEI8PT4gSWYgdGhlIGVsZW1l bnRzIGluIHRoaXMgdHJhbnNwb3J0IG5ldHdvcmsgb2YgeW91cnMgYXJlIHJ1bm5pbmcgc3RhbmRh cmQgR01QTFMgQ29udHJvbC1QbGFuZSAobm90IHNvbWUgR01QTFMgYmFzZWQgcHJvcHJpZXRhcnkg dmVyc2lvbiksIHBsZWFzZSBlbGFib3JhdGUgd2h5IHlvdSBjYW4ndCBjb3VwbGUgdGhlIHN0YXRl IG9mIGluZGl2aWR1YWwgTFNQcyB3aXRoIHRoZSBzdGF0ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBS U1ZQLVRFIHNpZ25hbGluZyBhZGphY2VuY3kuIElmIGFuIGltcGxlbWVudGF0aW9uIGNhbiBjbGVh bnVwIHRoZSBMU1Atc3RhdGUgd2hlbiB0aGUgcmVmcmVzaCB0aW1lcyBvdXQsIHRoZW4gaXQgc2hv dWxkIGFsc28gYmUgYWJsZSB0byBjbGVhbnVwIHRoZSBMU1Atc3RhdGUgd2hlbiB0aGUgaGVsbG8t YWRqYWNlbmN5IGdvZXMgZG93bi4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgYXJlIHByb3ByaWV0 YXJ5IGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIG5vdCBjbGVhbnVwIHRoZSBMU1Atc3RhdGUgd2hl biB0aGUgcmVmcmVzaCB0aW1lcyBvdXQgLS0gdGhvc2UgcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRp b25zIG1pZ2h0IG5lZWQgc29tZSBhZGRpdGlvbmFsIHByb2NlZHVyZXMgKHRoaXMgZHJhZnQgd2ls bCBub3QgZnVybmlzaCB0aG9zZSkuDQpUbyBnaXZlIGFuIGV4YW1wbGU6DQoNClByaW5jaXBsZSAy OiDigJxDb21wbGV0ZWx5IGVsaW1pbmF0ZSB0aGUgcmVsaWFuY2Ugb24gcmVmcmVzaCB0aW1lb3V0 cyBmb3Igc3RhbGUgc3RhdGXigJ0NCg0KSW4gdGhlIGRyYWZ0IHlvdSBhc3N1bWUgdGhhdCBzdGFs ZSBzdGF0ZSB3aWxsIGJlIHJlbW92ZWQgdGhhbmtzIHRvOiBhKSByZWxpYWJsZSBUZWFyL0VyciBt ZXNzYWdlcyBkZWxpdmVyeSBhbmQgYikgcmVtb3Zpbmcgb2YgbHNwIHN0YXRlIGFmdGVyIGFkamFj ZW5jeSBsb3NzLiBTaW5jZSBiKSBkb2VzIG5vdCB3b3JrIGluIHRyYW5zcG9ydCwgaG93IGNhbiB5 b3UgY292ZXIgc2NlbmFyaW9zIGludm9sdmluZyBhIHJlYm9vdCBvZiBhIFJTVlAgc3BlYWtlciB3 aGlsZSB0aGUgc2VydmljZSBpcyB0b3JuIGRvd24gZS5nLiBieSBQYXRoVGVhcj8NCg0KDQpWUEIg PD0+IEFnYWluLCBwbGVhc2UgZWxhYm9yYXRlIHdoeSB5b3UgY2Fubm90IHJlbW92ZSBMU1AgYWZ0 ZXIgYWRqYWNlbmN5IGxvc3MgaWYgeW91IGFyZSB1c2luZyBzdGFuZGFyZCBHTVBMUyBSU1ZQLVRF Lg0KDQpUaGFua3MsDQpQYXdlbA0KDQoNCkZyb206IFRlYXMgW21haWx0bzp0ZWFzLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnRlYXMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBWaXNo bnUgUGF2YW4gQmVlcmFtDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMzo1NiBQTQ0K VG86IExvYSBBbmRlcnNzb24NCkNjOiB0ZWFzQGlldGYub3JnPG1haWx0bzp0ZWFzQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtUZWFzXSBSU1ZQIFRFIFNjYWxhYmlsaXR5IC0gUmVjb21tZW5kYXRp b25zDQoNCkxvYSwgSGkhDQpUaGFua3MgZm9yIHBvaW50aW5nIGl0IG91dC4NClllcywgbm90IHJl ZmVyZW5jaW5nL21lbnRpb25pbmcgUkZDIDU0Mzkgd2FzIGEgbWlzdGFrZSBhbmQgdGhhdCB3b3Vs ZCBiZSByZWN0aWZpZWQgaW4gdGhlIG5leHQgdmVyc2lvbi4gKEJ1dCBJIGRpZCBtZW50aW9uIFJG QzU0MzkgaW4gdGhpcyBtb3JuaW5nJ3MgcHJlc2VudGF0aW9uIDopKS4NCkJvdGggUkZDMjk2MSBh bmQgUkZDNTQzOSBkbyB0YWxrIGFib3V0IGhhdmluZyBhIGxhcmdlIHJlZnJlc2ggaW50ZXJ2YWwg YXMgYSBtZWFucyBvZiByZWR1Y2luZyB0aGUgcmF0ZSBvZiBtZXNzYWdlcyB0aGF0IHRoZSBjb250 cm9sLXBsYW5lIGhhcyB0byBwcm9jZXNzLCBidXQgYWxzbyB3YXJuIGFib3V0IHRoZSBsb3NzIG9m IGZ1bmN0aW9uYWxpdHkgYXNzb2NpYXRlZCB3aXRoIGRvaW5nIHNvLiA8ZHJhZnQtYmVlcmFtLW1w bHMtcnN2cC10ZS1zY2FsaW5nPiBicmluZ3MgYmFjayB0aGUgbm90aW9uIG9mIHJlZnJlc2ggaW5k ZXBlbmRlbnQgUlNWUCwgYnV0IGFsc28gaW5jbHVkZXMgcmVjb21tZW5kYXRpb25zIHRoYXQgd291 bGQgbWFrZSBzdXJlIHRoYXQgdGhlcmUgaXMgbm8gbG9zcyBvZiBmdW5jdGlvbmFsaXR5IHdoZW4g YSBsYXJnZSByZWZyZXNoIGludGVydmFsIGlzIHVzZWQuDQpSZWdhcmRzLA0KLVBhdmFuDQoNCg0K T24gVGh1LCBNYXIgMjYsIDIwMTUgYXQgMzozMSBQTSwgTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51 PG1haWx0bzpsb2FAcGkubnU+PiB3cm90ZToNClBhdmFuLA0KDQpUaGUgTVBMUyB3ZyBkaWQgIkFu IEFuYWx5c2lzIG9mIFNjYWxpbmcgSXNzdWVzIGluIE1QTFMtVEUgQ29yZSBOZXR3b3JrcyINClJG QyA1NDM5LiBUaGlzIFJGQyBpcyBub3QgbWVudGlvbmVkIGluIGRyYWZ0LWJlZXJhbS1tcGxzLXJz dnAtDQp0ZS1zY2FsaW5nLiBUaGUgdG9waWNzIHNlZW1zIGNsb3NlIGVub3VnaCB0byBtYWtlIHdv cnRoIGxvb2sgYXQgdGhhdA0KZG9jdW1lbnQuDQoNCi9Mb2ENCg0KDQoNCg0KT24gMjAxNS0wMy0y NiAxNDowOSwgVmlzaG51IFBhdmFuIEJlZXJhbSB3cm90ZToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1iZWVyYW0tbXBscy1yc3ZwLXRlLXNjYWxpbmctMDENCg0KRm9sa3MsIEhp IQ0KDQo8ZHJhZnQtYmVlcmFtLW1wbHMtcnN2cC10ZS1zY2FsaW5nPiB3YXMgcHJlc2VudGVkIGVh cmxpZXIgdG9kYXkgaW4gdGhlDQpURUFTIFdHIHNlc3Npb24uIFRoZXJlIHdhc24ndCBzdWZmaWNp ZW50IHRpbWUgdG8gdGFrZSBpbiBxdWVzdGlvbnMgYXQNCnRoZSBlbmQgb2YgdGhlIHByZXNlbnRh dGlvbiAoYXBvbG9naXplIGZvciB0aGF0KS4gU28sIEknbSBvcGVuaW5nIHVwDQp0aGlzIHRocmVh ZCB0byBtYWtlIHN1cmUgdGhhdCBhbGwgdGhvc2UgcXVlc3Rpb25zIGdldCBhbnN3ZXJlZC4NCg0K QSBmZXcgcG9pbnRzIHRvIG5vdGU6DQoNCjEuIFRoZXNlIHJlY29tbWVuZGF0aW9ucyB3ZXJlIHB1 dCB0b2dldGhlciBmb3IgY2F0ZXJpbmcgdG8gY3VycmVudCBNUExTDQpSU1ZQLVRFIFNjYWxhYmls aXR5IG5lZWRzLiBCdXQgc2luY2UgbW9zdCBvZiB0aGVtIGhhdmUgZ2VuZXJpYw0KYXBwbGljYWJp bGl0eSwgdGhpcyBkcmFmdCBpcyBiZWluZyBkaXNjdXNzZWQgaW4gVEVBUy4NCg0KMi4gVGhlcmUg YXJlIDMgdW5kZXJseWluZyBwcmluY2lwbGVzIGRyaXZpbmcgdGhlc2UgcmVjb21tZW5kYXRpb25z DQotIENvbXBsZXRlbHkgZWxpbWluYXRlIHRoZSByZWxpYW5jZSBvbiByZWZyZXNoZXMgZm9yIHN0 YXRlIHN5bmMuDQotIENvbXBsZXRlbHkgZWxpbWluYXRlIHRoZSByZWxpYW5jZSBvbiByZWZyZXNo IHRpbWVvdXRzIGZvciBzdGFsZSBzdGF0ZQ0KY2xlYW51cC4NCi0gSW1wbGVtZW50IHBlci1wZWVy IGZsb3cgY29udHJvbC4NCg0KMy4gVGhpcyBpcyBub3QgYSB0aGVvcmV0aWNhbCBleGVyY2lzZS4g V2UgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0DQpyZWxpZ2lvdXNseSBhZG9wdHMgdGhlc2Ug cmVjb21tZW5kYXRpb25zIC0tIGFuZCB0aGUgc2F2aW5ncyBpbiB0ZXJtcyBvZg0KcHJvY2Vzc2lu ZyBjeWNsZXMgZm9yIHRoZSBjb250cm9sLXBsYW5lIChhcyBhIHJlc3VsdCBvZiB0aGUgc2lnbmlm aWNhbnQNCnJlZHVjdGlvbiBpbiBJL08gb3ZlcmhlYWQpIGlzIHF1aXRlIHNpZ25pZmljYW50Lg0K DQpQbGVhc2UgZG8gZ2l2ZSB0aGVzZSByZWNvbW1lbmRhdGlvbnMgc29tZSBzZXJpb3VzIGNvbnNp ZGVyYXRpb24gYW5kIGxldA0KdXMga25vdyB5b3VyIHF1ZXN0aW9ucy9jb21tZW50cy4NCg0KUmVn YXJkcywNCi1QYXZhbg0KKG9uIGJlaGFsZiBvZiB0aGUgYXV0aG9ycykNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlz dA0KVGVhc0BpZXRmLm9yZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAg ICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzpsb2FA bWFpbDAxLmh1YXdlaS5jb20+DQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAg ICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KSHVhd2VpIFRlY2hub2xvZ2llcyAo Y29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDczOSUy MDgxJTIwMjElMjA2ND4NCg0KDQo= --_000_79bd84a38c964717a963da3223359266MUCSEX13Badvaopticalcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6UEw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJQTCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlBhdmFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPnlvdSB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPuKAnFZQQiZsdDs9Jmd0OyBJZiB0aGUgZWxlbWVu dHMgaW4gdGhpcyB0cmFuc3BvcnQgbmV0d29yayBvZiB5b3VycyBhcmUgcnVubmluZyBzdGFuZGFy ZCBHTVBMUyBDb250cm9sLVBsYW5lIChub3Qgc29tZSBHTVBMUyBiYXNlZCBwcm9wcmlldGFyeSB2 ZXJzaW9uKSwgcGxlYXNlIGVsYWJvcmF0ZSB3aHkgeW91IGNhbid0IGNvdXBsZSB0aGUNCiBzdGF0 ZSBvZiBpbmRpdmlkdWFsIExTUHMgd2l0aCB0aGUgc3RhdGUgb2YgdGhlIGNvcnJlc3BvbmRpbmcg UlNWUC1URSBzaWduYWxpbmcgYWRqYWNlbmN5LiBJZiBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2xl YW51cCB0aGUgTFNQLXN0YXRlIHdoZW4gdGhlIHJlZnJlc2ggdGltZXMgb3V0LCB0aGVuIGl0IHNo b3VsZCBhbHNvIGJlIGFibGUgdG8gY2xlYW51cCB0aGUgTFNQLXN0YXRlIHdoZW4gdGhlIGhlbGxv LWFkamFjZW5jeSBnb2VzIGRvd24uIEkNCiB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgYXJlIHByb3By aWV0YXJ5IGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIG5vdCBjbGVhbnVwIHRoZSBMU1Atc3RhdGUg d2hlbiB0aGUgcmVmcmVzaCB0aW1lcyBvdXQgLS0gdGhvc2UgcHJvcHJpZXRhcnkgaW1wbGVtZW50 YXRpb25zIG1pZ2h0IG5lZWQgc29tZSBhZGRpdGlvbmFsIHByb2NlZHVyZXMgKHRoaXMgZHJhZnQg d2lsbCBub3QgZnVybmlzaCB0aG9zZSku4oCdPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SSBndWVzcyB0aGlzIGlzIHdoZXJlIG91ciBkaXNjb25uZWN0IGNv bWVzIGZyb20uIFlvdSBjZXJ0YWlubHkga25vdyBSRkNzIGJldHRlciB0aGFuIG1lLiBJIGFzc3Vt ZWQgdGhhdCBJRVRGIHJlY29tbWVuZGF0aW9uIGZvciBHTVBMUyBydW5uaW5nIGluDQogdHJhbnNw b3J0IG5ldHdvcmtzIHdvdWxkIGJlIE5PVCB0byBjbGVhbnVwIGxzcCBzdGF0ZSB3aGVuIHJlZnJl c2hlcyB0aW1lIG91dC4gSXMgaXQgbm90IHRoZSBjYXNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5QYXdlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVmlzaG51IFBhdmFuIEJlZXJh bSBbbWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRu ZXNkYXksIEFwcmlsIDAxLCAyMDE1IDEyOjEzIEFNPGJyPg0KPGI+VG86PC9iPiBQYXdlxYIgQnJ6 b3pvd3NraTxicj4NCjxiPkNjOjwvYj4gdGVhc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW1RlYXNdIFJTVlAgVEUgU2NhbGFiaWxpdHkgLSBSZWNvbW1lbmRhdGlvbnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlBhd2VsLCBIaSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFu a3MgZm9yIHRoZSByZXNwb25zZS4gUGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1QYXZhbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciAzMSwg MjAxNSBhdCA1OjMwIFBNLCBQYXdlxYIgQnJ6b3pvd3NraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlBC cnpvem93c2tpQGFkdmFvcHRpY2FsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPlBCcnpvem93c2tpQGFk dmFvcHRpY2FsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5QYXZhbiw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGlz IGlzIGdyZWF0IHdvcmsgYW5kIGFwcGxpZXMgd2VsbCB0byB0aGUgcGFja2V0IG5ldHdvcmtzLiBJ bWhvIHRoZSBkcmFmdCBzaG91bGQNCiBiZSBhdWdtZW50ZWQgdG8gcmVmbGVjdCB0byB3aGF0IGlz IHRoZSBkZWdyZWUgb2YgYXBwbGljYWJpbGl0eSB0byB0cmFuc3BvcnQgbmV0d29ya3MuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VlBCICZsdDs9Jmd0OyBBcyBtZW50 aW9uZWQgZWFybGllciwgdGhlIHJlY29tbWVuZGF0aW9ucyBpbiB0aGUgZHJhZnQgd2VyZSBwdXQg dG9nZXRoZXIgdG8gY2F0ZXIgdG8gTVBMUyBSU1ZQLVRFIExTUHMuIFRoZSBhdXRob3JzIGRpZG4n dCBjb25zaWRlciB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGVzZSByZWNvbW1lbmRhdGlvbnMgdG8g bm9uLXBzYyBHTVBMUyBMU1BzIGF0DQogYWxsIGluIHRoZSBpbml0aWFsIHJldmlzaW9uIC0tIHdl IHNpbXBseSBkaWRuJ3QgY2FyZSA6KS4gQnV0IHNpbmNlIGl0IHdhcyBwb2ludGVkIG91dCB0byB1 cyB0aGF0IG1vc3Qgb2YgdGhlc2UgcmVjb21tZW5kYXRpb25zIGhhdmUgZ2VuZXJpYyBhcHBsaWNh YmlsaXR5LCBJIGFncmVlIHRoYXQgaXQgd291bGQgYmUgdXNlZnVsIHRvIGNsYXJpZnkgdGhlIGRl Z3JlZSBvZiBhcHBsaWNhYmlsaXR5IHRvIHN1Y2ggbmV0d29ya3MgaW4gdGhlIG5leHQgcmV2aXNp b24NCiBvZiB0aGUgZHJhZnQuIEF0IGEgaGlnaC1sZXZlbCwgZXZlcnl0aGluZyBleGNlcHQgU2Vj dGlvbiAyLjUgKEdNUExTIFJTVlAtVEUgTFNQcyBkbyBub3QgdXNlIFJvdXRlci1BbGVydCBmb3Ig UGF0aHMpIGFuZCBTZWN0aW9uIDIuNiAodGhlcmUgYXJlIGRpZmZlcmVudCB3YXlzIG9mIGNoZWNr aW5nIGRhdGEtcGxhbmUgcmVhZGluZXNzIGZvciBub24gcHNjIExTUHMpIHNob3VsZCBoYXZlIGdl bmVyaWMgYXBwbGljYWJpbGl0eS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3Ugc2FpZDo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxpPjxzcGFuIGxh bmc9IkVOLVVTIj7igJxUaGVyZSBhcmUgMyB1bmRlcmx5aW5nIHByaW5jaXBsZXMgZHJpdmluZyB0 aGVzZSByZWNvbW1lbmRhdGlvbnM6PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPi0gQ29tcGxldGVseSBlbGltaW5h dGUgdGhlIHJlbGlhbmNlIG9uIHJlZnJlc2hlcyBmb3Igc3RhdGUgc3luYy48YnI+DQotIENvbXBs ZXRlbHkgZWxpbWluYXRlIHRoZSByZWxpYW5jZSBvbiByZWZyZXNoIHRpbWVvdXRzIGZvciBzdGFs ZSBzdGF0ZTxicj4NCmNsZWFudXAuPGJyPg0KLSBJbXBsZW1lbnQgcGVyLXBlZXIgZmxvdyBjb250 cm9sLuKAnTwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIG9y ZGVyIHRvIGFjaGlldmUgdGhlc2UgcHJpbmNpcGxlcyB5b3UgcmVjb21tZW5kIOKAnDxpPkltcGxl bWVudGluZyBjb3VwbGluZyB0aGUgc3RhdGUNCiBvZiBpbmRpdmlkdWFsIExTUHMgd2l0aCB0aGUg c3RhdGUgb2YgdGhlIGNvcnJlc3BvbmRpbmcgUlNWUC1URSBzaWduYWxpbmcgYWRqYWNlbmN5Ljwv aT7igJ0gKGNvcGllZCBmcm9tIHRoZSBkcmFmdCkuIFNpbmNlIGluIHRoZSB0cmFuc3BvcnQgbmV0 d29yayB5b3UgcmVhbGx5IHNob3VsZG7igJl0IGRvIHRoYXQsIEnigJltIGludGVyZXN0ZWQgaG93 IHlvdSBjYW4gZnVsZmlsbCBhYm92ZSBtZW50aW9uZWQgcHJpbmNpcGxlcyB3aXRob3V0IGl0Lg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ VlBCJmx0Oz0mZ3Q7IElmIHRoZSBlbGVtZW50cyBpbiB0aGlzIHRyYW5zcG9ydCBuZXR3b3JrIG9m IHlvdXJzIGFyZSBydW5uaW5nIHN0YW5kYXJkIEdNUExTIENvbnRyb2wtUGxhbmUgKG5vdCBzb21l IEdNUExTIGJhc2VkIHByb3ByaWV0YXJ5IHZlcnNpb24pLCBwbGVhc2UgZWxhYm9yYXRlIHdoeSB5 b3UgY2FuJ3QgY291cGxlIHRoZSBzdGF0ZSBvZiBpbmRpdmlkdWFsIExTUHMNCiB3aXRoIHRoZSBz dGF0ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBSU1ZQLVRFIHNpZ25hbGluZyBhZGphY2VuY3kuIElm IGFuIGltcGxlbWVudGF0aW9uIGNhbiBjbGVhbnVwIHRoZSBMU1Atc3RhdGUgd2hlbiB0aGUgcmVm cmVzaCB0aW1lcyBvdXQsIHRoZW4gaXQgc2hvdWxkIGFsc28gYmUgYWJsZSB0byBjbGVhbnVwIHRo ZSBMU1Atc3RhdGUgd2hlbiB0aGUgaGVsbG8tYWRqYWNlbmN5IGdvZXMgZG93bi4gSSB1bmRlcnN0 YW5kIHRoYXQgdGhlcmUgYXJlDQogcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRpb25zIHRoYXQgZG8g bm90IGNsZWFudXAgdGhlIExTUC1zdGF0ZSB3aGVuIHRoZSByZWZyZXNoIHRpbWVzIG91dCAtLSB0 aG9zZSBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbnMgbWlnaHQgbmVlZCBzb21lIGFkZGl0aW9u YWwgcHJvY2VkdXJlcyAodGhpcyBkcmFmdCB3aWxsIG5vdCBmdXJuaXNoIHRob3NlKS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRvIGdpdmUgYW4gZXhhbXBsZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpQcmluY2lwbGUg Mjog4oCcQ29tcGxldGVseSBlbGltaW5hdGUgdGhlIHJlbGlhbmNlIG9uIHJlZnJlc2ggdGltZW91 dHMgZm9yIHN0YWxlIHN0YXRl4oCdPC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SW4gdGhlIGRyYWZ0IHlvdSBhc3N1bWUgdGhhdCBzdGFsZSBzdGF0ZSB3aWxsIGJl IHJlbW92ZWQgdGhhbmtzIHRvOiBhKSByZWxpYWJsZSBUZWFyL0Vycg0KIG1lc3NhZ2VzIGRlbGl2 ZXJ5IGFuZCBiKSByZW1vdmluZyBvZiBsc3Agc3RhdGUgYWZ0ZXIgYWRqYWNlbmN5IGxvc3MuIFNp bmNlIGIpIGRvZXMgbm90IHdvcmsgaW4gdHJhbnNwb3J0LCBob3cgY2FuIHlvdSBjb3ZlciBzY2Vu YXJpb3MgaW52b2x2aW5nIGEgcmVib290IG9mIGEgUlNWUCBzcGVha2VyIHdoaWxlIHRoZSBzZXJ2 aWNlIGlzIHRvcm4gZG93biBlLmcuIGJ5IFBhdGhUZWFyPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VlBCICZsdDs9Jmd0OyBBZ2FpbiwgcGxlYXNlIGVsYWJvcmF0ZSB3aHkgeW91IGNhbm5vdCByZW1v dmUgTFNQIGFmdGVyIGFkamFjZW5jeSBsb3NzIGlmIHlvdSBhcmUgdXNpbmcgc3RhbmRhcmQgR01Q TFMgUlNWUC1URS4mbmJzcDsNCjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXdlbDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBUZWFzDQogW21haWx0bzo8YSBocmVmPSJtYWlsdG86dGVhcy1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGVhcy1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+VmlzaG51IFBhdmFuIEJlZXJhbTxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgTWFyY2ggMjYsIDIwMTUgMzo1NiBQTTxicj4NCjxiPlRvOjwvYj4gTG9hIEFu ZGVyc3Nvbjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRlYXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj50ZWFzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1RlYXNdIFJTVlAgVEUgU2NhbGFiaWxpdHkgLSBSZWNvbW1lbmRhdGlvbnM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+TG9hLCBIaSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+VGhhbmtzIGZvciBwb2ludGluZyBpdCBvdXQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+WWVzLCBub3QgcmVmZXJlbmNpbmcvbWVudGlvbmluZyBSRkMg NTQzOSB3YXMgYSBtaXN0YWtlIGFuZCB0aGF0IHdvdWxkIGJlIHJlY3RpZmllZCBpbiB0aGUgbmV4 dCB2ZXJzaW9uLiAoQnV0IEkgZGlkIG1lbnRpb24gUkZDNTQzOSBpbiB0aGlzIG1vcm5pbmcncyBw cmVzZW50YXRpb24gOikpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PkJvdGggUkZDMjk2MSBhbmQgUkZDNTQzOSBkbyB0YWxrIGFib3V0IGhhdmluZyBhIGxhcmdlIHJl ZnJlc2ggaW50ZXJ2YWwgYXMgYSBtZWFucyBvZiByZWR1Y2luZyB0aGUgcmF0ZSBvZiBtZXNzYWdl cyB0aGF0IHRoZSBjb250cm9sLXBsYW5lIGhhcyB0byBwcm9jZXNzLCBidXQgYWxzbyB3YXJuIGFi b3V0IHRoZSBsb3NzDQogb2YgZnVuY3Rpb25hbGl0eSBhc3NvY2lhdGVkIHdpdGggZG9pbmcgc28u ICZsdDtkcmFmdC1iZWVyYW0tbXBscy1yc3ZwLXRlLXNjYWxpbmcmZ3Q7IGJyaW5ncyBiYWNrIHRo ZSBub3Rpb24gb2YgcmVmcmVzaCBpbmRlcGVuZGVudCBSU1ZQLCBidXQgYWxzbyBpbmNsdWRlcyBy ZWNvbW1lbmRhdGlvbnMgdGhhdCB3b3VsZCBtYWtlIHN1cmUgdGhhdCB0aGVyZSBpcyBubyBsb3Nz IG9mIGZ1bmN0aW9uYWxpdHkgd2hlbiBhIGxhcmdlIHJlZnJlc2ggaW50ZXJ2YWwgaXMNCiB1c2Vk LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LVBhdmFuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgTWFyIDI2LCAyMDE1IGF0IDM6MzEgUE0s IExvYSBBbmRlcnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2Js YW5rIj5sb2FAcGkubnU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+UGF2YW4sPGJyPg0KPGJyPg0KVGhlIE1QTFMgd2cgZGlkICZxdW90O0FuIEFu YWx5c2lzIG9mIFNjYWxpbmcgSXNzdWVzIGluIE1QTFMtVEUgQ29yZSBOZXR3b3JrcyZxdW90Ozxi cj4NClJGQyA1NDM5LiBUaGlzIFJGQyBpcyBub3QgbWVudGlvbmVkIGluIGRyYWZ0LWJlZXJhbS1t cGxzLXJzdnAtPGJyPg0KdGUtc2NhbGluZy4gVGhlIHRvcGljcyBzZWVtcyBjbG9zZSBlbm91Z2gg dG8gbWFrZSB3b3J0aCBsb29rIGF0IHRoYXQ8YnI+DQpkb2N1bWVudC48YnI+DQo8YnI+DQovTG9h PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gMjAxNS0wMy0yNiAxNDowOSwgVmlzaG51IFBhdmFuIEJl ZXJhbSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVl cmFtLW1wbHMtcnN2cC10ZS1zY2FsaW5nLTAxIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlZXJhbS1tcGxzLXJzdnAtdGUtc2NhbGluZy0wMTwvYT48 YnI+DQo8YnI+DQpGb2xrcywgSGkhPGJyPg0KPGJyPg0KJmx0O2RyYWZ0LWJlZXJhbS1tcGxzLXJz dnAtdGUtc2NhbGluZyZndDsgd2FzIHByZXNlbnRlZCBlYXJsaWVyIHRvZGF5IGluIHRoZTxicj4N ClRFQVMgV0cgc2Vzc2lvbi4gVGhlcmUgd2Fzbid0IHN1ZmZpY2llbnQgdGltZSB0byB0YWtlIGlu IHF1ZXN0aW9ucyBhdDxicj4NCnRoZSBlbmQgb2YgdGhlIHByZXNlbnRhdGlvbiAoYXBvbG9naXpl IGZvciB0aGF0KS4gU28sIEknbSBvcGVuaW5nIHVwPGJyPg0KdGhpcyB0aHJlYWQgdG8gbWFrZSBz dXJlIHRoYXQgYWxsIHRob3NlIHF1ZXN0aW9ucyBnZXQgYW5zd2VyZWQuPGJyPg0KPGJyPg0KQSBm ZXcgcG9pbnRzIHRvIG5vdGU6PGJyPg0KPGJyPg0KMS4gVGhlc2UgcmVjb21tZW5kYXRpb25zIHdl cmUgcHV0IHRvZ2V0aGVyIGZvciBjYXRlcmluZyB0byBjdXJyZW50IE1QTFM8YnI+DQpSU1ZQLVRF IFNjYWxhYmlsaXR5IG5lZWRzLiBCdXQgc2luY2UgbW9zdCBvZiB0aGVtIGhhdmUgZ2VuZXJpYzxi cj4NCmFwcGxpY2FiaWxpdHksIHRoaXMgZHJhZnQgaXMgYmVpbmcgZGlzY3Vzc2VkIGluIFRFQVMu PGJyPg0KPGJyPg0KMi4gVGhlcmUgYXJlIDMgdW5kZXJseWluZyBwcmluY2lwbGVzIGRyaXZpbmcg dGhlc2UgcmVjb21tZW5kYXRpb25zPGJyPg0KLSBDb21wbGV0ZWx5IGVsaW1pbmF0ZSB0aGUgcmVs aWFuY2Ugb24gcmVmcmVzaGVzIGZvciBzdGF0ZSBzeW5jLjxicj4NCi0gQ29tcGxldGVseSBlbGlt aW5hdGUgdGhlIHJlbGlhbmNlIG9uIHJlZnJlc2ggdGltZW91dHMgZm9yIHN0YWxlIHN0YXRlPGJy Pg0KY2xlYW51cC48YnI+DQotIEltcGxlbWVudCBwZXItcGVlciBmbG93IGNvbnRyb2wuPGJyPg0K PGJyPg0KMy4gVGhpcyBpcyBub3QgYSB0aGVvcmV0aWNhbCBleGVyY2lzZS4gV2UgaGF2ZSBhbiBp bXBsZW1lbnRhdGlvbiB0aGF0PGJyPg0KcmVsaWdpb3VzbHkgYWRvcHRzIHRoZXNlIHJlY29tbWVu ZGF0aW9ucyAtLSBhbmQgdGhlIHNhdmluZ3MgaW4gdGVybXMgb2Y8YnI+DQpwcm9jZXNzaW5nIGN5 Y2xlcyBmb3IgdGhlIGNvbnRyb2wtcGxhbmUgKGFzIGEgcmVzdWx0IG9mIHRoZSBzaWduaWZpY2Fu dDxicj4NCnJlZHVjdGlvbiBpbiBJL08gb3ZlcmhlYWQpIGlzIHF1aXRlIHNpZ25pZmljYW50Ljxi cj4NCjxicj4NClBsZWFzZSBkbyBnaXZlIHRoZXNlIHJlY29tbWVuZGF0aW9ucyBzb21lIHNlcmlv dXMgY29uc2lkZXJhdGlvbiBhbmQgbGV0PGJyPg0KdXMga25vdyB5b3VyIHF1ZXN0aW9ucy9jb21t ZW50cy48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCi1QYXZhbjxicj4NCihvbiBiZWhhbGYgb2Yg dGhlIGF1dGhvcnMpPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NClRlYXMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOlRlYXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UZWFzQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVhcyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGVh czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCi0tIDxicj4NCjxicj4NCjxicj4N CkxvYSBBbmRlcnNzb24mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogPGEgaHJlZj0i bWFpbHRvOmxvYUBtYWlsMDEuaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbG9hQG1haWww MS5odWF3ZWkuY29tPC9hPjxicj4NClNlbmlvciBNUExTIEV4cGVydCZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJtYWlsdG86bG9hQHBpLm51IiB0YXJnZXQ9Il9ibGFu ayI+DQpsb2FAcGkubnU8L2E+PGJyPg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkm bmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiA8YSBocmVmPSJ0ZWw6JTJCNDYlMjA3MzklMjA4MSUy MDIxJTIwNjQiIHRhcmdldD0iX2JsYW5rIj4NCiYjNDM7NDYgNzM5IDgxIDIxIDY0PC9hPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_79bd84a38c964717a963da3223359266MUCSEX13Badvaopticalcom_-- From nobody Wed Apr 1 06:50:38 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A821A9117 for ; Wed, 1 Apr 2015 06:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLJ8N1CLNFPr for ; Wed, 1 Apr 2015 06:50:31 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709E81A9115 for ; Wed, 1 Apr 2015 06:50:31 -0700 (PDT) Received: by qcgx3 with SMTP id x3so41231248qcg.3 for ; Wed, 01 Apr 2015 06:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+ak0t1NOK2272jCs0OfnePj6A8dftlwS/XUzaoELVRk=; b=LxArPupp/CYuZLS5Jh7ipXtoFPdGZQFWRkK8w5tJKyBaKw0ndDAUqbzIl3kWb+Z2h+ cgJpa9BevDoZxYaUdDrIkQNth6K7fjMffd8qlIldNEeCYUJd82Qz6onr5S8+tnDEht9K 292j7IdHLTmfUCEryFjUY4TrzUXoEN3Ge5O8J2eln/oFGB78c+zonzvI6D/MXakPlm7X a7ZYL0HGqUtmSzFt2J0aD4wW3mvzHtc6+K+71UOEkoZoOdYUa/OyDr9J9Ado2zrhkT1k anl1RzNItUb9ucs48adaMl9/VH0YHqqpvDP9xmgUnBYpuK65LBW654mxu+LmvxpWIws/ ePrA== MIME-Version: 1.0 X-Received: by 10.140.192.15 with SMTP id n15mr56287813qha.28.1427896230763; Wed, 01 Apr 2015 06:50:30 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Wed, 1 Apr 2015 06:50:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Apr 2015 09:50:30 -0400 Message-ID: From: Vishnu Pavan Beeram To: "Andrew G. Malis" Content-Type: multipart/alternative; boundary=001a1141816e9c61de0512a9ff05 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 13:50:36 -0000 --001a1141816e9c61de0512a9ff05 Content-Type: text/plain; charset=UTF-8 Andy, No, We are not bringing back the RFC3209 vs RFC3212 debate :) Regards, -Pavan On Wed, Apr 1, 2015 at 7:58 AM, Andrew G. Malis wrote: > Pavan, > > Thanks for the recommendations. They could certainly be addressed by > bringing back RFC 3212 (but note today's date, I deliberately waited six > days to send this email :-). > > Cheers, > Andy > > > On Thu, Mar 26, 2015 at 3:09 PM, Vishnu Pavan Beeram < > vishnupavan@gmail.com> wrote: > >> https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01 >> >> Folks, Hi! >> >> was presented earlier today in the >> TEAS WG session. There wasn't sufficient time to take in questions at the >> end of the presentation (apologize for that). So, I'm opening up this >> thread to make sure that all those questions get answered. >> >> A few points to note: >> >> 1. These recommendations were put together for catering to current MPLS >> RSVP-TE Scalability needs. But since most of them have generic >> applicability, this draft is being discussed in TEAS. >> >> 2. There are 3 underlying principles driving these recommendations >> - Completely eliminate the reliance on refreshes for state sync. >> - Completely eliminate the reliance on refresh timeouts for stale state >> cleanup. >> - Implement per-peer flow control. >> >> 3. This is not a theoretical exercise. We have an implementation that >> religiously adopts these recommendations -- and the savings in terms of >> processing cycles for the control-plane (as a result of the significant >> reduction in I/O overhead) is quite significant. >> >> Please do give these recommendations some serious consideration and let >> us know your questions/comments. >> >> Regards, >> -Pavan >> (on behalf of the authors) >> >> >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> >> > --001a1141816e9c61de0512a9ff05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andy,

No, We are not bringing = back the RFC3209 vs RFC3212 debate :)

Regards,
-Pavan=

On Wed,= Apr 1, 2015 at 7:58 AM, Andrew G. Malis <agmalis@gmail.com>= wrote:
Pavan,

<= /div>
Thanks for the recommendations. They could certainly be addressed= by bringing back RFC 3212 (but note today's date, I deliberately waite= d six days to send this email :-).

Cheers,
Andy


On Thu, Mar 26, 2015 at 3:09 PM, Vi= shnu Pavan Beeram <vishnupavan@gmail.com> wrote:
<draft-beeram= -mpls-rsvp-te-scaling> was presented earlier today in the TEAS WG sessio= n. There wasn't sufficient time to take in questions at the end of the = presentation (apologize for that). So, I'm opening up this thread to ma= ke sure that all those questions get answered.

A few poin= ts to note:

1. These recommendations were put together fo= r catering to current MPLS RSVP-TE Scalability needs. But since most of the= m have generic applicability, this draft is being discussed in TEAS.
2. There are 3 underlying principles driving these recommendati= ons
- Completely eliminate the reliance on refreshes for sta= te sync.
- Completely eliminate the reliance on refresh timeo= uts for stale state cleanup.
- Implement per-peer flow contro= l.

3. This is not a theoretical exercise. We have an impl= ementation that religiously adopts these recommendations -- and the savings= in terms of processing cycles for the control-plane (as a result of the si= gnificant reduction in I/O overhead) is quite significant.

Please do give these recommendations some serious consideration and let u= s know your questions/comments.

Regards,
-P= avan
(on behalf of the authors)




__________________________________________= _____
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas



--001a1141816e9c61de0512a9ff05-- From nobody Wed Apr 1 06:58:55 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14951A9133 for ; Wed, 1 Apr 2015 06:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuaEeeY2BzYn for ; Wed, 1 Apr 2015 06:58:50 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6806C1A9134 for ; Wed, 1 Apr 2015 06:58:49 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 0E896F2BED491; Wed, 1 Apr 2015 13:58:44 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t31Dwilm019752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 15:58:44 +0200 Received: from [149.204.107.61] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Apr 2015 15:58:44 +0200 Message-ID: <551BF98E.9050102@alcatel-lucent.com> Date: Wed, 1 Apr 2015 15:58:38 +0200 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: =?UTF-8?B?UGF3ZcWCIEJyem96b3dza2k=?= , Vishnu Pavan Beeram References: <55145EA1.3010905@pi.nu> <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> In-Reply-To: <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.41] Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 13:58:53 -0000 Hi all,

two comments regarding the usage of RSVP in GMPLS enabled transport networks:
  1. In my view, RSVP requires LSP state cleanup in case of RSVP refresh timeouts (soft state protocol) - you may, however, suspend
    the refresh mechanism in case your signalling communication is broken while your data plane is working properly.

  2. RSVP-TE scalability may not be an issue in GMPLS enabled transport networks due to the fact that we have a limited number of
    LSPs per link (corresponding to the number of circuits per link)

Thanks,
Dieter

On 01.04.2015 14:48, Paweł Brzozowski wrote:

Pavan,

 

you wrote:

 

“VPB<=> If the elements in this transport network of yours are running standard GMPLS Control-Plane (not some GMPLS based proprietary version), please elaborate why you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. If an implementation can cleanup the LSP-state when the refresh times out, then it should also be able to cleanup the LSP-state when the hello-adjacency goes down. I understand that there are proprietary implementations that do not cleanup the LSP-state when the refresh times out -- those proprietary implementations might need some additional procedures (this draft will not furnish those).”

I guess this is where our disconnect comes from. You certainly know RFCs better than me. I assumed that IETF recommendation for GMPLS running in transport networks would be NOT to cleanup lsp state when refreshes time out. Is it not the case?

 

Thanks,

Pawel

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Wednesday, April 01, 2015 12:13 AM
To: Paweł Brzozowski
Cc: teas@ietf.org
Subject: Re: [Teas] RSVP TE Scalability - Recommendations

 

Pawel, Hi!

Thanks for the response. Please see inline.

Regards,

-Pavan

 

On Tue, Mar 31, 2015 at 5:30 PM, Paweł Brzozowski <PBrzozowski@advaoptical.com> wrote:

Pavan,

 

I think this is great work and applies well to the packet networks. Imho the draft should be augmented to reflect to what is the degree of applicability to transport networks.

 

VPB <=> As mentioned earlier, the recommendations in the draft were put together to cater to MPLS RSVP-TE LSPs. The authors didn't consider the applicability of these recommendations to non-psc GMPLS LSPs at all in the initial revision -- we simply didn't care :). But since it was pointed out to us that most of these recommendations have generic applicability, I agree that it would be useful to clarify the degree of applicability to such networks in the next revision of the draft. At a high-level, everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert for Paths) and Section 2.6 (there are different ways of checking data-plane readiness for non psc LSPs) should have generic applicability.

 

You said:

 

“There are 3 underlying principles driving these recommendations:

- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.”

 

In order to achieve these principles you recommend “Implementing coupling the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency.” (copied from the draft). Since in the transport network you really shouldn’t do that, I’m interested how you can fulfill above mentioned principles without it.

 

VPB<=> If the elements in this transport network of yours are running standard GMPLS Control-Plane (not some GMPLS based proprietary version), please elaborate why you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. If an implementation can cleanup the LSP-state when the refresh times out, then it should also be able to cleanup the LSP-state when the hello-adjacency goes down. I understand that there are proprietary implementations that do not cleanup the LSP-state when the refresh times out -- those proprietary implementations might need some additional procedures (this draft will not furnish those).

To give an example:


Principle 2: “Completely eliminate the reliance on refresh timeouts for stale state”

 

In the draft you assume that stale state will be removed thanks to: a) reliable Tear/Err messages delivery and b) removing of lsp state after adjacency loss. Since b) does not work in transport, how can you cover scenarios involving a reboot of a RSVP speaker while the service is torn down e.g. by PathTear?

 

 

VPB <=> Again, please elaborate why you cannot remove LSP after adjacency loss if you are using standard GMPLS RSVP-TE. 
 

Thanks,

Pawel

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, March 26, 2015 3:56 PM
To: Loa Andersson
Cc: teas@ietf.org
Subject: Re: [Teas] RSVP TE Scalability - Recommendations

 

Loa, Hi!

Thanks for pointing it out.

Yes, not referencing/mentioning RFC 5439 was a mistake and that would be rectified in the next version. (But I did mention RFC5439 in this morning's presentation :)).

Both RFC2961 and RFC5439 do talk about having a large refresh interval as a means of reducing the rate of messages that the control-plane has to process, but also warn about the loss of functionality associated with doing so. <draft-beeram-mpls-rsvp-te-scaling> brings back the notion of refresh independent RSVP, but also includes recommendations that would make sure that there is no loss of functionality when a large refresh interval is used.

Regards,

-Pavan

 

 

On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson <loa@pi.nu> wrote:

Pavan,

The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks"
RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp-
te-scaling. The topics seems close enough to make worth look at that
document.

/Loa





On 2015-03-26 14:09, Vishnu Pavan Beeram wrote:

https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01

Folks, Hi!

<draft-beeram-mpls-rsvp-te-scaling> was presented earlier today in the
TEAS WG session. There wasn't sufficient time to take in questions at
the end of the presentation (apologize for that). So, I'm opening up
this thread to make sure that all those questions get answered.

A few points to note:

1. These recommendations were put together for catering to current MPLS
RSVP-TE Scalability needs. But since most of them have generic
applicability, this draft is being discussed in TEAS.

2. There are 3 underlying principles driving these recommendations
- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.

3. This is not a theoretical exercise. We have an implementation that
religiously adopts these recommendations -- and the savings in terms of
processing cycles for the control-plane (as a result of the significant
reduction in I/O overhead) is quite significant.

Please do give these recommendations some serious consideration and let
us know your questions/comments.

Regards,
-Pavan
(on behalf of the authors)



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

 

 



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
From nobody Wed Apr 1 07:10:14 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E91A1A9232 for ; Wed, 1 Apr 2015 07:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1K0elGh0yHt for ; Wed, 1 Apr 2015 07:10:09 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF651A916D for ; Wed, 1 Apr 2015 07:10:08 -0700 (PDT) Received: by qgep97 with SMTP id p97so43218585qge.1 for ; Wed, 01 Apr 2015 07:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WLPt1baPZhz5ABmH9i1+cqH8tQQ9kVjX+TxXpfV5YDs=; b=jZtOpGV+SHhJ8ET2FyS4CXRPqKrlskt1lCxlebhKv4GYmIJUc/VVqTJPNfZD4WJtMB mKKOyoiYerG0YUJhgkI88oYOU6Svdpg0QBRMnYs+v8BvKYucm3JKLl+ytzWL4nR9lGge UApTBR63T+slZOuGyyNIrmhkvT4F99v0tytbjLfDyRKaEMRMHzDbSRA0fEjQfb6zxAr/ 7ev8qSAhj9wQqZklgyGaXTM2UF7ELiYBX+cDXt4L6DT6BMtvE9BBIgxdnnjoDXD5bU2A q4rkhbMvAzK7f7mItv7dcc/J6aDsdBwgwVinamwOfPlz/NHF+hU2iEimC/05k8w4zUZG 8QpA== MIME-Version: 1.0 X-Received: by 10.140.233.71 with SMTP id e68mr57579252qhc.56.1427897408012; Wed, 01 Apr 2015 07:10:08 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Wed, 1 Apr 2015 07:10:07 -0700 (PDT) In-Reply-To: <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> References: <55145EA1.3010905@pi.nu> <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> Date: Wed, 1 Apr 2015 10:10:07 -0400 Message-ID: From: Vishnu Pavan Beeram To: =?UTF-8?Q?Pawe=C5=82_Brzozowski?= Content-Type: multipart/alternative; boundary=001a113551aac7c5460512aa45a9 Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:10:12 -0000 --001a113551aac7c5460512aa45a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pawel, Hi! There is no (AFAIK) GMPLS document that recommends NOT cleaning up LSP state when refresh times out. So, the point that you are making about these recommendations not being applicable for GMPLS LSPs isn't quite true. I do understand that there are proprietary implementations out there that use some additional procedures (after the refresh times out) to make sure that it is absolutely safe to cleanup the data-plane before cleaning up the corresponding LSP state. With the new recommendations proposed in , these implementations should still be able to run similar procedures after the node-hello times out and then cleanup the state. But since these are all proprietary mechanisms, this draft will not spell all this out for you. Regards, -Pavan On Wed, Apr 1, 2015 at 8:48 AM, Pawe=C5=82 Brzozowski < PBrzozowski@advaoptical.com> wrote: > Pavan, > > > > you wrote: > > > > *=E2=80=9CVPB<=3D> If the elements in this transport network of yours are= running > standard GMPLS Control-Plane (not some GMPLS based proprietary version), > please elaborate why you can't couple the state of individual LSPs with t= he > state of the corresponding RSVP-TE signaling adjacency. If an > implementation can cleanup the LSP-state when the refresh times out, then > it should also be able to cleanup the LSP-state when the hello-adjacency > goes down. I understand that there are proprietary implementations that d= o > not cleanup the LSP-state when the refresh times out -- those proprietary > implementations might need some additional procedures (this draft will no= t > furnish those).=E2=80=9D* > > I guess this is where our disconnect comes from. You certainly know RFCs > better than me. I assumed that IETF recommendation for GMPLS running in > transport networks would be NOT to cleanup lsp state when refreshes time > out. Is it not the case? > > > > Thanks, > > Pawel > > > > *From:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] > *Sent:* Wednesday, April 01, 2015 12:13 AM > *To:* Pawe=C5=82 Brzozowski > > *Cc:* teas@ietf.org > *Subject:* Re: [Teas] RSVP TE Scalability - Recommendations > > > > Pawel, Hi! > > Thanks for the response. Please see inline. > > Regards, > > -Pavan > > > > On Tue, Mar 31, 2015 at 5:30 PM, Pawe=C5=82 Brzozowski < > PBrzozowski@advaoptical.com> wrote: > > Pavan, > > > > I think this is great work and applies well to the packet networks. Imho > the draft should be augmented to reflect to what is the degree of > applicability to transport networks. > > > > VPB <=3D> As mentioned earlier, the recommendations in the draft were put > together to cater to MPLS RSVP-TE LSPs. The authors didn't consider the > applicability of these recommendations to non-psc GMPLS LSPs at all in th= e > initial revision -- we simply didn't care :). But since it was pointed ou= t > to us that most of these recommendations have generic applicability, I > agree that it would be useful to clarify the degree of applicability to > such networks in the next revision of the draft. At a high-level, > everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert > for Paths) and Section 2.6 (there are different ways of checking data-pla= ne > readiness for non psc LSPs) should have generic applicability. > > > > You said: > > > > *=E2=80=9CThere are 3 underlying principles driving these recommendations= :* > > > > > *- Completely eliminate the reliance on refreshes for state sync. - > Completely eliminate the reliance on refresh timeouts for stale state > cleanup. - Implement per-peer flow control.=E2=80=9D* > > > > In order to achieve these principles you recommend =E2=80=9C*Implementing > coupling the state of individual LSPs with the state of the corresponding > RSVP-TE signaling adjacency.*=E2=80=9D (copied from the draft). Since in = the > transport network you really shouldn=E2=80=99t do that, I=E2=80=99m inter= ested how you can > fulfill above mentioned principles without it. > > > > VPB<=3D> If the elements in this transport network of yours are running > standard GMPLS Control-Plane (not some GMPLS based proprietary version), > please elaborate why you can't couple the state of individual LSPs with t= he > state of the corresponding RSVP-TE signaling adjacency. If an > implementation can cleanup the LSP-state when the refresh times out, then > it should also be able to cleanup the LSP-state when the hello-adjacency > goes down. I understand that there are proprietary implementations that d= o > not cleanup the LSP-state when the refresh times out -- those proprietary > implementations might need some additional procedures (this draft will no= t > furnish those). > > To give an example: > > > * Principle 2: =E2=80=9CCompletely eliminate the reliance on refresh time= outs for > stale state=E2=80=9D* > > > > In the draft you assume that stale state will be removed thanks to: a) > reliable Tear/Err messages delivery and b) removing of lsp state after > adjacency loss. Since b) does not work in transport, how can you cover > scenarios involving a reboot of a RSVP speaker while the service is torn > down e.g. by PathTear? > > > > > > VPB <=3D> Again, please elaborate why you cannot remove LSP after adjacen= cy > loss if you are using standard GMPLS RSVP-TE. > > > Thanks, > > Pawel > > > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Vishnu Pavan > Beeram > *Sent:* Thursday, March 26, 2015 3:56 PM > *To:* Loa Andersson > *Cc:* teas@ietf.org > *Subject:* Re: [Teas] RSVP TE Scalability - Recommendations > > > > Loa, Hi! > > Thanks for pointing it out. > > Yes, not referencing/mentioning RFC 5439 was a mistake and that would be > rectified in the next version. (But I did mention RFC5439 in this morning= 's > presentation :)). > > Both RFC2961 and RFC5439 do talk about having a large refresh interval as > a means of reducing the rate of messages that the control-plane has to > process, but also warn about the loss of functionality associated with > doing so. brings back the notion of > refresh independent RSVP, but also includes recommendations that would ma= ke > sure that there is no loss of functionality when a large refresh interval > is used. > > Regards, > > -Pavan > > > > > > On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson wrote: > > Pavan, > > The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks" > RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp- > te-scaling. The topics seems close enough to make worth look at that > document. > > /Loa > > > > > > On 2015-03-26 14:09, Vishnu Pavan Beeram wrote: > > https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01 > > Folks, Hi! > > was presented earlier today in the > TEAS WG session. There wasn't sufficient time to take in questions at > the end of the presentation (apologize for that). So, I'm opening up > this thread to make sure that all those questions get answered. > > A few points to note: > > 1. These recommendations were put together for catering to current MPLS > RSVP-TE Scalability needs. But since most of them have generic > applicability, this draft is being discussed in TEAS. > > 2. There are 3 underlying principles driving these recommendations > - Completely eliminate the reliance on refreshes for state sync. > - Completely eliminate the reliance on refresh timeouts for stale state > cleanup. > - Implement per-peer flow control. > > 3. This is not a theoretical exercise. We have an implementation that > religiously adopts these recommendations -- and the savings in terms of > processing cycles for the control-plane (as a result of the significant > reduction in I/O overhead) is quite significant. > > Please do give these recommendations some serious consideration and let > us know your questions/comments. > > Regards, > -Pavan > (on behalf of the authors) > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > --001a113551aac7c5460512aa45a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pawel, Hi!

There is no (AFAIK)= GMPLS document that recommends NOT cleaning up LSP state when refresh time= s out. So, the point that you are making about these recommendations not be= ing applicable for GMPLS LSPs isn't quite true.

I do understand = that there are proprietary implementations out there that use some addition= al procedures (after the refresh times out) to make sure that it is absolut= ely safe to cleanup the data-plane before cleaning up the corresponding LSP= state. With the new recommendations proposed in <draft-beeram..>, th= ese implementations should still be able to run similar procedures after th= e node-hello times out and then cleanup the state. But since these are all = proprietary mechanisms, this draft will not spell all this out for you.
=
Regards,
-Pavan

On Wed, Apr 1, 2015 at 8:48 AM, Pawe=C5= =82 Brzozowski <PBrzozowski@advaoptical.com> wrote= :

Pavan,

=C2=A0

you wrote:=

=C2= =A0

=E2=80=9CVPB<=3D> If the elements in this transport network of you= rs are running standard GMPLS Control-Plane (not some GMPLS based proprieta= ry version), please elaborate why you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signa= ling adjacency. If an implementation can cleanup the LSP-state when the ref= resh times out, then it should also be able to cleanup the LSP-state when t= he hello-adjacency goes down. I understand that there are proprietary implementations that do not cleanup = the LSP-state when the refresh times out -- those proprietary implementatio= ns might need some additional procedures (this draft will not furnish those= ).=E2=80=9D

I guess th= is is where our disconnect comes from. You certainly know RFCs better than = me. I assumed that IETF recommendation for GMPLS running in transport networks would be NOT to cleanup lsp state when refreshes time o= ut. Is it not the case?

=C2= =A0

Thanks,=

Pawel

=C2= =A0

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Wednesday, April 01, 2015 12:13 AM
To: Pawe=C5=82 Brzozowski


Cc: teas@ietf.org=
Subject: Re: [Teas] RSVP TE Scalability - Recommendations<= /u>

=C2=A0

Pawel, Hi!<= /u>

Thanks for the respon= se. Please see inline.

Regards,

-Pavan

=C2=A0

On Tue, Mar 31, 2015 at 5:30 PM, Pawe=C5=82 Brzozows= ki <PBr= zozowski@advaoptical.com> wrote:

Pavan,

=C2=A0

I think th= is is great work and applies well to the packet networks. Imho the draft sh= ould be augmented to reflect to what is the degree of applicability to transpor= t networks.

=C2=A0

VPB <=3D> As me= ntioned earlier, the recommendations in the draft were put together to cate= r to MPLS RSVP-TE LSPs. The authors didn't consider the applicability o= f these recommendations to non-psc GMPLS LSPs at all in the initial revision -- we simply didn't care :). But since it = was pointed out to us that most of these recommendations have generic appli= cability, I agree that it would be useful to clarify the degree of applicab= ility to such networks in the next revision of the draft. At a high-level, everything except Section 2.5 (GMPLS RSVP-T= E LSPs do not use Router-Alert for Paths) and Section 2.6 (there are differ= ent ways of checking data-plane readiness for non psc LSPs) should have gen= eric applicability.

=C2=A0

You said:<= /span>

=C2=A0

=E2=80=9CThere are 3 underly= ing principles driving these recommendations:

- Completely eliminate the r= eliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.=E2=80=9D

=C2=A0

In order t= o achieve these principles you recommend =E2=80=9CImplementing coupling = the state of individual LSPs with the state of the corresponding RSVP-TE signaling a= djacency.=E2=80=9D (copied from the draft). Since in the transport netw= ork you really shouldn=E2=80=99t do that, I=E2=80=99m interested how you ca= n fulfill above mentioned principles without it.

=C2=A0

VPB<=3D> If the= elements in this transport network of yours are running standard GMPLS Con= trol-Plane (not some GMPLS based proprietary version), please elaborate why= you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. If an imp= lementation can cleanup the LSP-state when the refresh times out, then it s= hould also be able to cleanup the LSP-state when the hello-adjacency goes d= own. I understand that there are proprietary implementations that do not cleanup the LSP-state when the ref= resh times out -- those proprietary implementations might need some additio= nal procedures (this draft will not furnish those).

To give an= example:


Principle 2: =E2=80=9CCompletely eliminate the reliance on refresh timeouts= for stale state=E2=80=9D

=C2=A0

In the dra= ft you assume that stale state will be removed thanks to: a) reliable Tear/= Err messages delivery and b) removing of lsp state after adjacency loss. Since= b) does not work in transport, how can you cover scenarios involving a reb= oot of a RSVP speaker while the service is torn down e.g. by PathTear?

=C2=A0

=C2=A0

VPB <=3D> Again, please elaborate why you cann= ot remove LSP after adjacency loss if you are using standard GMPLS RSVP-TE.= =C2=A0
=C2=A0

Thanks,

Pawel

=C2=A0

=C2=A0

From: Teas [mailto:teas-bo= unces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, March 26, 2015 3:56 PM
To: Loa Andersson
Cc: teas@ietf.org=
Subject: Re: [Teas] RSVP TE Scalability - Recommendations<= /u>

=C2=A0

Loa, Hi!

Thanks for pointing i= t out.

Yes, not referencing/= mentioning RFC 5439 was a mistake and that would be rectified in the next v= ersion. (But I did mention RFC5439 in this morning's presentation :)).<= u>

Both RFC2961 and RFC5= 439 do talk about having a large refresh interval as a means of reducing th= e rate of messages that the control-plane has to process, but also warn abo= ut the loss of functionality associated with doing so. <draft-beeram-mpls-rsvp-te-s= caling> brings back the notion of refresh independent RSVP, but also inc= ludes recommendations that would make sure that there is no loss of functio= nality when a large refresh interval is used.

Regards,

-Pavan

=C2=A0

=C2=A0

On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson <<= a href=3D"mailto:loa@pi.nu" target=3D"_blank">loa@pi.nu> wrote:

Pavan,

The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Network= s"
RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp-
te-scaling. The topics seems close enough to make worth look at that
document.

/Loa





On 2015-03-26 14:09, Vishnu Pavan Beeram wrote:

h= ttps://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01

Folks, Hi!

<draft-beeram-mpls-rsvp-te-scaling> was presented earlier today in th= e
TEAS WG session. There wasn't sufficient time to take in questions at the end of the presentation (apologize for that). So, I'm opening up this thread to make sure that all those questions get answered.

A few points to note:

1. These recommendations were put together for catering to current MPLS
RSVP-TE Scalability needs. But since most of them have generic
applicability, this draft is being discussed in TEAS.

2. There are 3 underlying principles driving these recommendations
- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.

3. This is not a theoretical exercise. We have an implementation that
religiously adopts these recommendations -- and the savings in terms of
processing cycles for the control-plane (as a result of the significant
reduction in I/O overhead) is quite significant.

Please do give these recommendations some serious consideration and let
us know your questions/comments.

Regards,
-Pavan
(on behalf of the authors)



_____________________= __________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64

=C2=A0

=C2=A0


--001a113551aac7c5460512aa45a9-- From nobody Wed Apr 1 07:31:05 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE3A1AC3D4 for ; Wed, 1 Apr 2015 07:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIby-vPyp3v2 for ; Wed, 1 Apr 2015 07:31:01 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21151AC3D2 for ; Wed, 1 Apr 2015 07:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43706; q=dns/txt; s=iport; t=1427898661; x=1429108261; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=p8fvZtsT2rBbWNrMRaBSlWz/Vf1wLeZ0OAvYfGnBP4M=; b=BGk0relHWy6QaJ5sybPo3SQ8SiyqGMAhODxUAgK7ynjONtiWWBVXbh5L EOXSAsRetqZzXbZs2THhIAcoY2ZRaxbPpzzXV6NGwCzMndpJszkEVz78J Rm7amOfeEXXrBGk5Onoug4UXU45pLw7z4HGhrim9zgpDxmDLP/nn3lIne E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ATBQBnABxV/4MNJK1cgkNDUlwFgxDCOwEJhXMCHIEjTAEBAQEBAX2EFAEBAQQBAQEgCj4DCw4CAgEIEQQBAQsWAQYDAgICGQYGCxQJCAIEAQ0FCIgTAxENtSaTUQ2FUAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBIomf4JHgU8KBwEfBQgJFwQGAYJoL4EWBY5Ugg+DcoImgV4zgmoRgyGJQ4Jkg0giggIcgVBvgQIJFwMffwEBAQ X-IronPort-AV: E=Sophos;i="5.11,504,1422921600"; d="scan'208,217";a="137346712" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 01 Apr 2015 14:31:00 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t31EUxOM024905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 14:30:59 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.184]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 1 Apr 2015 09:30:59 -0500 From: "Matt Hartley (mhartley)" To: Dieter Beller , =?utf-8?B?UGF3ZcWCIEJyem96b3dza2k=?= , "Vishnu Pavan Beeram" Thread-Topic: [Teas] RSVP TE Scalability - Recommendations Thread-Index: AQHQZ/hymseFyKa2RUWbwO6Imiz9GZ0vFkiAgAAGq4CACAG94IAAyY+AgACP64CAABOeAP//sslw Date: Wed, 1 Apr 2015 14:30:58 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29BFB999@xmb-rcd-x03.cisco.com> References: <55145EA1.3010905@pi.nu> <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> <551BF98E.9050102@alcatel-lucent.com> In-Reply-To: <551BF98E.9050102@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.213.46] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC29BFB999xmbrcdx03ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" , "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:31:04 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC29BFB999xmbrcdx03ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGlldGVyLA0KDQpIaSBhbGwsDQoNCnR3byBjb21tZW50cyByZWdhcmRpbmcgdGhlIHVzYWdlIG9m IFJTVlAgaW4gR01QTFMgZW5hYmxlZCB0cmFuc3BvcnQgbmV0d29ya3M6DQoNCiAgMS4gIEluIG15 IHZpZXcsIFJTVlAgcmVxdWlyZXMgTFNQIHN0YXRlIGNsZWFudXAgaW4gY2FzZSBvZiBSU1ZQIHJl ZnJlc2ggdGltZW91dHMgKHNvZnQgc3RhdGUgcHJvdG9jb2wpIC0geW91IG1heSwgaG93ZXZlciwg c3VzcGVuZA0KdGhlIHJlZnJlc2ggbWVjaGFuaXNtIGluIGNhc2UgeW91ciBzaWduYWxsaW5nIGNv bW11bmljYXRpb24gaXMgYnJva2VuIHdoaWxlIHlvdXIgZGF0YSBwbGFuZSBpcyB3b3JraW5nIHBy b3Blcmx5Lg0KWW91IGNhbiBhbHNvIGp1c3QgcHVzaCB0aGUgcmVmcmVzaC1pbnRlcnZhbCBhbmQg bWlzcy1jb3VudCBoaWdoIGVub3VnaCB0aGF0IHlvdXIgdGltZW91dCBpcyBzdWZmaWNpZW50IGZv ciBuZXR3b3JrIG9wZXJhdG9ycyB0byBub3RpY2UgYW5kIGZpeCB0aGUgcHJvYmxlbS4gU28geW91 ciBzb2Z0LXN0YXRlIHByb3RvY29sIGJlY29tZXPigKYgc29mdCwgbGlrZSByb2NrcyBhcmUgc29m dCA6KQ0KDQogIDEuICBSU1ZQLVRFIHNjYWxhYmlsaXR5IG1heSBub3QgYmUgYW4gaXNzdWUgaW4g R01QTFMgZW5hYmxlZCB0cmFuc3BvcnQgbmV0d29ya3MgZHVlIHRvIHRoZSBmYWN0IHRoYXQgd2Ug aGF2ZSBhIGxpbWl0ZWQgbnVtYmVyIG9mDQpMU1BzIHBlciBsaW5rIChjb3JyZXNwb25kaW5nIHRv IHRoZSBudW1iZXIgb2YgY2lyY3VpdHMgcGVyIGxpbmspDQpUcnVlLiBQYXZhbuKAmXMgZHJhZnQg c2VlbXMgdG8gYmUgYWltZWQgbW9yZSBhdCB0aGUgcGFja2V0IHdvcmxkIHdoZXJlIHN1cHBvcnRp bmcgaHVuZHJlZHMgb2YgdGhvdXNhbmRzIG9mIExTUHMgaXMgYmVjb21pbmcgYSByZXF1aXJlbWVu dCwgYW5kIHdl4oCZbGwgZG91YnRsZXNzIGJlIGdldHRpbmcgaW50byB0aGUgbWlsbGlvbnMgYmVm b3JlIHdlIGtub3cgaXQuIEnigJltIG5vdCBhd2FyZSBvZiB0aGlzIGJlaW5nIGFuIGlzc3VlIGZv ciBHTVBMUy4NCkNoZWVycw0KTWF0dA0KDQpUaGFua3MsDQpEaWV0ZXINCk9uIDAxLjA0LjIwMTUg MTQ6NDgsIFBhd2XFgiBCcnpvem93c2tpIHdyb3RlOg0KUGF2YW4sDQoNCnlvdSB3cm90ZToNCg0K 4oCcVlBCPD0+IElmIHRoZSBlbGVtZW50cyBpbiB0aGlzIHRyYW5zcG9ydCBuZXR3b3JrIG9mIHlv dXJzIGFyZSBydW5uaW5nIHN0YW5kYXJkIEdNUExTIENvbnRyb2wtUGxhbmUgKG5vdCBzb21lIEdN UExTIGJhc2VkIHByb3ByaWV0YXJ5IHZlcnNpb24pLCBwbGVhc2UgZWxhYm9yYXRlIHdoeSB5b3Ug Y2FuJ3QgY291cGxlIHRoZSBzdGF0ZSBvZiBpbmRpdmlkdWFsIExTUHMgd2l0aCB0aGUgc3RhdGUg b2YgdGhlIGNvcnJlc3BvbmRpbmcgUlNWUC1URSBzaWduYWxpbmcgYWRqYWNlbmN5LiBJZiBhbiBp bXBsZW1lbnRhdGlvbiBjYW4gY2xlYW51cCB0aGUgTFNQLXN0YXRlIHdoZW4gdGhlIHJlZnJlc2gg dGltZXMgb3V0LCB0aGVuIGl0IHNob3VsZCBhbHNvIGJlIGFibGUgdG8gY2xlYW51cCB0aGUgTFNQ LXN0YXRlIHdoZW4gdGhlIGhlbGxvLWFkamFjZW5jeSBnb2VzIGRvd24uIEkgdW5kZXJzdGFuZCB0 aGF0IHRoZXJlIGFyZSBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3QgY2xl YW51cCB0aGUgTFNQLXN0YXRlIHdoZW4gdGhlIHJlZnJlc2ggdGltZXMgb3V0IC0tIHRob3NlIHBy b3ByaWV0YXJ5IGltcGxlbWVudGF0aW9ucyBtaWdodCBuZWVkIHNvbWUgYWRkaXRpb25hbCBwcm9j ZWR1cmVzICh0aGlzIGRyYWZ0IHdpbGwgbm90IGZ1cm5pc2ggdGhvc2UpLuKAnQ0KSSBndWVzcyB0 aGlzIGlzIHdoZXJlIG91ciBkaXNjb25uZWN0IGNvbWVzIGZyb20uIFlvdSBjZXJ0YWlubHkga25v dyBSRkNzIGJldHRlciB0aGFuIG1lLiBJIGFzc3VtZWQgdGhhdCBJRVRGIHJlY29tbWVuZGF0aW9u IGZvciBHTVBMUyBydW5uaW5nIGluIHRyYW5zcG9ydCBuZXR3b3JrcyB3b3VsZCBiZSBOT1QgdG8g Y2xlYW51cCBsc3Agc3RhdGUgd2hlbiByZWZyZXNoZXMgdGltZSBvdXQuIElzIGl0IG5vdCB0aGUg Y2FzZT8NCg0KVGhhbmtzLA0KUGF3ZWwNCg0KRnJvbTogVmlzaG51IFBhdmFuIEJlZXJhbSBbbWFp bHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDEsIDIw MTUgMTI6MTMgQU0NClRvOiBQYXdlxYIgQnJ6b3pvd3NraQ0KQ2M6IHRlYXNAaWV0Zi5vcmc8bWFp bHRvOnRlYXNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RlYXNdIFJTVlAgVEUgU2NhbGFiaWxp dHkgLSBSZWNvbW1lbmRhdGlvbnMNCg0KUGF3ZWwsIEhpIQ0KVGhhbmtzIGZvciB0aGUgcmVzcG9u c2UuIFBsZWFzZSBzZWUgaW5saW5lLg0KUmVnYXJkcywNCi1QYXZhbg0KDQpPbiBUdWUsIE1hciAz MSwgMjAxNSBhdCA1OjMwIFBNLCBQYXdlxYIgQnJ6b3pvd3NraSA8UEJyem96b3dza2lAYWR2YW9w dGljYWwuY29tPG1haWx0bzpQQnJ6b3pvd3NraUBhZHZhb3B0aWNhbC5jb20+PiB3cm90ZToNClBh dmFuLA0KDQpJIHRoaW5rIHRoaXMgaXMgZ3JlYXQgd29yayBhbmQgYXBwbGllcyB3ZWxsIHRvIHRo ZSBwYWNrZXQgbmV0d29ya3MuIEltaG8gdGhlIGRyYWZ0IHNob3VsZCBiZSBhdWdtZW50ZWQgdG8g cmVmbGVjdCB0byB3aGF0IGlzIHRoZSBkZWdyZWUgb2YgYXBwbGljYWJpbGl0eSB0byB0cmFuc3Bv cnQgbmV0d29ya3MuDQoNClZQQiA8PT4gQXMgbWVudGlvbmVkIGVhcmxpZXIsIHRoZSByZWNvbW1l bmRhdGlvbnMgaW4gdGhlIGRyYWZ0IHdlcmUgcHV0IHRvZ2V0aGVyIHRvIGNhdGVyIHRvIE1QTFMg UlNWUC1URSBMU1BzLiBUaGUgYXV0aG9ycyBkaWRuJ3QgY29uc2lkZXIgdGhlIGFwcGxpY2FiaWxp dHkgb2YgdGhlc2UgcmVjb21tZW5kYXRpb25zIHRvIG5vbi1wc2MgR01QTFMgTFNQcyBhdCBhbGwg aW4gdGhlIGluaXRpYWwgcmV2aXNpb24gLS0gd2Ugc2ltcGx5IGRpZG4ndCBjYXJlIDopLiBCdXQg c2luY2UgaXQgd2FzIHBvaW50ZWQgb3V0IHRvIHVzIHRoYXQgbW9zdCBvZiB0aGVzZSByZWNvbW1l bmRhdGlvbnMgaGF2ZSBnZW5lcmljIGFwcGxpY2FiaWxpdHksIEkgYWdyZWUgdGhhdCBpdCB3b3Vs ZCBiZSB1c2VmdWwgdG8gY2xhcmlmeSB0aGUgZGVncmVlIG9mIGFwcGxpY2FiaWxpdHkgdG8gc3Vj aCBuZXR3b3JrcyBpbiB0aGUgbmV4dCByZXZpc2lvbiBvZiB0aGUgZHJhZnQuIEF0IGEgaGlnaC1s ZXZlbCwgZXZlcnl0aGluZyBleGNlcHQgU2VjdGlvbiAyLjUgKEdNUExTIFJTVlAtVEUgTFNQcyBk byBub3QgdXNlIFJvdXRlci1BbGVydCBmb3IgUGF0aHMpIGFuZCBTZWN0aW9uIDIuNiAodGhlcmUg YXJlIGRpZmZlcmVudCB3YXlzIG9mIGNoZWNraW5nIGRhdGEtcGxhbmUgcmVhZGluZXNzIGZvciBu b24gcHNjIExTUHMpIHNob3VsZCBoYXZlIGdlbmVyaWMgYXBwbGljYWJpbGl0eS4NCg0KWW91IHNh aWQ6DQoNCuKAnFRoZXJlIGFyZSAzIHVuZGVybHlpbmcgcHJpbmNpcGxlcyBkcml2aW5nIHRoZXNl IHJlY29tbWVuZGF0aW9uczoNCi0gQ29tcGxldGVseSBlbGltaW5hdGUgdGhlIHJlbGlhbmNlIG9u IHJlZnJlc2hlcyBmb3Igc3RhdGUgc3luYy4NCi0gQ29tcGxldGVseSBlbGltaW5hdGUgdGhlIHJl bGlhbmNlIG9uIHJlZnJlc2ggdGltZW91dHMgZm9yIHN0YWxlIHN0YXRlDQpjbGVhbnVwLg0KLSBJ bXBsZW1lbnQgcGVyLXBlZXIgZmxvdyBjb250cm9sLuKAnQ0KDQpJbiBvcmRlciB0byBhY2hpZXZl IHRoZXNlIHByaW5jaXBsZXMgeW91IHJlY29tbWVuZCDigJxJbXBsZW1lbnRpbmcgY291cGxpbmcg dGhlIHN0YXRlIG9mIGluZGl2aWR1YWwgTFNQcyB3aXRoIHRoZSBzdGF0ZSBvZiB0aGUgY29ycmVz cG9uZGluZyBSU1ZQLVRFIHNpZ25hbGluZyBhZGphY2VuY3ku4oCdIChjb3BpZWQgZnJvbSB0aGUg ZHJhZnQpLiBTaW5jZSBpbiB0aGUgdHJhbnNwb3J0IG5ldHdvcmsgeW91IHJlYWxseSBzaG91bGRu 4oCZdCBkbyB0aGF0LCBJ4oCZbSBpbnRlcmVzdGVkIGhvdyB5b3UgY2FuIGZ1bGZpbGwgYWJvdmUg bWVudGlvbmVkIHByaW5jaXBsZXMgd2l0aG91dCBpdC4NCg0KVlBCPD0+IElmIHRoZSBlbGVtZW50 cyBpbiB0aGlzIHRyYW5zcG9ydCBuZXR3b3JrIG9mIHlvdXJzIGFyZSBydW5uaW5nIHN0YW5kYXJk IEdNUExTIENvbnRyb2wtUGxhbmUgKG5vdCBzb21lIEdNUExTIGJhc2VkIHByb3ByaWV0YXJ5IHZl cnNpb24pLCBwbGVhc2UgZWxhYm9yYXRlIHdoeSB5b3UgY2FuJ3QgY291cGxlIHRoZSBzdGF0ZSBv ZiBpbmRpdmlkdWFsIExTUHMgd2l0aCB0aGUgc3RhdGUgb2YgdGhlIGNvcnJlc3BvbmRpbmcgUlNW UC1URSBzaWduYWxpbmcgYWRqYWNlbmN5LiBJZiBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2xlYW51 cCB0aGUgTFNQLXN0YXRlIHdoZW4gdGhlIHJlZnJlc2ggdGltZXMgb3V0LCB0aGVuIGl0IHNob3Vs ZCBhbHNvIGJlIGFibGUgdG8gY2xlYW51cCB0aGUgTFNQLXN0YXRlIHdoZW4gdGhlIGhlbGxvLWFk amFjZW5jeSBnb2VzIGRvd24uIEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGFyZSBwcm9wcmlldGFy eSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3QgY2xlYW51cCB0aGUgTFNQLXN0YXRlIHdoZW4g dGhlIHJlZnJlc2ggdGltZXMgb3V0IC0tIHRob3NlIHByb3ByaWV0YXJ5IGltcGxlbWVudGF0aW9u cyBtaWdodCBuZWVkIHNvbWUgYWRkaXRpb25hbCBwcm9jZWR1cmVzICh0aGlzIGRyYWZ0IHdpbGwg bm90IGZ1cm5pc2ggdGhvc2UpLg0KVG8gZ2l2ZSBhbiBleGFtcGxlOg0KDQpQcmluY2lwbGUgMjog 4oCcQ29tcGxldGVseSBlbGltaW5hdGUgdGhlIHJlbGlhbmNlIG9uIHJlZnJlc2ggdGltZW91dHMg Zm9yIHN0YWxlIHN0YXRl4oCdDQoNCkluIHRoZSBkcmFmdCB5b3UgYXNzdW1lIHRoYXQgc3RhbGUg c3RhdGUgd2lsbCBiZSByZW1vdmVkIHRoYW5rcyB0bzogYSkgcmVsaWFibGUgVGVhci9FcnIgbWVz c2FnZXMgZGVsaXZlcnkgYW5kIGIpIHJlbW92aW5nIG9mIGxzcCBzdGF0ZSBhZnRlciBhZGphY2Vu Y3kgbG9zcy4gU2luY2UgYikgZG9lcyBub3Qgd29yayBpbiB0cmFuc3BvcnQsIGhvdyBjYW4geW91 IGNvdmVyIHNjZW5hcmlvcyBpbnZvbHZpbmcgYSByZWJvb3Qgb2YgYSBSU1ZQIHNwZWFrZXIgd2hp bGUgdGhlIHNlcnZpY2UgaXMgdG9ybiBkb3duIGUuZy4gYnkgUGF0aFRlYXI/DQoNCg0KVlBCIDw9 PiBBZ2FpbiwgcGxlYXNlIGVsYWJvcmF0ZSB3aHkgeW91IGNhbm5vdCByZW1vdmUgTFNQIGFmdGVy IGFkamFjZW5jeSBsb3NzIGlmIHlvdSBhcmUgdXNpbmcgc3RhbmRhcmQgR01QTFMgUlNWUC1URS4N Cg0KVGhhbmtzLA0KUGF3ZWwNCg0KDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzp0ZWFzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVmlzaG51 IFBhdmFuIEJlZXJhbQ0KU2VudDogVGh1cnNkYXksIE1hcmNoIDI2LCAyMDE1IDM6NTYgUE0NClRv OiBMb2EgQW5kZXJzc29uDQpDYzogdGVhc0BpZXRmLm9yZzxtYWlsdG86dGVhc0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbVGVhc10gUlNWUCBURSBTY2FsYWJpbGl0eSAtIFJlY29tbWVuZGF0aW9u cw0KDQpMb2EsIEhpIQ0KVGhhbmtzIGZvciBwb2ludGluZyBpdCBvdXQuDQpZZXMsIG5vdCByZWZl cmVuY2luZy9tZW50aW9uaW5nIFJGQyA1NDM5IHdhcyBhIG1pc3Rha2UgYW5kIHRoYXQgd291bGQg YmUgcmVjdGlmaWVkIGluIHRoZSBuZXh0IHZlcnNpb24uIChCdXQgSSBkaWQgbWVudGlvbiBSRkM1 NDM5IGluIHRoaXMgbW9ybmluZydzIHByZXNlbnRhdGlvbiA6KSkuDQpCb3RoIFJGQzI5NjEgYW5k IFJGQzU0MzkgZG8gdGFsayBhYm91dCBoYXZpbmcgYSBsYXJnZSByZWZyZXNoIGludGVydmFsIGFz IGEgbWVhbnMgb2YgcmVkdWNpbmcgdGhlIHJhdGUgb2YgbWVzc2FnZXMgdGhhdCB0aGUgY29udHJv bC1wbGFuZSBoYXMgdG8gcHJvY2VzcywgYnV0IGFsc28gd2FybiBhYm91dCB0aGUgbG9zcyBvZiBm dW5jdGlvbmFsaXR5IGFzc29jaWF0ZWQgd2l0aCBkb2luZyBzby4gPGRyYWZ0LWJlZXJhbS1tcGxz LXJzdnAtdGUtc2NhbGluZz4gYnJpbmdzIGJhY2sgdGhlIG5vdGlvbiBvZiByZWZyZXNoIGluZGVw ZW5kZW50IFJTVlAsIGJ1dCBhbHNvIGluY2x1ZGVzIHJlY29tbWVuZGF0aW9ucyB0aGF0IHdvdWxk IG1ha2Ugc3VyZSB0aGF0IHRoZXJlIGlzIG5vIGxvc3Mgb2YgZnVuY3Rpb25hbGl0eSB3aGVuIGEg bGFyZ2UgcmVmcmVzaCBpbnRlcnZhbCBpcyB1c2VkLg0KUmVnYXJkcywNCi1QYXZhbg0KDQoNCk9u IFRodSwgTWFyIDI2LCAyMDE1IGF0IDM6MzEgUE0sIExvYSBBbmRlcnNzb24gPGxvYUBwaS5udTxt YWlsdG86bG9hQHBpLm51Pj4gd3JvdGU6DQpQYXZhbiwNCg0KVGhlIE1QTFMgd2cgZGlkICJBbiBB bmFseXNpcyBvZiBTY2FsaW5nIElzc3VlcyBpbiBNUExTLVRFIENvcmUgTmV0d29ya3MiDQpSRkMg NTQzOS4gVGhpcyBSRkMgaXMgbm90IG1lbnRpb25lZCBpbiBkcmFmdC1iZWVyYW0tbXBscy1yc3Zw LQ0KdGUtc2NhbGluZy4gVGhlIHRvcGljcyBzZWVtcyBjbG9zZSBlbm91Z2ggdG8gbWFrZSB3b3J0 aCBsb29rIGF0IHRoYXQNCmRvY3VtZW50Lg0KDQovTG9hDQoNCg0KDQoNCk9uIDIwMTUtMDMtMjYg MTQ6MDksIFZpc2hudSBQYXZhbiBCZWVyYW0gd3JvdGU6DQpodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtYmVlcmFtLW1wbHMtcnN2cC10ZS1zY2FsaW5nLTAxDQoNCkZvbGtzLCBIaSEN Cg0KPGRyYWZ0LWJlZXJhbS1tcGxzLXJzdnAtdGUtc2NhbGluZz4gd2FzIHByZXNlbnRlZCBlYXJs aWVyIHRvZGF5IGluIHRoZQ0KVEVBUyBXRyBzZXNzaW9uLiBUaGVyZSB3YXNuJ3Qgc3VmZmljaWVu dCB0aW1lIHRvIHRha2UgaW4gcXVlc3Rpb25zIGF0DQp0aGUgZW5kIG9mIHRoZSBwcmVzZW50YXRp b24gKGFwb2xvZ2l6ZSBmb3IgdGhhdCkuIFNvLCBJJ20gb3BlbmluZyB1cA0KdGhpcyB0aHJlYWQg dG8gbWFrZSBzdXJlIHRoYXQgYWxsIHRob3NlIHF1ZXN0aW9ucyBnZXQgYW5zd2VyZWQuDQoNCkEg ZmV3IHBvaW50cyB0byBub3RlOg0KDQoxLiBUaGVzZSByZWNvbW1lbmRhdGlvbnMgd2VyZSBwdXQg dG9nZXRoZXIgZm9yIGNhdGVyaW5nIHRvIGN1cnJlbnQgTVBMUw0KUlNWUC1URSBTY2FsYWJpbGl0 eSBuZWVkcy4gQnV0IHNpbmNlIG1vc3Qgb2YgdGhlbSBoYXZlIGdlbmVyaWMNCmFwcGxpY2FiaWxp dHksIHRoaXMgZHJhZnQgaXMgYmVpbmcgZGlzY3Vzc2VkIGluIFRFQVMuDQoNCjIuIFRoZXJlIGFy ZSAzIHVuZGVybHlpbmcgcHJpbmNpcGxlcyBkcml2aW5nIHRoZXNlIHJlY29tbWVuZGF0aW9ucw0K LSBDb21wbGV0ZWx5IGVsaW1pbmF0ZSB0aGUgcmVsaWFuY2Ugb24gcmVmcmVzaGVzIGZvciBzdGF0 ZSBzeW5jLg0KLSBDb21wbGV0ZWx5IGVsaW1pbmF0ZSB0aGUgcmVsaWFuY2Ugb24gcmVmcmVzaCB0 aW1lb3V0cyBmb3Igc3RhbGUgc3RhdGUNCmNsZWFudXAuDQotIEltcGxlbWVudCBwZXItcGVlciBm bG93IGNvbnRyb2wuDQoNCjMuIFRoaXMgaXMgbm90IGEgdGhlb3JldGljYWwgZXhlcmNpc2UuIFdl IGhhdmUgYW4gaW1wbGVtZW50YXRpb24gdGhhdA0KcmVsaWdpb3VzbHkgYWRvcHRzIHRoZXNlIHJl Y29tbWVuZGF0aW9ucyAtLSBhbmQgdGhlIHNhdmluZ3MgaW4gdGVybXMgb2YNCnByb2Nlc3Npbmcg Y3ljbGVzIGZvciB0aGUgY29udHJvbC1wbGFuZSAoYXMgYSByZXN1bHQgb2YgdGhlIHNpZ25pZmlj YW50DQpyZWR1Y3Rpb24gaW4gSS9PIG92ZXJoZWFkKSBpcyBxdWl0ZSBzaWduaWZpY2FudC4NCg0K UGxlYXNlIGRvIGdpdmUgdGhlc2UgcmVjb21tZW5kYXRpb25zIHNvbWUgc2VyaW91cyBjb25zaWRl cmF0aW9uIGFuZCBsZXQNCnVzIGtub3cgeW91ciBxdWVzdGlvbnMvY29tbWVudHMuDQoNClJlZ2Fy ZHMsDQotUGF2YW4NCihvbiBiZWhhbGYgb2YgdGhlIGF1dGhvcnMpDQoNCg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlz dA0KVGVhc0BpZXRmLm9yZzxtYWlsdG86VGVhc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGVhcw0KDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAg ICAgICAgICAgICAgICAgICBlbWFpbDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzpsb2FA bWFpbDAxLmh1YXdlaS5jb20+DQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAg ICAgICAgIGxvYUBwaS5udTxtYWlsdG86bG9hQHBpLm51Pg0KSHVhd2VpIFRlY2hub2xvZ2llcyAo Y29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDczOSUy MDgxJTIwMjElMjA2ND4NCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNClRlYXMgbWFpbGluZyBsaXN0DQoNClRlYXNAaWV0Zi5vcmc8 bWFpbHRvOlRlYXNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGVhcw0K --_000_9D50FCE7413E3D4EA5E42331115FB5BC29BFB999xmbrcdx03ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJCb29rbWFuIE9sZCBTdHlsZSI7DQoJcGFub3NlLTE6 MiA1IDYgNCA1IDUgNSAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpQTDt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkJvb2ttYW4gT2xkIFN0 eWxlIiwic2VyaWYiOw0KCWNvbG9yOiM2MzI0MjM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44 NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDY4NjY3MTAy Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjAxNTczNTE0ODt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBi Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxl JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPkRpZXRlciw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtz ZXJpZiZxdW90Oztjb2xvcjojNjMyNDIzIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5I aSBhbGwsPGJyPg0KPGJyPg0KdHdvIGNvbW1lbnRzIHJlZ2FyZGluZyB0aGUgdXNhZ2Ugb2YgUlNW UCBpbiBHTVBMUyBlbmFibGVkIHRyYW5zcG9ydCBuZXR3b3Jrczo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQpJbiBteSB2aWV3LCBSU1ZQIHJlcXVpcmVzIExTUCBzdGF0ZSBjbGVh bnVwIGluIGNhc2Ugb2YgUlNWUCByZWZyZXNoIHRpbWVvdXRzIChzb2Z0IHN0YXRlIHByb3RvY29s KSAtIHlvdSBtYXksIGhvd2V2ZXIsIHN1c3BlbmQ8YnI+DQp0aGUgcmVmcmVzaCBtZWNoYW5pc20g aW4gY2FzZSB5b3VyIHNpZ25hbGxpbmcgY29tbXVuaWNhdGlvbiBpcyBicm9rZW4gd2hpbGUgeW91 ciBkYXRhIHBsYW5lIGlzIHdvcmtpbmcgcHJvcGVybHkuPG86cD48L286cD48L2xpPjwvb2w+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0Jvb2ttYW4gT2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2 MzI0MjMiPllvdSBjYW4gYWxzbyBqdXN0IHB1c2ggdGhlIHJlZnJlc2gtaW50ZXJ2YWwgYW5kIG1p c3MtY291bnQgaGlnaCBlbm91Z2ggdGhhdCB5b3VyIHRpbWVvdXQgaXMgc3VmZmljaWVudA0KIGZv ciBuZXR3b3JrIG9wZXJhdG9ycyB0byBub3RpY2UgYW5kIGZpeCB0aGUgcHJvYmxlbS4gU28geW91 ciBzb2Z0LXN0YXRlIHByb3RvY29sIGJlY29tZXPigKYgc29mdCwgbGlrZSByb2NrcyBhcmUgc29m dCA6KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdGFydD0iMiIgdHlwZT0iMSI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClJTVlAtVEUgc2Nh bGFiaWxpdHkgbWF5IG5vdCBiZSBhbiBpc3N1ZSBpbiBHTVBMUyBlbmFibGVkIHRyYW5zcG9ydCBu ZXR3b3JrcyBkdWUgdG8gdGhlIGZhY3QgdGhhdCB3ZSBoYXZlIGEgbGltaXRlZCBudW1iZXIgb2Y8 YnI+DQpMU1BzIHBlciBsaW5rIChjb3JyZXNwb25kaW5nIHRvIHRoZSBudW1iZXIgb2YgY2lyY3Vp dHMgcGVyIGxpbmspPG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4g T2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPlRydWUuIFBh dmFu4oCZcyBkcmFmdCBzZWVtcyB0byBiZSBhaW1lZCBtb3JlIGF0IHRoZSBwYWNrZXQgd29ybGQg d2hlcmUgc3VwcG9ydGluZyBodW5kcmVkcyBvZg0KIHRob3VzYW5kcyBvZiBMU1BzIGlzIGJlY29t aW5nIGEgcmVxdWlyZW1lbnQsIGFuZCB3ZeKAmWxsIGRvdWJ0bGVzcyBiZSBnZXR0aW5nIGludG8g dGhlIG1pbGxpb25zIGJlZm9yZSB3ZSBrbm93IGl0LiBJ4oCZbSBub3QgYXdhcmUgb2YgdGhpcyBi ZWluZyBhbiBpc3N1ZSBmb3IgR01QTFMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtCb29rbWFuIE9sZCBTdHlsZSZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjojNjMy NDIzIj5DaGVlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2ttYW4g T2xkIFN0eWxlJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM2MzI0MjMiPk1hdHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NClRoYW5rcyw8YnI+DQpEaWV0ZXI8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwMS4wNC4yMDE1IDE0OjQ4LCBQYXdlxYIgQnJ6 b3pvd3NraSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGF2YW4sPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj55b3Ugd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGk+4oCcVlBCJmx0Oz0mZ3Q7IElmIHRoZSBlbGVtZW50cyBpbiB0aGlz IHRyYW5zcG9ydCBuZXR3b3JrIG9mIHlvdXJzIGFyZSBydW5uaW5nIHN0YW5kYXJkIEdNUExTIENv bnRyb2wtUGxhbmUgKG5vdCBzb21lIEdNUExTIGJhc2VkIHByb3ByaWV0YXJ5IHZlcnNpb24pLCBw bGVhc2UgZWxhYm9yYXRlIHdoeSB5b3UgY2FuJ3QgY291cGxlIHRoZSBzdGF0ZSBvZiBpbmRpdmlk dWFsDQogTFNQcyB3aXRoIHRoZSBzdGF0ZSBvZiB0aGUgY29ycmVzcG9uZGluZyBSU1ZQLVRFIHNp Z25hbGluZyBhZGphY2VuY3kuIElmIGFuIGltcGxlbWVudGF0aW9uIGNhbiBjbGVhbnVwIHRoZSBM U1Atc3RhdGUgd2hlbiB0aGUgcmVmcmVzaCB0aW1lcyBvdXQsIHRoZW4gaXQgc2hvdWxkIGFsc28g YmUgYWJsZSB0byBjbGVhbnVwIHRoZSBMU1Atc3RhdGUgd2hlbiB0aGUgaGVsbG8tYWRqYWNlbmN5 IGdvZXMgZG93bi4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUNCiBhcmUgcHJvcHJpZXRhcnkgaW1w bGVtZW50YXRpb25zIHRoYXQgZG8gbm90IGNsZWFudXAgdGhlIExTUC1zdGF0ZSB3aGVuIHRoZSBy ZWZyZXNoIHRpbWVzIG91dCAtLSB0aG9zZSBwcm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbnMgbWln aHQgbmVlZCBzb21lIGFkZGl0aW9uYWwgcHJvY2VkdXJlcyAodGhpcyBkcmFmdCB3aWxsIG5vdCBm dXJuaXNoIHRob3NlKS7igJ08L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBndWVzcyB0aGlz IGlzIHdoZXJlIG91ciBkaXNjb25uZWN0IGNvbWVzIGZyb20uIFlvdSBjZXJ0YWlubHkga25vdyBS RkNzIGJldHRlciB0aGFuIG1lLiBJIGFzc3VtZWQgdGhhdCBJRVRGIHJlY29tbWVuZGF0aW9uIGZv ciBHTVBMUyBydW5uaW5nIGluIHRyYW5zcG9ydCBuZXR3b3Jrcw0KIHdvdWxkIGJlIE5PVCB0byBj bGVhbnVwIGxzcCBzdGF0ZSB3aGVuIHJlZnJlc2hlcyB0aW1lIG91dC4gSXMgaXQgbm90IHRoZSBj YXNlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXdl bDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVmlzaG51IFBhdmFu IEJlZXJhbSBbPGEgaHJlZj0ibWFpbHRvOnZpc2hudXBhdmFuQGdtYWlsLmNvbSI+bWFpbHRvOnZp c2hudXBhdmFuQGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBB cHJpbCAwMSwgMjAxNSAxMjoxMyBBTTxicj4NCjxiPlRvOjwvYj4gUGF3ZcWCIEJyem96b3dza2k8 YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0ZWFzQGlldGYub3JnIj50ZWFzQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RlYXNdIFJTVlAgVEUgU2NhbGFiaWxp dHkgLSBSZWNvbW1lbmRhdGlvbnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlBhd2Vs LCBIaSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3MgZm9yIHRoZSByZXNwb25zZS4gUGxlYXNlIHNl ZSBpbmxpbmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1QYXZh bjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBUdWUsIE1hciAzMSwgMjAxNSBhdCA1OjMwIFBNLCBQYXdlxYIgQnJ6b3pv d3NraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlBCcnpvem93c2tpQGFkdmFvcHRpY2FsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPlBCcnpvem93c2tpQGFkdmFvcHRpY2FsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXZhbiw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JIHRoaW5rIHRoaXMgaXMgZ3JlYXQgd29yayBhbmQgYXBwbGllcyB3ZWxsIHRvIHRoZSBwYWNr ZXQgbmV0d29ya3MuIEltaG8gdGhlIGRyYWZ0IHNob3VsZCBiZSBhdWdtZW50ZWQNCiB0byByZWZs ZWN0IHRvIHdoYXQgaXMgdGhlIGRlZ3JlZSBvZiBhcHBsaWNhYmlsaXR5IHRvIHRyYW5zcG9ydCBu ZXR3b3Jrcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5WUEIgJmx0 Oz0mZ3Q7IEFzIG1lbnRpb25lZCBlYXJsaWVyLCB0aGUgcmVjb21tZW5kYXRpb25zIGluIHRoZSBk cmFmdCB3ZXJlIHB1dCB0b2dldGhlciB0byBjYXRlciB0byBNUExTIFJTVlAtVEUgTFNQcy4gVGhl IGF1dGhvcnMgZGlkbid0IGNvbnNpZGVyIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZXNlIHJlY29t bWVuZGF0aW9ucyB0byBub24tcHNjIEdNUExTIExTUHMgYXQNCiBhbGwgaW4gdGhlIGluaXRpYWwg cmV2aXNpb24gLS0gd2Ugc2ltcGx5IGRpZG4ndCBjYXJlIDopLiBCdXQgc2luY2UgaXQgd2FzIHBv aW50ZWQgb3V0IHRvIHVzIHRoYXQgbW9zdCBvZiB0aGVzZSByZWNvbW1lbmRhdGlvbnMgaGF2ZSBn ZW5lcmljIGFwcGxpY2FiaWxpdHksIEkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8g Y2xhcmlmeSB0aGUgZGVncmVlIG9mIGFwcGxpY2FiaWxpdHkgdG8gc3VjaCBuZXR3b3JrcyBpbiB0 aGUgbmV4dCByZXZpc2lvbg0KIG9mIHRoZSBkcmFmdC4gQXQgYSBoaWdoLWxldmVsLCBldmVyeXRo aW5nIGV4Y2VwdCBTZWN0aW9uIDIuNSAoR01QTFMgUlNWUC1URSBMU1BzIGRvIG5vdCB1c2UgUm91 dGVyLUFsZXJ0IGZvciBQYXRocykgYW5kIFNlY3Rpb24gMi42ICh0aGVyZSBhcmUgZGlmZmVyZW50 IHdheXMgb2YgY2hlY2tpbmcgZGF0YS1wbGFuZSByZWFkaW5lc3MgZm9yIG5vbiBwc2MgTFNQcykg c2hvdWxkIGhhdmUgZ2VuZXJpYyBhcHBsaWNhYmlsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ WW91IHNhaWQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+4oCcVGhlcmUg YXJlIDMgdW5kZXJseWluZyBwcmluY2lwbGVzIGRyaXZpbmcgdGhlc2UgcmVjb21tZW5kYXRpb25z OjwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+LSBDb21wbGV0 ZWx5IGVsaW1pbmF0ZSB0aGUgcmVsaWFuY2Ugb24gcmVmcmVzaGVzIGZvciBzdGF0ZSBzeW5jLjxi cj4NCi0gQ29tcGxldGVseSBlbGltaW5hdGUgdGhlIHJlbGlhbmNlIG9uIHJlZnJlc2ggdGltZW91 dHMgZm9yIHN0YWxlIHN0YXRlPGJyPg0KY2xlYW51cC48YnI+DQotIEltcGxlbWVudCBwZXItcGVl ciBmbG93IGNvbnRyb2wu4oCdPC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGVzZSBw cmluY2lwbGVzIHlvdSByZWNvbW1lbmQg4oCcPGk+SW1wbGVtZW50aW5nIGNvdXBsaW5nIHRoZSBz dGF0ZSBvZiBpbmRpdmlkdWFsDQogTFNQcyB3aXRoIHRoZSBzdGF0ZSBvZiB0aGUgY29ycmVzcG9u ZGluZyBSU1ZQLVRFIHNpZ25hbGluZyBhZGphY2VuY3kuPC9pPuKAnSAoY29waWVkIGZyb20gdGhl IGRyYWZ0KS4gU2luY2UgaW4gdGhlIHRyYW5zcG9ydCBuZXR3b3JrIHlvdSByZWFsbHkgc2hvdWxk buKAmXQgZG8gdGhhdCwgSeKAmW0gaW50ZXJlc3RlZCBob3cgeW91IGNhbiBmdWxmaWxsIGFib3Zl IG1lbnRpb25lZCBwcmluY2lwbGVzIHdpdGhvdXQgaXQuDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5WUEImbHQ7PSZndDsgSWYgdGhlIGVs ZW1lbnRzIGluIHRoaXMgdHJhbnNwb3J0IG5ldHdvcmsgb2YgeW91cnMgYXJlIHJ1bm5pbmcgc3Rh bmRhcmQgR01QTFMgQ29udHJvbC1QbGFuZSAobm90IHNvbWUgR01QTFMgYmFzZWQgcHJvcHJpZXRh cnkgdmVyc2lvbiksIHBsZWFzZSBlbGFib3JhdGUgd2h5IHlvdSBjYW4ndCBjb3VwbGUgdGhlIHN0 YXRlIG9mIGluZGl2aWR1YWwgTFNQcw0KIHdpdGggdGhlIHN0YXRlIG9mIHRoZSBjb3JyZXNwb25k aW5nIFJTVlAtVEUgc2lnbmFsaW5nIGFkamFjZW5jeS4gSWYgYW4gaW1wbGVtZW50YXRpb24gY2Fu IGNsZWFudXAgdGhlIExTUC1zdGF0ZSB3aGVuIHRoZSByZWZyZXNoIHRpbWVzIG91dCwgdGhlbiBp dCBzaG91bGQgYWxzbyBiZSBhYmxlIHRvIGNsZWFudXAgdGhlIExTUC1zdGF0ZSB3aGVuIHRoZSBo ZWxsby1hZGphY2VuY3kgZ29lcyBkb3duLiBJIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBhcmUNCiBw cm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3QgY2xlYW51cCB0aGUgTFNQLXN0 YXRlIHdoZW4gdGhlIHJlZnJlc2ggdGltZXMgb3V0IC0tIHRob3NlIHByb3ByaWV0YXJ5IGltcGxl bWVudGF0aW9ucyBtaWdodCBuZWVkIHNvbWUgYWRkaXRpb25hbCBwcm9jZWR1cmVzICh0aGlzIGRy YWZ0IHdpbGwgbm90IGZ1cm5pc2ggdGhvc2UpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VG8gZ2l2ZSBhbiBleGFtcGxlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGk+PGJyPg0KUHJpbmNpcGxlIDI6IOKAnENvbXBsZXRlbHkg ZWxpbWluYXRlIHRoZSByZWxpYW5jZSBvbiByZWZyZXNoIHRpbWVvdXRzIGZvciBzdGFsZSBzdGF0 ZeKAnTwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkluIHRoZSBkcmFmdCB5b3UgYXNzdW1lIHRoYXQgc3RhbGUgc3RhdGUg d2lsbCBiZSByZW1vdmVkIHRoYW5rcyB0bzogYSkgcmVsaWFibGUgVGVhci9FcnIgbWVzc2FnZXMN CiBkZWxpdmVyeSBhbmQgYikgcmVtb3Zpbmcgb2YgbHNwIHN0YXRlIGFmdGVyIGFkamFjZW5jeSBs b3NzLiBTaW5jZSBiKSBkb2VzIG5vdCB3b3JrIGluIHRyYW5zcG9ydCwgaG93IGNhbiB5b3UgY292 ZXIgc2NlbmFyaW9zIGludm9sdmluZyBhIHJlYm9vdCBvZiBhIFJTVlAgc3BlYWtlciB3aGlsZSB0 aGUgc2VydmljZSBpcyB0b3JuIGRvd24gZS5nLiBieSBQYXRoVGVhcj88L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VlBCICZs dDs9Jmd0OyBBZ2FpbiwgcGxlYXNlIGVsYWJvcmF0ZSB3aHkgeW91IGNhbm5vdCByZW1vdmUgTFNQ IGFmdGVyIGFkamFjZW5jeSBsb3NzIGlmIHlvdSBhcmUgdXNpbmcgc3RhbmRhcmQgR01QTFMgUlNW UC1URS4mbmJzcDsNCjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBhd2VsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGVhcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0 ZWFzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50ZWFzLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5WaXNobnUgUGF2YW4gQmVlcmFtPGJyPg0KPGI+ U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAyNiwgMjAxNSAzOjU2IFBNPGJyPg0KPGI+VG86PC9i PiBMb2EgQW5kZXJzc29uPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dGVhc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRlYXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbVGVhc10gUlNWUCBURSBTY2FsYWJpbGl0eSAtIFJlY29tbWVuZGF0aW9uczwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij5Mb2EsIEhpITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij5UaGFua3MgZm9yIHBvaW50aW5nIGl0IG91dC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5ZZXMsIG5vdCByZWZlcmVuY2luZy9tZW50aW9u aW5nIFJGQyA1NDM5IHdhcyBhIG1pc3Rha2UgYW5kIHRoYXQgd291bGQgYmUgcmVjdGlmaWVkIGlu IHRoZSBuZXh0IHZlcnNpb24uIChCdXQgSSBkaWQgbWVudGlvbiBSRkM1NDM5IGluIHRoaXMgbW9y bmluZydzIHByZXNlbnRhdGlvbiA6KSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+Qm90aCBSRkMyOTYxIGFuZCBSRkM1NDM5IGRvIHRhbGsgYWJvdXQgaGF2aW5nIGEg bGFyZ2UgcmVmcmVzaCBpbnRlcnZhbCBhcyBhIG1lYW5zIG9mIHJlZHVjaW5nIHRoZSByYXRlIG9m IG1lc3NhZ2VzIHRoYXQgdGhlIGNvbnRyb2wtcGxhbmUgaGFzIHRvIHByb2Nlc3MsIGJ1dCBhbHNv IHdhcm4gYWJvdXQgdGhlIGxvc3MNCiBvZiBmdW5jdGlvbmFsaXR5IGFzc29jaWF0ZWQgd2l0aCBk b2luZyBzby4gJmx0O2RyYWZ0LWJlZXJhbS1tcGxzLXJzdnAtdGUtc2NhbGluZyZndDsgYnJpbmdz IGJhY2sgdGhlIG5vdGlvbiBvZiByZWZyZXNoIGluZGVwZW5kZW50IFJTVlAsIGJ1dCBhbHNvIGlu Y2x1ZGVzIHJlY29tbWVuZGF0aW9ucyB0aGF0IHdvdWxkIG1ha2Ugc3VyZSB0aGF0IHRoZXJlIGlz IG5vIGxvc3Mgb2YgZnVuY3Rpb25hbGl0eSB3aGVuIGEgbGFyZ2UgcmVmcmVzaCBpbnRlcnZhbCBp cw0KIHVzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4t UGF2YW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVGh1LCBNYXIgMjYsIDIwMTUgYXQg MzozMSBQTSwgTG9hIEFuZGVyc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxvYUBwaS5udSIgdGFy Z2V0PSJfYmxhbmsiPmxvYUBwaS5udTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5QYXZhbiw8YnI+DQo8YnI+DQpUaGUgTVBMUyB3ZyBkaWQgJnF1 b3Q7QW4gQW5hbHlzaXMgb2YgU2NhbGluZyBJc3N1ZXMgaW4gTVBMUy1URSBDb3JlIE5ldHdvcmtz JnF1b3Q7PGJyPg0KUkZDIDU0MzkuIFRoaXMgUkZDIGlzIG5vdCBtZW50aW9uZWQgaW4gZHJhZnQt YmVlcmFtLW1wbHMtcnN2cC08YnI+DQp0ZS1zY2FsaW5nLiBUaGUgdG9waWNzIHNlZW1zIGNsb3Nl IGVub3VnaCB0byBtYWtlIHdvcnRoIGxvb2sgYXQgdGhhdDxicj4NCmRvY3VtZW50Ljxicj4NCjxi cj4NCi9Mb2E8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiAyMDE1LTAzLTI2IDE0OjA5LCBWaXNobnUg UGF2YW4gQmVlcmFtIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1iZWVyYW0tbXBscy1yc3ZwLXRlLXNjYWxpbmctMDEiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVlcmFtLW1wbHMtcnN2cC10ZS1zY2FsaW5n LTAxPC9hPjxicj4NCjxicj4NCkZvbGtzLCBIaSE8YnI+DQo8YnI+DQombHQ7ZHJhZnQtYmVlcmFt LW1wbHMtcnN2cC10ZS1zY2FsaW5nJmd0OyB3YXMgcHJlc2VudGVkIGVhcmxpZXIgdG9kYXkgaW4g dGhlPGJyPg0KVEVBUyBXRyBzZXNzaW9uLiBUaGVyZSB3YXNuJ3Qgc3VmZmljaWVudCB0aW1lIHRv IHRha2UgaW4gcXVlc3Rpb25zIGF0PGJyPg0KdGhlIGVuZCBvZiB0aGUgcHJlc2VudGF0aW9uIChh cG9sb2dpemUgZm9yIHRoYXQpLiBTbywgSSdtIG9wZW5pbmcgdXA8YnI+DQp0aGlzIHRocmVhZCB0 byBtYWtlIHN1cmUgdGhhdCBhbGwgdGhvc2UgcXVlc3Rpb25zIGdldCBhbnN3ZXJlZC48YnI+DQo8 YnI+DQpBIGZldyBwb2ludHMgdG8gbm90ZTo8YnI+DQo8YnI+DQoxLiBUaGVzZSByZWNvbW1lbmRh dGlvbnMgd2VyZSBwdXQgdG9nZXRoZXIgZm9yIGNhdGVyaW5nIHRvIGN1cnJlbnQgTVBMUzxicj4N ClJTVlAtVEUgU2NhbGFiaWxpdHkgbmVlZHMuIEJ1dCBzaW5jZSBtb3N0IG9mIHRoZW0gaGF2ZSBn ZW5lcmljPGJyPg0KYXBwbGljYWJpbGl0eSwgdGhpcyBkcmFmdCBpcyBiZWluZyBkaXNjdXNzZWQg aW4gVEVBUy48YnI+DQo8YnI+DQoyLiBUaGVyZSBhcmUgMyB1bmRlcmx5aW5nIHByaW5jaXBsZXMg ZHJpdmluZyB0aGVzZSByZWNvbW1lbmRhdGlvbnM8YnI+DQotIENvbXBsZXRlbHkgZWxpbWluYXRl IHRoZSByZWxpYW5jZSBvbiByZWZyZXNoZXMgZm9yIHN0YXRlIHN5bmMuPGJyPg0KLSBDb21wbGV0 ZWx5IGVsaW1pbmF0ZSB0aGUgcmVsaWFuY2Ugb24gcmVmcmVzaCB0aW1lb3V0cyBmb3Igc3RhbGUg c3RhdGU8YnI+DQpjbGVhbnVwLjxicj4NCi0gSW1wbGVtZW50IHBlci1wZWVyIGZsb3cgY29udHJv bC48YnI+DQo8YnI+DQozLiBUaGlzIGlzIG5vdCBhIHRoZW9yZXRpY2FsIGV4ZXJjaXNlLiBXZSBo YXZlIGFuIGltcGxlbWVudGF0aW9uIHRoYXQ8YnI+DQpyZWxpZ2lvdXNseSBhZG9wdHMgdGhlc2Ug cmVjb21tZW5kYXRpb25zIC0tIGFuZCB0aGUgc2F2aW5ncyBpbiB0ZXJtcyBvZjxicj4NCnByb2Nl c3NpbmcgY3ljbGVzIGZvciB0aGUgY29udHJvbC1wbGFuZSAoYXMgYSByZXN1bHQgb2YgdGhlIHNp Z25pZmljYW50PGJyPg0KcmVkdWN0aW9uIGluIEkvTyBvdmVyaGVhZCkgaXMgcXVpdGUgc2lnbmlm aWNhbnQuPGJyPg0KPGJyPg0KUGxlYXNlIGRvIGdpdmUgdGhlc2UgcmVjb21tZW5kYXRpb25zIHNv bWUgc2VyaW91cyBjb25zaWRlcmF0aW9uIGFuZCBsZXQ8YnI+DQp1cyBrbm93IHlvdXIgcXVlc3Rp b25zL2NvbW1lbnRzLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KLVBhdmFuPGJyPg0KKG9uIGJl aGFsZiBvZiB0aGUgYXV0aG9ycyk8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVGVhcyBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86VGVhc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRlYXNA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90ZWFzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90ZWFzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KLS0gPGJy Pg0KPGJyPg0KPGJyPg0KTG9hIEFuZGVyc3NvbiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGVt YWlsOiA8YSBocmVmPSJtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFu ayI+DQpsb2FAbWFpbDAxLmh1YXdlaS5jb208L2E+PGJyPg0KU2VuaW9yIE1QTFMgRXhwZXJ0Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUi IHRhcmdldD0iX2JsYW5rIj4NCmxvYUBwaS5udTwvYT48YnI+DQpIdWF3ZWkgVGVjaG5vbG9naWVz IChjb25zdWx0YW50KSZuYnNwOyAmbmJzcDsgJm5ic3A7cGhvbmU6IDxhIGhyZWY9InRlbDolMkI0 NiUyMDczOSUyMDgxJTIwMjElMjA2NCIgdGFyZ2V0PSJfYmxhbmsiPg0KJiM0Mzs0NiA3MzkgODEg MjEgNjQ8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UZWFzIG1haWxpbmcgbGlzdDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpUZWFzQGlldGYub3JnIj5UZWFzQGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGVhcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90ZWFzPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9D50FCE7413E3D4EA5E42331115FB5BC29BFB999xmbrcdx03ciscoc_-- From nobody Wed Apr 1 07:59:44 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4721ACD48 for ; Wed, 1 Apr 2015 07:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7JmctcA5WFp for ; Wed, 1 Apr 2015 07:59:36 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0121ACD41 for ; Wed, 1 Apr 2015 07:59:34 -0700 (PDT) Received: by qcrf4 with SMTP id f4so30632222qcr.0 for ; Wed, 01 Apr 2015 07:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A+3boZ+FXAyHW7jo8HC1JwKteqCxPDdufFThPMkKkas=; b=uq7oogCrRDC25Q0u63dLpQ0Md3T+9bmpyWrTq46pQdEy5uctgGswY+hHb7oH1sWpGi O2jmmfU14/n9ruFZnpCTK4a4ErkTmpAzrpFds1Mxi7n/QxKvmwtGPAmSK3edfTBweyV+ xmePWZeh2t7MMNoZF35DqkiSD6CJVho+fGCkykRzakCbXIY2cnHoFlw8WDxes9ARNIQ3 ojBnxsbqgrVOxZ/Us6ZsZ2T1YZwxLhbAmtFGwgHraWtSLvN2CUsEdAFD7dDkak2bkz/M GUXO2K8OTl/0kZ+I4bSUPWD/OYvhS8PUAZ8xVnJ6TMcjbx5fxpxb/UPckNzurPPhK0by MhSw== MIME-Version: 1.0 X-Received: by 10.140.21.233 with SMTP id 96mr10795985qgl.78.1427900373895; Wed, 01 Apr 2015 07:59:33 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Wed, 1 Apr 2015 07:59:33 -0700 (PDT) In-Reply-To: <551BF98E.9050102@alcatel-lucent.com> References: <55145EA1.3010905@pi.nu> <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> <551BF98E.9050102@alcatel-lucent.com> Date: Wed, 1 Apr 2015 10:59:33 -0400 Message-ID: From: Vishnu Pavan Beeram To: Dieter Beller Content-Type: multipart/alternative; boundary=001a11c157a48fad340512aaf624 Archived-At: Cc: =?UTF-8?Q?Pawe=C5=82_Brzozowski?= , "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 14:59:41 -0000 --001a11c157a48fad340512aaf624 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dieter, Hi! Please see inline.. Regards, -Pavan On Wed, Apr 1, 2015 at 9:58 AM, Dieter Beller < Dieter.Beller@alcatel-lucent.com> wrote: > Hi all, > > two comments regarding the usage of RSVP in GMPLS enabled transport > networks: > > 1. In my view, RSVP requires LSP state cleanup in case of RSVP refresh > timeouts (soft state protocol) - you may, however, suspend > the refresh mechanism in case your signalling communication is broken > while your data plane is working properly. > > > > 1. RSVP-TE scalability may not be an issue in GMPLS enabled transport > networks due to the fact that we have a limited number of > LSPs per link (corresponding to the number of circuits per link) > > > [VPB] Totally agree that the scaling requirements imposed on MPLS RSVP-TE LSPs are very different from those imposed on non-psc RSVP-TE LSPs. The recommendations in this draft were put together to cater to the former set of requirements (and that would continue to be the primary focus of this draft). But one of the initial points that was made to us when we came out with this draft was that most of these recommendations are applicable to non-psc GMPLS LSPs as well -- and I don't think there is an argument against that statement (irrespective of whether "Scalability" is a current concern or not for GMPLS-enabled LSPs). > Thanks, > Dieter > > > On 01.04.2015 14:48, Pawe=C5=82 Brzozowski wrote: > > Pavan, > > > > you wrote: > > > > *=E2=80=9CVPB<=3D> If the elements in this transport network of yours are= running > standard GMPLS Control-Plane (not some GMPLS based proprietary version), > please elaborate why you can't couple the state of individual LSPs with t= he > state of the corresponding RSVP-TE signaling adjacency. If an > implementation can cleanup the LSP-state when the refresh times out, then > it should also be able to cleanup the LSP-state when the hello-adjacency > goes down. I understand that there are proprietary implementations that d= o > not cleanup the LSP-state when the refresh times out -- those proprietary > implementations might need some additional procedures (this draft will no= t > furnish those).=E2=80=9D* > > I guess this is where our disconnect comes from. You certainly know RFCs > better than me. I assumed that IETF recommendation for GMPLS running in > transport networks would be NOT to cleanup lsp state when refreshes time > out. Is it not the case? > > > > Thanks, > > Pawel > > > > *From:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com > ] > *Sent:* Wednesday, April 01, 2015 12:13 AM > *To:* Pawe=C5=82 Brzozowski > *Cc:* teas@ietf.org > *Subject:* Re: [Teas] RSVP TE Scalability - Recommendations > > > > Pawel, Hi! > > Thanks for the response. Please see inline. > > Regards, > > -Pavan > > > > On Tue, Mar 31, 2015 at 5:30 PM, Pawe=C5=82 Brzozowski < > PBrzozowski@advaoptical.com> wrote: > > Pavan, > > > > I think this is great work and applies well to the packet networks. Imho > the draft should be augmented to reflect to what is the degree of > applicability to transport networks. > > > > VPB <=3D> As mentioned earlier, the recommendations in the draft were put > together to cater to MPLS RSVP-TE LSPs. The authors didn't consider the > applicability of these recommendations to non-psc GMPLS LSPs at all in th= e > initial revision -- we simply didn't care :). But since it was pointed ou= t > to us that most of these recommendations have generic applicability, I > agree that it would be useful to clarify the degree of applicability to > such networks in the next revision of the draft. At a high-level, > everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert > for Paths) and Section 2.6 (there are different ways of checking data-pla= ne > readiness for non psc LSPs) should have generic applicability. > > > > You said: > > > > *=E2=80=9CThere are 3 underlying principles driving these recommendations= :* > > > > > *- Completely eliminate the reliance on refreshes for state sync. - > Completely eliminate the reliance on refresh timeouts for stale state > cleanup. - Implement per-peer flow control.=E2=80=9D* > > > > In order to achieve these principles you recommend =E2=80=9C*Implementing > coupling the state of individual LSPs with the state of the corresponding > RSVP-TE signaling adjacency.*=E2=80=9D (copied from the draft). Since in = the > transport network you really shouldn=E2=80=99t do that, I=E2=80=99m inter= ested how you can > fulfill above mentioned principles without it. > > > > VPB<=3D> If the elements in this transport network of yours are running > standard GMPLS Control-Plane (not some GMPLS based proprietary version), > please elaborate why you can't couple the state of individual LSPs with t= he > state of the corresponding RSVP-TE signaling adjacency. If an > implementation can cleanup the LSP-state when the refresh times out, then > it should also be able to cleanup the LSP-state when the hello-adjacency > goes down. I understand that there are proprietary implementations that d= o > not cleanup the LSP-state when the refresh times out -- those proprietary > implementations might need some additional procedures (this draft will no= t > furnish those). > > To give an example: > > > * Principle 2: =E2=80=9CCompletely eliminate the reliance on refresh time= outs for > stale state=E2=80=9D* > > > > In the draft you assume that stale state will be removed thanks to: a) > reliable Tear/Err messages delivery and b) removing of lsp state after > adjacency loss. Since b) does not work in transport, how can you cover > scenarios involving a reboot of a RSVP speaker while the service is torn > down e.g. by PathTear? > > > > > > VPB <=3D> Again, please elaborate why you cannot remove LSP after adjacen= cy > loss if you are using standard GMPLS RSVP-TE. > > > Thanks, > > Pawel > > > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Vishnu Pavan > Beeram > *Sent:* Thursday, March 26, 2015 3:56 PM > *To:* Loa Andersson > *Cc:* teas@ietf.org > *Subject:* Re: [Teas] RSVP TE Scalability - Recommendations > > > > Loa, Hi! > > Thanks for pointing it out. > > Yes, not referencing/mentioning RFC 5439 was a mistake and that would be > rectified in the next version. (But I did mention RFC5439 in this morning= 's > presentation :)). > > Both RFC2961 and RFC5439 do talk about having a large refresh interval as > a means of reducing the rate of messages that the control-plane has to > process, but also warn about the loss of functionality associated with > doing so. brings back the notion of > refresh independent RSVP, but also includes recommendations that would ma= ke > sure that there is no loss of functionality when a large refresh interval > is used. > > Regards, > > -Pavan > > > > > > On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson wrote: > > Pavan, > > The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks" > RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp- > te-scaling. The topics seems close enough to make worth look at that > document. > > /Loa > > > > > > On 2015-03-26 14:09, Vishnu Pavan Beeram wrote: > > https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01 > > Folks, Hi! > > was presented earlier today in the > TEAS WG session. There wasn't sufficient time to take in questions at > the end of the presentation (apologize for that). So, I'm opening up > this thread to make sure that all those questions get answered. > > A few points to note: > > 1. These recommendations were put together for catering to current MPLS > RSVP-TE Scalability needs. But since most of them have generic > applicability, this draft is being discussed in TEAS. > > 2. There are 3 underlying principles driving these recommendations > - Completely eliminate the reliance on refreshes for state sync. > - Completely eliminate the reliance on refresh timeouts for stale state > cleanup. > - Implement per-peer flow control. > > 3. This is not a theoretical exercise. We have an implementation that > religiously adopts these recommendations -- and the savings in terms of > processing cycles for the control-plane (as a result of the significant > reduction in I/O overhead) is quite significant. > > Please do give these recommendations some serious consideration and let > us know your questions/comments. > > Regards, > -Pavan > (on behalf of the authors) > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > > _______________________________________________ > Teas mailing listTeas@ietf.orghttps://www.ietf.org/mailman/listinfo/teas > > --001a11c157a48fad340512aaf624 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dieter, Hi!

Please see inline.= .

Regards,
-Pavan

On Wed, Apr 1, 2015 at 9:58= AM, Dieter Beller <Dieter.Beller@alcatel-lucent.com>= ; wrote:
=20 =20 =20
Hi all,

two comments regarding the usage of RSVP in GMPLS enabled transport networks:
  1. In my view, RSVP requires LSP state cleanup in case of RSVP refresh timeouts (soft state protocol) - you may, however, suspend
    the refresh mechanism in case your signalling communication is broken while your data plane is working properly.

  1. RSVP-TE scalability may not be an issue in GMPLS enabled transport networks due to the fact that we have a limited number of
    LSPs per link (corresponding to the number of circuits per link)

=C2=A0
[VPB] Totally agree that t= he scaling requirements imposed on MPLS RSVP-TE LSPs are very different fro= m those imposed on non-psc RSVP-TE LSPs. The recommendations in this draft = were put together to cater to the former set of requirements (and that woul= d continue to be the primary focus of this draft). But one of the initial p= oints that was made to us when we came out with this draft was that most of= these recommendations are applicable to non-psc GMPLS LSPs as well -- and = I don't think there is an argument against that statement (irrespective= of whether "Scalability" is a current concern or not for GMPLS-e= nabled LSPs).

=C2=A0
Thanks,
Dieter


On 01.04.2015 14:48, Pawe=C5=82 Brzozowski wrote:
=20 =20 =20

Pavan,<= /u>

=C2=A0<= /u>

yo= u wrote:

=C2=A0

=E2=80=9CVPB<=3D> If the elements in this transport network of yours are running standard GMPLS Control-Plane (not some GMPLS based proprietary version), please elaborate why you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. If an implementation can cleanup the LSP-state when the refresh times out, then it should also be able to cleanup the LSP-state when the hello-adjacency goes down. I understand that there are proprietary implementations that do not cleanup the LSP-state when the refresh times out -- those proprietary implementations might need some additional procedures (this draft will not furnish those).=E2=80=9D

I = guess this is where our disconnect comes from. You certainly know RFCs better than me. I assumed that IETF recommendation for GMPLS running in transport networks would be NOT to cleanup lsp state when refreshes time out. Is it not the case?

=C2=A0

Th= anks,

Pa= wel

=C2=A0

From: Vishnu Pavan Beeram [mai= lto:vishnupavan@gmail.com]
Sent: Wednesday, April 01, 2015 12:13 AM
To: Pawe=C5=82 Brzozowski
Cc: t= eas@ietf.org
Subject: Re: [Teas] RSVP TE Scalability - Recommendations

=C2=A0

Pawel= , Hi!

Thanks for the response. Please see inline.

Regards,

-Pavan

=C2=A0

On Tue, Mar 31, 2015 at 5:30 PM, Pawe=C5=82 Brzozowski <PBrzozowski@advaoptical.com= > wrote:

Pavan,

=C2=A0

I think this is great work and applies well to the packet networks. Imho the draft should be augmented to reflect to what is the degree of applicability to transport networks.

=C2=A0

VPB <=3D> As mentioned earlier, the recommendations in the draft were put together to cater to MPLS RSVP-TE LSPs. The authors didn't consider the applicability of these recommendations to non-psc GMPLS LSPs at all in the initial revision -- we simply didn't care :). But since it was pointed out to us that most of these recommendations have generic applicability, I agree that it would be useful to clarify the degree of applicability to such networks in the next revision of the draft. At a high-level, everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert for Paths) and Section 2.6 (there are different ways of checking data-plane readiness for non psc LSPs) should have generic applicability.

=C2=A0

You said:

=C2= =A0

= =E2=80=9CThere are 3 underlying principles driving these recommendations:=

= - Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.=E2=80= =9D

=C2=A0

In order to achieve these principles you recommend =E2=80=9CImplem= enting coupling the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency.=E2=80=9D (copied from the draft). Since in the transport network you really shouldn=E2=80= =99t do that, I=E2=80=99m interested how you can fulfill above mentioned principles without it.

=C2=A0

VPB<=3D> If the elements in this transport network of yours are running standard GMPLS Control-Plane (not some GMPLS based proprietary version), please elaborate why you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. If an implementation can cleanup the LSP-state when the refresh times out, then it should also be able to cleanup the LSP-state when the hello-adjacency goes down. I understand that there are proprietary implementations that do not cleanup the LSP-state when the refresh times out -- those proprietary implementations might need some additional procedures (this draft will not furnish those).

To give an example:

=
Principle 2: =E2=80=9CCompletely eliminat= e the reliance on refresh timeouts for stale state=E2=80=9D

=C2=A0

In the draft you assume that stale state will be removed thanks to: a) reliable Tear/Err messages delivery and b) removing of lsp state after adjacency loss. Since b) does not work in transport, how can you cover scenarios involving a reboot of a RSVP speaker while the service is torn down e.g. by PathTear?

=C2=A0

=C2=A0

VPB <=3D> Again, pleas= e elaborate why you cannot remove LSP after adjacency loss if you are using standard GMPLS RSVP-TE.=C2=A0
=C2=A0

Thanks,

Pawel

=C2=A0

=C2=A0

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, March 26, 2015 3:56 PM
To: Loa Andersson
Cc: teas@ietf.org
Subject: Re: [Teas] RSVP TE Scalability - Recommendations=

=C2=A0=

Loa, Hi!

Thanks for pointing it out.<= /u>

Yes, not referencing/mentioning RFC 5439 was a mistake and that would be rectified in the next version. (But I did mention RFC5439 in this morning's presentation :)).

Both RFC2961 and RFC5439 do talk about having a large refresh interval as a means of reducing the rate of messages that the control-plane has to process, but also warn about the loss of functionality associated with doing so. <draft-beeram-mpls-rsvp-te-scali= ng> brings back the notion of refresh independent RSVP, but also includes recommendations that would make sure that there is no loss of functionality when a large refresh interval is used.

Regards,<= u>

-Pavan

=C2=A0

=C2=A0

On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson <loa@pi.nu> wrote:

Pavan,

The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks"
RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp-
te-scaling. The topics seems close enough to make worth look at that
document.

/Loa





On 2015-03-26 14:09, Vishnu Pavan Beeram wrote:=

https://tools.ietf.org/html/draft-= beeram-mpls-rsvp-te-scaling-01

Folks, Hi!

<draft-beeram-mpls-rsvp-te-s= caling> was presented earlier today in the
TEAS WG session. There wasn't sufficient time to take in questions at
the end of the presentation (apologize for that). So, I'm opening up
this thread to make sure that all those questions get answered.

A few points to note:

1. These recommendations were put together for catering to current MPLS
RSVP-TE Scalability needs. But since most of them have generic
applicability, this draft is being discussed in TEAS.

2. There are 3 underlying principles driving these recommendations
- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.

3. This is not a theoretical exercise. We have an implementation that
religiously adopts these recommendations -- and the savings in terms of
processing cycles for the control-plane (as a result of the significant
reduction in I/O overhead) is quite significant.

Please do give these recommendations some serious consideration and let
us know your questions/comments.

Regards,
-Pavan
(on behalf of the authors)



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo= /teas


--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0pho= ne: +46 739 81 21 64

=C2=A0

=C2=A0



_______________________________________________
Teas mailing list
Teas@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/teas

--001a11c157a48fad340512aaf624-- From nobody Wed Apr 1 08:46:30 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E08D1ACDE8 for ; Wed, 1 Apr 2015 08:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.886 X-Spam-Level: X-Spam-Status: No, score=-5.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ2lZg7fY7Z7 for ; Wed, 1 Apr 2015 08:46:25 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC041ACE3E for ; Wed, 1 Apr 2015 08:46:23 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 7EB1EA3E4FAAD; Wed, 1 Apr 2015 15:46:18 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t31FkIJV026692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 17:46:19 +0200 Received: from [149.204.107.61] (135.239.27.38) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Apr 2015 17:46:18 +0200 Message-ID: <551C12C9.80704@alcatel-lucent.com> Date: Wed, 1 Apr 2015 17:46:17 +0200 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Matt Hartley (mhartley)" , =?UTF-8?B?UGF3ZcWCIEJy?= =?UTF-8?B?em96b3dza2k=?= , Vishnu Pavan Beeram References: <55145EA1.3010905@pi.nu> <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> <551BF98E.9050102@alcatel-lucent.com> <9D50FCE7413E3D4EA5E42331115FB5BC29BFB999@xmb-rcd-x03.cisco.com> In-Reply-To: <9D50FCE7413E3D4EA5E42331115FB5BC29BFB999@xmb-rcd-x03.cisco.com> Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.38] Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 15:46:28 -0000 Hi Matt, all,

On 01.04.2015 16:30, Matt Hartley (mhartley) wrote:

Dieter,

 

Hi all,

two comments regarding the usage of RSVP in GMPLS enabled transport networks:

  1. In my view, RSVP requires LSP state cleanup in case of RSVP refresh timeouts (soft state protocol) - you may, however, suspend
    the refresh mechanism in case your signalling communication is broken while your data plane is working properly.

You can also just push the refresh-interval and miss-count high enough that your timeout is sufficient for network operators to notice and fix the problem. So your soft-state protocol becomes… soft, like rocks are soft :)

this is what we GMPLS folks normally do! Without refresh timeouts you may end up having orphaned resources which is also bad!


Thanks,
Dieter

  1. RSVP-TE scalability may not be an issue in GMPLS enabled transport networks due to the fact that we have a limited number of
    LSPs per link (corresponding to the number of circuits per link)

True. Pavan’s draft seems to be aimed more at the packet world where supporting hundreds of thousands of LSPs is becoming a requirement, and we’ll doubtless be getting into the millions before we know it. I’m not aware of this being an issue for GMPLS.

Cheers

Matt


Thanks,
Dieter

On 01.04.2015 14:48, Paweł Brzozowski wrote:

Pavan,

 

you wrote:

 

“VPB<=> If the elements in this transport network of yours are running standard GMPLS Control-Plane (not some GMPLS based proprietary version), please elaborate why you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. If an implementation can cleanup the LSP-state when the refresh times out, then it should also be able to cleanup the LSP-state when the hello-adjacency goes down. I understand that there are proprietary implementations that do not cleanup the LSP-state when the refresh times out -- those proprietary implementations might need some additional procedures (this draft will not furnish those).”

I guess this is where our disconnect comes from. You certainly know RFCs better than me. I assumed that IETF recommendation for GMPLS running in transport networks would be NOT to cleanup lsp state when refreshes time out. Is it not the case?

 

Thanks,

Pawel

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Wednesday, April 01, 2015 12:13 AM
To: Paweł Brzozowski
Cc: teas@ietf.org
Subject: Re: [Teas] RSVP TE Scalability - Recommendations

 

Pawel, Hi!

Thanks for the response. Please see inline.

Regards,

-Pavan

 

On Tue, Mar 31, 2015 at 5:30 PM, Paweł Brzozowski <PBrzozowski@advaoptical.com> wrote:

Pavan,

 

I think this is great work and applies well to the packet networks. Imho the draft should be augmented to reflect to what is the degree of applicability to transport networks.

 

VPB <=> As mentioned earlier, the recommendations in the draft were put together to cater to MPLS RSVP-TE LSPs. The authors didn't consider the applicability of these recommendations to non-psc GMPLS LSPs at all in the initial revision -- we simply didn't care :). But since it was pointed out to us that most of these recommendations have generic applicability, I agree that it would be useful to clarify the degree of applicability to such networks in the next revision of the draft. At a high-level, everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert for Paths) and Section 2.6 (there are different ways of checking data-plane readiness for non psc LSPs) should have generic applicability.

 

You said:

 

“There are 3 underlying principles driving these recommendations:

- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.”

 

In order to achieve these principles you recommend “Implementing coupling the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency.” (copied from the draft). Since in the transport network you really shouldn’t do that, I’m interested how you can fulfill above mentioned principles without it.

 

VPB<=> If the elements in this transport network of yours are running standard GMPLS Control-Plane (not some GMPLS based proprietary version), please elaborate why you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. If an implementation can cleanup the LSP-state when the refresh times out, then it should also be able to cleanup the LSP-state when the hello-adjacency goes down. I understand that there are proprietary implementations that do not cleanup the LSP-state when the refresh times out -- those proprietary implementations might need some additional procedures (this draft will not furnish those).

To give an example:


Principle 2: “Completely eliminate the reliance on refresh timeouts for stale state”

 

In the draft you assume that stale state will be removed thanks to: a) reliable Tear/Err messages delivery and b) removing of lsp state after adjacency loss. Since b) does not work in transport, how can you cover scenarios involving a reboot of a RSVP speaker while the service is torn down e.g. by PathTear?

 

 

VPB <=> Again, please elaborate why you cannot remove LSP after adjacency loss if you are using standard GMPLS RSVP-TE. 
 

Thanks,

Pawel

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, March 26, 2015 3:56 PM
To: Loa Andersson
Cc: teas@ietf.org
Subject: Re: [Teas] RSVP TE Scalability - Recommendations

 

Loa, Hi!

Thanks for pointing it out.

Yes, not referencing/mentioning RFC 5439 was a mistake and that would be rectified in the next version. (But I did mention RFC5439 in this morning's presentation :)).

Both RFC2961 and RFC5439 do talk about having a large refresh interval as a means of reducing the rate of messages that the control-plane has to process, but also warn about the loss of functionality associated with doing so. <draft-beeram-mpls-rsvp-te-scaling> brings back the notion of refresh independent RSVP, but also includes recommendations that would make sure that there is no loss of functionality when a large refresh interval is used.

Regards,

-Pavan

 

 

On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson <loa@pi.nu> wrote:

Pavan,

The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks"
RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp-
te-scaling. The topics seems close enough to make worth look at that
document.

/Loa





On 2015-03-26 14:09, Vishnu Pavan Beeram wrote:

https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01

Folks, Hi!

<draft-beeram-mpls-rsvp-te-scaling> was presented earlier today in the
TEAS WG session. There wasn't sufficient time to take in questions at
the end of the presentation (apologize for that). So, I'm opening up
this thread to make sure that all those questions get answered.

A few points to note:

1. These recommendations were put together for catering to current MPLS
RSVP-TE Scalability needs. But since most of them have generic
applicability, this draft is being discussed in TEAS.

2. There are 3 underlying principles driving these recommendations
- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.

3. This is not a theoretical exercise. We have an implementation that
religiously adopts these recommendations -- and the savings in terms of
processing cycles for the control-plane (as a result of the significant
reduction in I/O overhead) is quite significant.

Please do give these recommendations some serious consideration and let
us know your questions/comments.

Regards,
-Pavan
(on behalf of the authors)




_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

 

 




_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

From nobody Wed Apr 1 12:13:16 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFEE1A87F2 for ; Wed, 1 Apr 2015 12:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw9Kc4O82y5J for ; Wed, 1 Apr 2015 12:13:10 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 549801A87EF for ; Wed, 1 Apr 2015 12:13:09 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t31JD46b003650; Wed, 1 Apr 2015 20:13:04 +0100 Received: from 950129200 (089144233220.atnat0042.highway.a1.net [89.144.233.220]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t31JCrlZ003601 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 1 Apr 2015 20:12:56 +0100 From: "Adrian Farrel" To: "'Vishnu Pavan Beeram'" , "=?UTF-8?Q?'Pawe=C5=82_Brzozowski'?=" References: <55145EA1.3010905@pi.nu> <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> In-Reply-To: Date: Wed, 1 Apr 2015 20:12:50 +0100 Message-ID: <03aa01d06caf$dd9069d0$98b13d70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AB_01D06CB8.3FB8C3C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH/wz6b61XarqYhaGZVCORId7UiYwFncShzAePPvMgCW3fweAGCgECgAdJyg4IC6Qb00Zx6sv7A Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21442.000 X-TM-AS-Result: No--24.504-10.0-31-10 X-imss-scan-details: No--24.504-10.0-31-10 X-TMASE-MatchedRID: pS5owHKhBO0wJ6xbTjBa5odlc1JaOB1TKsyJ61LbQNHWIoKbVgvCfsCS 2AMm1nQC5Borxp1ZhZYXIJWO/t2WjkABfZHqYIeMSEQN/D/3cG5u/Xr6CKXiNwRmqGGEuVK1l05 GhWTdDwiJgTp+B9VBCa0RYwD4lwpwYqmUd3tOErXWBrIvDxFuQwMDwjfX+DzgZ5yuplze9pt4jD dXUi1GIk4W7yyyPEbzq5QP9dOpw8O/VDG+xJ1b6JEbNXwHGDRxOhJ9m53n4aD4sp4xDuD8bLliD 6D5Idq7AHjthvGw0Y03KhLsGCPGMvd9n5vMgdWeW7gz/Gbgpl6MAJiPkwmsiZ0j8OKRnVQ8H4NL ANR09sYwT/9yGDjFPa2PVXir30/xk4P+vqTbTVH5wpfrIJDXeyT0t/+p7zHH2Fq6de/aaIb1sWD i2X/t1GbUH+77spTYxEHRX5tTvxlcMjZyPiYiqTCIlN/eSPB99kP3kjqA4vFUjspoiX02F9FmvX k01mAh79PsZqyxH2DSmFz/r3EszIe/o1zWuGFvy18e5+drKgbE30otgLqu0aNjYs/M7FeKqtt1T GZxNoCOouA24We/2hSG66XlhtMxJWpN7A2W3R5VXhlmZsTdjPaS52LUPfcS7ZuNmL4Rc2czg7ZK hHBREnr+gPBivTPBFiXOYdxsXIplCJn1G1Wd/Zmug812qIbzC4rWEiK1Igeyd65qZFFPk45KOSC tTm4DRnUgijdt6WRwvm2OOSnWuxadv+F8ucSI/Sl5cYQQGW+uiAW0p38/t9KWShEsIp8TnpBWeV cwjKBet9iiyf76iqEgGCR+ger2Ih2a2QHA7cOeAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCslWg7STLUbyoc21ChMRI+GwhVRZruzyc+Ps1nMmcvODjxYVzI3UCCaY= Archived-At: Cc: teas@ietf.org Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 19:13:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03AB_01D06CB8.3FB8C3C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm doing this from memory - someone might want to read an RFC. =20 3473 includes processing to enable restart after a control pane = communication failure. Fundamental to that is LSP soft state does not = time out when the session (hello state) is down. That would probably be = section 9. =20 So "it all depends what you mean". =20 Adrian =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram Sent: 01 April 2015 15:10 To: Pawe=C5=82 Brzozowski Cc: teas@ietf.org Subject: Re: [Teas] RSVP TE Scalability - Recommendations =20 Pawel, Hi! There is no (AFAIK) GMPLS document that recommends NOT cleaning up LSP = state when refresh times out. So, the point that you are making about = these recommendations not being applicable for GMPLS LSPs isn't quite = true. I do understand that there are proprietary implementations out there = that use some additional procedures (after the refresh times out) to = make sure that it is absolutely safe to cleanup the data-plane before = cleaning up the corresponding LSP state. With the new recommendations = proposed in , these implementations should still be able = to run similar procedures after the node-hello times out and then = cleanup the state. But since these are all proprietary mechanisms, this = draft will not spell all this out for you. Regards, -Pavan =20 On Wed, Apr 1, 2015 at 8:48 AM, Pawe=C5=82 Brzozowski = wrote: Pavan, =20 you wrote: =20 =E2=80=9CVPB<=3D> If the elements in this transport network of yours are = running standard GMPLS Control-Plane (not some GMPLS based proprietary = version), please elaborate why you can't couple the state of individual = LSPs with the state of the corresponding RSVP-TE signaling adjacency. If = an implementation can cleanup the LSP-state when the refresh times out, = then it should also be able to cleanup the LSP-state when the = hello-adjacency goes down. I understand that there are proprietary = implementations that do not cleanup the LSP-state when the refresh times = out -- those proprietary implementations might need some additional = procedures (this draft will not furnish those).=E2=80=9D I guess this is where our disconnect comes from. You certainly know RFCs = better than me. I assumed that IETF recommendation for GMPLS running in = transport networks would be NOT to cleanup lsp state when refreshes time = out. Is it not the case? =20 Thanks, Pawel =20 From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]=20 Sent: Wednesday, April 01, 2015 12:13 AM To: Pawe=C5=82 Brzozowski Cc: teas@ietf.org Subject: Re: [Teas] RSVP TE Scalability - Recommendations =20 Pawel, Hi! Thanks for the response. Please see inline. Regards, -Pavan =20 On Tue, Mar 31, 2015 at 5:30 PM, Pawe=C5=82 Brzozowski = wrote: Pavan, =20 I think this is great work and applies well to the packet networks. Imho = the draft should be augmented to reflect to what is the degree of = applicability to transport networks. =20 VPB <=3D> As mentioned earlier, the recommendations in the draft were = put together to cater to MPLS RSVP-TE LSPs. The authors didn't consider = the applicability of these recommendations to non-psc GMPLS LSPs at all = in the initial revision -- we simply didn't care :). But since it was = pointed out to us that most of these recommendations have generic = applicability, I agree that it would be useful to clarify the degree of = applicability to such networks in the next revision of the draft. At a = high-level, everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use = Router-Alert for Paths) and Section 2.6 (there are different ways of = checking data-plane readiness for non psc LSPs) should have generic = applicability. =20 You said: =20 =E2=80=9CThere are 3 underlying principles driving these = recommendations: - Completely eliminate the reliance on refreshes for state sync. - Completely eliminate the reliance on refresh timeouts for stale state cleanup. - Implement per-peer flow control.=E2=80=9D =20 In order to achieve these principles you recommend =E2=80=9CImplementing = coupling the state of individual LSPs with the state of the = corresponding RSVP-TE signaling adjacency.=E2=80=9D (copied from the = draft). Since in the transport network you really shouldn=E2=80=99t do = that, I=E2=80=99m interested how you can fulfill above mentioned = principles without it.=20 =20 VPB<=3D> If the elements in this transport network of yours are running = standard GMPLS Control-Plane (not some GMPLS based proprietary version), = please elaborate why you can't couple the state of individual LSPs with = the state of the corresponding RSVP-TE signaling adjacency. If an = implementation can cleanup the LSP-state when the refresh times out, = then it should also be able to cleanup the LSP-state when the = hello-adjacency goes down. I understand that there are proprietary = implementations that do not cleanup the LSP-state when the refresh times = out -- those proprietary implementations might need some additional = procedures (this draft will not furnish those). To give an example: Principle 2: =E2=80=9CCompletely eliminate the reliance on refresh = timeouts for stale state=E2=80=9D =20 In the draft you assume that stale state will be removed thanks to: a) = reliable Tear/Err messages delivery and b) removing of lsp state after = adjacency loss. Since b) does not work in transport, how can you cover = scenarios involving a reboot of a RSVP speaker while the service is torn = down e.g. by PathTear? =20 =20 VPB <=3D> Again, please elaborate why you cannot remove LSP after = adjacency loss if you are using standard GMPLS RSVP-TE. =20 =20 Thanks, Pawel =20 =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram Sent: Thursday, March 26, 2015 3:56 PM To: Loa Andersson Cc: teas@ietf.org Subject: Re: [Teas] RSVP TE Scalability - Recommendations =20 Loa, Hi! Thanks for pointing it out. Yes, not referencing/mentioning RFC 5439 was a mistake and that would be = rectified in the next version. (But I did mention RFC5439 in this = morning's presentation :)). Both RFC2961 and RFC5439 do talk about having a large refresh interval = as a means of reducing the rate of messages that the control-plane has = to process, but also warn about the loss of functionality associated = with doing so. brings back the = notion of refresh independent RSVP, but also includes recommendations = that would make sure that there is no loss of functionality when a large = refresh interval is used. Regards, -Pavan =20 =20 On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson wrote: Pavan, The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks" RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp- te-scaling. The topics seems close enough to make worth look at that document. /Loa On 2015-03-26 14:09, Vishnu Pavan Beeram wrote: https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01 Folks, Hi! was presented earlier today in the TEAS WG session. There wasn't sufficient time to take in questions at the end of the presentation (apologize for that). So, I'm opening up this thread to make sure that all those questions get answered. A few points to note: 1. These recommendations were put together for catering to current MPLS RSVP-TE Scalability needs. But since most of them have generic applicability, this draft is being discussed in TEAS. 2. There are 3 underlying principles driving these recommendations - Completely eliminate the reliance on refreshes for state sync. - Completely eliminate the reliance on refresh timeouts for stale state cleanup. - Implement per-peer flow control. 3. This is not a theoretical exercise. We have an implementation that religiously adopts these recommendations -- and the savings in terms of processing cycles for the control-plane (as a result of the significant reduction in I/O overhead) is quite significant. Please do give these recommendations some serious consideration and let us know your questions/comments. Regards, -Pavan (on behalf of the authors) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 = =20 =20 =20 =20 ------=_NextPart_000_03AB_01D06CB8.3FB8C3C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I'm doing this from memory - = someone might want to read an RFC.

 

3473 includes processing to = enable restart after a control pane communication failure. Fundamental = to that is LSP soft state does not time out when the session (hello = state) is down. That would probably be section = 9.

 

So "it all depends what = you mean".

 

Adrian

 

From: Teas = [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram
Sent: 01 April 2015 15:10
To: Pawe=C5=82 = Brzozowski
Cc: teas@ietf.org
Subject: Re: [Teas] = RSVP TE Scalability - = Recommendations

 

Pawel, = Hi!

There is no (AFAIK) GMPLS document that = recommends NOT cleaning up LSP state when refresh times out. So, the = point that you are making about these recommendations not being = applicable for GMPLS LSPs isn't quite true.

I do understand that = there are proprietary implementations out there that use some additional = procedures (after the refresh times out) to make sure that it is = absolutely safe to cleanup the data-plane before cleaning up the = corresponding LSP state. With the new recommendations proposed in = <draft-beeram..>, these implementations should still be able to = run similar procedures after the node-hello times out and then cleanup = the state. But since these are all proprietary mechanisms, this draft = will not spell all this out for you.

Regards,

-Pavan

 

On Wed, = Apr 1, 2015 at 8:48 AM, Pawe=C5=82 Brzozowski <PBrzozowski@advaoptical.com> = wrote:

Pavan,

 

you wrote:

 

=E2=80=9CVPB<=3D> = If the elements in this transport network of yours are running standard = GMPLS Control-Plane (not some GMPLS based proprietary version), please = elaborate why you can't couple the state of individual LSPs with the = state of the corresponding RSVP-TE signaling adjacency. If an = implementation can cleanup the LSP-state when the refresh times out, = then it should also be able to cleanup the LSP-state when the = hello-adjacency goes down. I understand that there are proprietary = implementations that do not cleanup the LSP-state when the refresh times = out -- those proprietary implementations might need some additional = procedures (this draft will not furnish those).=E2=80=9D

I guess this is where our disconnect comes = from. You certainly know RFCs better than me. I assumed that IETF = recommendation for GMPLS running in transport networks would be NOT to = cleanup lsp state when refreshes time out. Is it not the = case?

 

Thanks,

Pawel

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Wednesday, = April 01, 2015 12:13 AM
To: Pawe=C5=82 Brzozowski


Cc: teas@ietf.org
Subject: Re: [Teas] RSVP = TE Scalability - = Recommendations

 

Pawel, Hi!

Thanks for the response. Please see = inline.

Regards,

-Pavan

 

On Tue, Mar 31, 2015 at 5:30 = PM, Pawe=C5=82 Brzozowski <PBrzozowski@advaoptical.com> = wrote:

Pavan,

 

I think this is great work and applies well = to the packet networks. Imho the draft should be augmented to reflect to = what is the degree of applicability to transport networks.

 

VPB <=3D> As mentioned earlier, the = recommendations in the draft were put together to cater to MPLS RSVP-TE = LSPs. The authors didn't consider the applicability of these = recommendations to non-psc GMPLS LSPs at all in the initial revision -- = we simply didn't care :). But since it was pointed out to us that most = of these recommendations have generic applicability, I agree that it = would be useful to clarify the degree of applicability to such networks = in the next revision of the draft. At a high-level, everything except = Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert for Paths) and = Section 2.6 (there are different ways of checking data-plane readiness = for non psc LSPs) should have generic = applicability.

 

You said:

 

=E2=80=9CThere are 3 = underlying principles driving these recommendations:

- Completely eliminate = the reliance on refreshes for state sync.
- Completely eliminate the = reliance on refresh timeouts for stale state
cleanup.
- Implement = per-peer flow control.=E2=80=9D

 

In order to achieve these principles you = recommend =E2=80=9CImplementing coupling the state of individual LSPs = with the state of the corresponding RSVP-TE signaling = adjacency.=E2=80=9D (copied from the draft). Since in the transport = network you really shouldn=E2=80=99t do that, I=E2=80=99m interested how = you can fulfill above mentioned principles without it.

 

VPB<=3D> If the elements in this = transport network of yours are running standard GMPLS Control-Plane (not = some GMPLS based proprietary version), please elaborate why you can't = couple the state of individual LSPs with the state of the corresponding = RSVP-TE signaling adjacency. If an implementation can cleanup the = LSP-state when the refresh times out, then it should also be able to = cleanup the LSP-state when the hello-adjacency goes down. I understand = that there are proprietary implementations that do not cleanup the = LSP-state when the refresh times out -- those proprietary = implementations might need some additional procedures (this draft will = not furnish those).

To give an example:


Principle 2: = =E2=80=9CCompletely eliminate the reliance on refresh timeouts for stale = state=E2=80=9D

 

In the draft you assume that stale state will = be removed thanks to: a) reliable Tear/Err messages delivery and b) = removing of lsp state after adjacency loss. Since b) does not work in = transport, how can you cover scenarios involving a reboot of a RSVP = speaker while the service is torn down e.g. by PathTear?

 

 

VPB <=3D> Again, please = elaborate why you cannot remove LSP after adjacency loss if you are = using standard GMPLS RSVP-TE.  =
 

Thanks,

Pawel

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu = Pavan Beeram
Sent: Thursday, March 26, 2015 3:56 = PM
To: Loa Andersson
Cc: teas@ietf.org
Subject: Re: [Teas] RSVP = TE Scalability - Recommendations

 

Loa, = Hi!

Thanks for pointing it = out.

Yes, not referencing/mentioning RFC 5439 = was a mistake and that would be rectified in the next version. (But I = did mention RFC5439 in this morning's presentation = :)).

Both RFC2961 and RFC5439 do talk about = having a large refresh interval as a means of reducing the rate of = messages that the control-plane has to process, but also warn about the = loss of functionality associated with doing so. = <draft-beeram-mpls-rsvp-te-scaling> brings back the notion of = refresh independent RSVP, but also includes recommendations that would = make sure that there is no loss of functionality when a large refresh = interval is used.

Regards,

-Pavan

 

 

On Thu, Mar 26, 2015 at 3:31 = PM, Loa Andersson <loa@pi.nu> wrote:

Pavan,

The MPLS wg did = "An Analysis of Scaling Issues in MPLS-TE Core = Networks"
RFC 5439. This RFC is not mentioned in = draft-beeram-mpls-rsvp-
te-scaling. The topics seems close enough to = make worth look at = that
document.

/Loa





On 2015-03-26 = 14:09, Vishnu Pavan Beeram = wrote:

https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-s= caling-01

Folks, = Hi!

<draft-beeram-mpls-rsvp-te-scaling> was presented = earlier today in the
TEAS WG session. There wasn't sufficient time to = take in questions at
the end of the presentation (apologize for = that). So, I'm opening up
this thread to make sure that all those = questions get answered.

A few points to note:

1. These = recommendations were put together for catering to current = MPLS
RSVP-TE Scalability needs. But since most of them have = generic
applicability, this draft is being discussed in = TEAS.

2. There are 3 underlying principles driving these = recommendations
- Completely eliminate the reliance on refreshes for = state sync.
- Completely eliminate the reliance on refresh timeouts = for stale state
cleanup.
- Implement per-peer flow = control.

3. This is not a theoretical exercise. We have an = implementation that
religiously adopts these recommendations -- and = the savings in terms of
processing cycles for the control-plane (as a = result of the significant
reduction in I/O overhead) is quite = significant.

Please do give these recommendations some serious = consideration and let
us know your = questions/comments.

Regards,
-Pavan
(on behalf of the = authors)


__________________________________________= _____
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas


-- =


Loa Andersson            =             email: loa@mail01.huawei.com
Senior MPLS Expert  =                     =     loa@pi.nu
Huawei Technologies = (consultant)     phone: +46 739 81 21 = 64

 

 

 

------=_NextPart_000_03AB_01D06CB8.3FB8C3C0-- From nobody Wed Apr 1 13:35:12 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707561A909F for ; Wed, 1 Apr 2015 13:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_Yoii_5suA6 for ; Wed, 1 Apr 2015 13:35:06 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5DB1A90A0 for ; Wed, 1 Apr 2015 13:35:06 -0700 (PDT) Received: by qcbii10 with SMTP id ii10so29107752qcb.2 for ; Wed, 01 Apr 2015 13:35:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8uwpiCxpnwN/3IXoyMTXOCkRRHjU3gBOkIJfGiCgRKc=; b=FQLdaACAImTLoYhy4lUSw8aiRoCLIxoYa1piHl6a7TCFd+gl/3CWz26C3e0JKd61vH PqMsllIyAEb2zSsKrNS3XizsQ94lqO51TWM2XZgtEbQ4zWvnzLmDmtleSKZv1jr1IKJO BMKr1z7n9o92Z+9oZ6YFgjLwgb4iiabS7K7vbJboKyOumMMBxH8bolaOT0ZvcMeYi9eR FOfJVX0rdflfjh8ROfI8sIL/CJJGNWxqF8syp49gORGOCpJy174v1CIFSenwz1S3jvwv Vp0usmASk6vIZ2Mhez9wzsrhURcYDtwRK2eukWiEAGxH7Ob/YYJWV79rPGp66erzcsRg nCbw== MIME-Version: 1.0 X-Received: by 10.140.21.233 with SMTP id 96mr12682229qgl.78.1427920505591; Wed, 01 Apr 2015 13:35:05 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Wed, 1 Apr 2015 13:35:05 -0700 (PDT) In-Reply-To: <03aa01d06caf$dd9069d0$98b13d70$@olddog.co.uk> References: <55145EA1.3010905@pi.nu> <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> <03aa01d06caf$dd9069d0$98b13d70$@olddog.co.uk> Date: Wed, 1 Apr 2015 16:35:05 -0400 Message-ID: From: Vishnu Pavan Beeram To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a11c157a480dd0f0512afa6c1 Archived-At: Cc: =?UTF-8?Q?Pawe=C5=82_Brzozowski?= , "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 20:35:11 -0000 --001a11c157a480dd0f0512afa6c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adrian, Hi! First, a quick clarification on how/if these recommendations impact the "Graceful Restart" procedures: - The "LSP state cleanup upon node-hello timeout" recommendation made in does NOT impact the RSVP-TE graceful restart procedures defined in ([RFC3473], [RFC5063]). If the node is not acting as a "graceful-restart" helper, it would cleanup state immediately upon node-hello timeout. But if the node is acting as a graceful-restart helper for a neighboring node, then the "cleanup" action will be executed only after taking into account the grace period extended for the neighbor by the helper. I checked Section 9 of RFC3473 again. Section 9.3 says the following: 9.3 . Modification to Hello Processing to Support State Recovery When a node determines that RSVP communication with a neighbor has been lost, and the node previously learned that the neighbor supports state recovery, the node SHOULD wait at least the amount of time indicated by the Restart Time indicated by the neighbor before invoking procedures related to communication loss. A node MAY wait a different amount of time based on local policy or configuration information. Was this the text that you were thinking of? The text in 9.3 is in line with the clarification that I gave above. Regards, -Pavan On Wed, Apr 1, 2015 at 3:12 PM, Adrian Farrel wrote: > I'm doing this from memory - someone might want to read an RFC. > > > > 3473 includes processing to enable restart after a control pane > communication failure. Fundamental to that is LSP soft state does not tim= e > out when the session (hello state) is down. That would probably be sectio= n > 9. > > > > So "it all depends what you mean". > > > > Adrian > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Vishnu Pavan > Beeram > *Sent:* 01 April 2015 15:10 > > *To:* Pawe=C5=82 Brzozowski > *Cc:* teas@ietf.org > *Subject:* Re: [Teas] RSVP TE Scalability - Recommendations > > > > Pawel, Hi! > > There is no (AFAIK) GMPLS document that recommends NOT cleaning up LSP > state when refresh times out. So, the point that you are making about the= se > recommendations not being applicable for GMPLS LSPs isn't quite true. > > I do understand that there are proprietary implementations out there that > use some additional procedures (after the refresh times out) to make sure > that it is absolutely safe to cleanup the data-plane before cleaning up t= he > corresponding LSP state. With the new recommendations proposed in > , these implementations should still be able to run simil= ar > procedures after the node-hello times out and then cleanup the state. But > since these are all proprietary mechanisms, this draft will not spell all > this out for you. > > Regards, > > -Pavan > > > > On Wed, Apr 1, 2015 at 8:48 AM, Pawe=C5=82 Brzozowski < > PBrzozowski@advaoptical.com> wrote: > > Pavan, > > > > you wrote: > > > > *=E2=80=9CVPB<=3D> If the elements in this transport network of yours are= running > standard GMPLS Control-Plane (not some GMPLS based proprietary version), > please elaborate why you can't couple the state of individual LSPs with t= he > state of the corresponding RSVP-TE signaling adjacency. If an > implementation can cleanup the LSP-state when the refresh times out, then > it should also be able to cleanup the LSP-state when the hello-adjacency > goes down. I understand that there are proprietary implementations that d= o > not cleanup the LSP-state when the refresh times out -- those proprietary > implementations might need some additional procedures (this draft will no= t > furnish those).=E2=80=9D* > > I guess this is where our disconnect comes from. You certainly know RFCs > better than me. I assumed that IETF recommendation for GMPLS running in > transport networks would be NOT to cleanup lsp state when refreshes time > out. Is it not the case? > > > > Thanks, > > Pawel > > > > *From:* Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] > *Sent:* Wednesday, April 01, 2015 12:13 AM > *To:* Pawe=C5=82 Brzozowski > > > *Cc:* teas@ietf.org > *Subject:* Re: [Teas] RSVP TE Scalability - Recommendations > > > > Pawel, Hi! > > Thanks for the response. Please see inline. > > Regards, > > -Pavan > > > > On Tue, Mar 31, 2015 at 5:30 PM, Pawe=C5=82 Brzozowski < > PBrzozowski@advaoptical.com> wrote: > > Pavan, > > > > I think this is great work and applies well to the packet networks. Imho > the draft should be augmented to reflect to what is the degree of > applicability to transport networks. > > > > VPB <=3D> As mentioned earlier, the recommendations in the draft were put > together to cater to MPLS RSVP-TE LSPs. The authors didn't consider the > applicability of these recommendations to non-psc GMPLS LSPs at all in th= e > initial revision -- we simply didn't care :). But since it was pointed ou= t > to us that most of these recommendations have generic applicability, I > agree that it would be useful to clarify the degree of applicability to > such networks in the next revision of the draft. At a high-level, > everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert > for Paths) and Section 2.6 (there are different ways of checking data-pla= ne > readiness for non psc LSPs) should have generic applicability. > > > > You said: > > > > *=E2=80=9CThere are 3 underlying principles driving these recommendations= :* > > > > > *- Completely eliminate the reliance on refreshes for state sync.- > Completely eliminate the reliance on refresh timeouts for stale > statecleanup.- Implement per-peer flow control.=E2=80=9D* > > > > In order to achieve these principles you recommend =E2=80=9C*Implementing > coupling the state of individual LSPs with the state of the corresponding > RSVP-TE signaling adjacency.*=E2=80=9D (copied from the draft). Since in = the > transport network you really shouldn=E2=80=99t do that, I=E2=80=99m inter= ested how you can > fulfill above mentioned principles without it. > > > > VPB<=3D> If the elements in this transport network of yours are running > standard GMPLS Control-Plane (not some GMPLS based proprietary version), > please elaborate why you can't couple the state of individual LSPs with t= he > state of the corresponding RSVP-TE signaling adjacency. If an > implementation can cleanup the LSP-state when the refresh times out, then > it should also be able to cleanup the LSP-state when the hello-adjacency > goes down. I understand that there are proprietary implementations that d= o > not cleanup the LSP-state when the refresh times out -- those proprietary > implementations might need some additional procedures (this draft will no= t > furnish those). > > To give an example: > > > *Principle 2: =E2=80=9CCompletely eliminate the reliance on refresh timeo= uts for > stale state=E2=80=9D* > > > > In the draft you assume that stale state will be removed thanks to: a) > reliable Tear/Err messages delivery and b) removing of lsp state after > adjacency loss. Since b) does not work in transport, how can you cover > scenarios involving a reboot of a RSVP speaker while the service is torn > down e.g. by PathTear? > > > > > > VPB <=3D> Again, please elaborate why you cannot remove LSP after adjacen= cy > loss if you are using standard GMPLS RSVP-TE. > > > Thanks, > > Pawel > > > > > > *From:* Teas [mailto:teas-bounces@ietf.org] *On Behalf Of *Vishnu Pavan > Beeram > *Sent:* Thursday, March 26, 2015 3:56 PM > *To:* Loa Andersson > *Cc:* teas@ietf.org > *Subject:* Re: [Teas] RSVP TE Scalability - Recommendations > > > > Loa, Hi! > > Thanks for pointing it out. > > Yes, not referencing/mentioning RFC 5439 was a mistake and that would be > rectified in the next version. (But I did mention RFC5439 in this morning= 's > presentation :)). > > Both RFC2961 and RFC5439 do talk about having a large refresh interval as > a means of reducing the rate of messages that the control-plane has to > process, but also warn about the loss of functionality associated with > doing so. brings back the notion of > refresh independent RSVP, but also includes recommendations that would ma= ke > sure that there is no loss of functionality when a large refresh interval > is used. > > Regards, > > -Pavan > > > > > > On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson wrote: > > Pavan, > > The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks" > RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp- > te-scaling. The topics seems close enough to make worth look at that > document. > > /Loa > > > > > > On 2015-03-26 14:09, Vishnu Pavan Beeram wrote: > > https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01 > > Folks, Hi! > > was presented earlier today in the > TEAS WG session. There wasn't sufficient time to take in questions at > the end of the presentation (apologize for that). So, I'm opening up > this thread to make sure that all those questions get answered. > > A few points to note: > > 1. These recommendations were put together for catering to current MPLS > RSVP-TE Scalability needs. But since most of them have generic > applicability, this draft is being discussed in TEAS. > > 2. There are 3 underlying principles driving these recommendations > - Completely eliminate the reliance on refreshes for state sync. > - Completely eliminate the reliance on refresh timeouts for stale state > cleanup. > - Implement per-peer flow control. > > 3. This is not a theoretical exercise. We have an implementation that > religiously adopts these recommendations -- and the savings in terms of > processing cycles for the control-plane (as a result of the significant > reduction in I/O overhead) is quite significant. > > Please do give these recommendations some serious consideration and let > us know your questions/comments. > > Regards, > -Pavan > (on behalf of the authors) > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > > > --001a11c157a480dd0f0512afa6c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adrian, Hi!

First, a quick cla= rification on how/if these recommendations impact the "Graceful Restar= t" procedures:
- The "LSP sta= te cleanup upon node-hello timeout" recommendation made in <draft-b= eeram..> does NOT impact the RSVP-TE graceful restart procedures defined= in ([RFC3473], [RFC5063]).=C2=A0 If the node is not acting as a "grac= eful-restart" helper, it would cleanup state immediately upon node-hel= lo timeout. But if the node is acting as a graceful-restart helper for a ne= ighboring node, then the "cleanup" action will be executed only a= fter taking into account the grace period extended for the neighbor by the = helper.

I checked Section 9 of RFC3473 again.=C2=A0 Section 9= .3 says the following:
9.3. Modification to Hello Processing to Support State Recovery   When a node determines that RSVP communication with a neighbor =
has
   been lost, and the node previously learned that the neighbor supports
   state recovery, the node SHOULD wait at least the amount of time
   indicated by the Restart Time indicated by the neighbor before
   invoking procedures related to communication loss.  A node MAY wait a
   different amount of time based on local policy or configuration
   information.
Was this the text that you were thinking of? The text = in 9.3 is in line with the clarification that I gave above.

Regards,
-Pavan

On Wed, Apr 1, 2015 at 3:12 PM= , Adrian Farrel <adrian@olddog.co.uk> wrote:

I'm doing this from memory - someone might want to read an RFC.=

=C2=A0

3473 includes processing to enable restart after a control pane co= mmunication failure. Fundamental to that is LSP soft state does not time ou= t when the session (hello state) is down. That would probably be section 9.=

=C2=A0

So "it all depends what you mean".<= /span>

=C2= =A0

Adrian

=C2=A0

From: Teas [mailto:teas-bounces@ietf.org] O= n Behalf Of Vishnu Pavan Beeram
Sent: 01 April 2015 15:10


To: Pawe=C5=82 Brzozowski
Cc= : teas@ietf.org<= br>Subject: Re: [Teas] RSVP TE Scalability - Recommendations<= u>

=C2=A0

Pawel, Hi!

There is no (AFAIK) GMPLS document = that recommends NOT cleaning up LSP state when refresh times out. So, the p= oint that you are making about these recommendations not being applicable f= or GMPLS LSPs isn't quite true.

I do understand that there are p= roprietary implementations out there that use some additional procedures (a= fter the refresh times out) to make sure that it is absolutely safe to clea= nup the data-plane before cleaning up the corresponding LSP state. With the= new recommendations proposed in <draft-beeram..>, these implementati= ons should still be able to run similar procedures after the node-hello tim= es out and then cleanup the state. But since these are all proprietary mech= anisms, this draft will not spell all this out for you.

Regards,

-Pavan

<= u>=C2=A0

On Wed, Apr 1, 2015 at 8= :48 AM, Pawe=C5=82 Brzozowski <PBrzozowski@advaoptical.com> wrote:

Pavan,

=C2=A0

you wrote:<= /u>

=C2=A0

= =E2=80=9CVPB<=3D> If the elements in this transport network of yours = are running standard GMPLS Control-Plane (not some GMPLS based proprietary = version), please elaborate why you can't couple the state of individual= LSPs with the state of the corresponding RSVP-TE signaling adjacency. If a= n implementation can cleanup the LSP-state when the refresh times out, then= it should also be able to cleanup the LSP-state when the hello-adjacency g= oes down. I understand that there are proprietary implementations that do n= ot cleanup the LSP-state when the refresh times out -- those proprietary im= plementations might need some additional procedures (this draft will not fu= rnish those).=E2=80=9D

I gu= ess this is where our disconnect comes from. You certainly know RFCs better= than me. I assumed that IETF recommendation for GMPLS running in transport= networks would be NOT to cleanup lsp state when refreshes time out. Is it = not the case?

=C2=A0

Thanks,=

Pawel

=C2=A0

From: Vishnu Pavan = Beeram [mailto:v= ishnupavan@gmail.com]
Sent: Wednesday, April 01, 2015 12:13 = AM
To: Pawe=C5=82 Brzozowski


Cc:<= /b> teas@ietf.orgSubject: Re: [Teas] RSVP TE Scalability - Recommendations=

=C2=A0

Pawel, Hi!

Thanks for the response. Please see inline.<= /p>

Regards,

-Pavan=

=C2=A0

On Tue, Mar 31, 2015 at 5:30 PM, Pawe=C5=82 Brzozowski <PBrzozowski@advaoptica= l.com> wrote:

Pavan,

=C2=A0

I th= ink this is great work and applies well to the packet networks. Imho the dr= aft should be augmented to reflect to what is the degree of applicability t= o transport networks.

=C2=A0<= /span>

VPB <=3D> As mentioned earlier, the recommendations i= n the draft were put together to cater to MPLS RSVP-TE LSPs. The authors di= dn't consider the applicability of these recommendations to non-psc GMP= LS LSPs at all in the initial revision -- we simply didn't care :). But= since it was pointed out to us that most of these recommendations have gen= eric applicability, I agree that it would be useful to clarify the degree o= f applicability to such networks in the next revision of the draft. At a hi= gh-level, everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Rout= er-Alert for Paths) and Section 2.6 (there are different ways of checking d= ata-plane readiness for non psc LSPs) should have generic applicability.=

=C2=A0=

You said:

=C2=A0

= =E2=80=9CThere are 3 underlying principles driving these recommendations:

= - Completely eliminate the reliance on refreshes fo= r state sync.
- Completely eliminate the reliance on refresh timeouts fo= r stale state
cleanup.
- Implement per-peer flow control.=E2=80=9D

<= span style=3D"font-size:11pt;font-family:"Calibri","sans-ser= if";color:rgb(31,73,125)" lang=3D"EN-US">=C2=A0

In order to achieve these principles you recommend = =E2=80=9CImplementing coupling the state of individual LSPs with the sta= te of the corresponding RSVP-TE signaling adjacency.=E2=80=9D (copied f= rom the draft). Since in the transport network you really shouldn=E2=80=99t= do that, I=E2=80=99m interested how you can fulfill above mentioned princi= ples without it.

=C2=A0

VPB<=3D> If the elements in this transport n= etwork of yours are running standard GMPLS Control-Plane (not some GMPLS ba= sed proprietary version), please elaborate why you can't couple the sta= te of individual LSPs with the state of the corresponding RSVP-TE signaling= adjacency. If an implementation can cleanup the LSP-state when the refresh= times out, then it should also be able to cleanup the LSP-state when the h= ello-adjacency goes down. I understand that there are proprietary implement= ations that do not cleanup the LSP-state when the refresh times out -- thos= e proprietary implementations might need some additional procedures (this d= raft will not furnish those).

To= give an example:


Principle 2: =E2=80=9CCompletely= eliminate the reliance on refresh timeouts for stale state=E2=80=9D=

=C2=A0

In the draft you assume that stale state will be removed = thanks to: a) reliable Tear/Err messages delivery and b) removing of lsp st= ate after adjacency loss. Since b) does not work in transport, how can you = cover scenarios involving a reboot of a RSVP speaker while the service is t= orn down e.g. by PathTear?

=C2= =A0

=C2=A0

VPB <=3D> Ag= ain, please elaborate why you cannot remove LSP after adjacency loss if you= are using standard GMPLS RSVP-TE.=C2=A0
=C2=A0

Thanks,

Paw= el

= =C2=A0

=C2=A0=

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pa= van Beeram
Sent: Thursday, March 26, 2015 3:56 PM
To: L= oa Andersson
Cc: teas@ietf.org
Subject: Re: [Teas] RSVP TE Scalability - Re= commendations

=C2=A0

=

Loa, Hi!

Thanks for pointing i= t out.

Yes, not referencing/mentioning RFC 5439 wa= s a mistake and that would be rectified in the next version. (But I did men= tion RFC5439 in this morning's presentation :)).

Both RFC2961 and RFC5439 do talk about having a large refresh interval a= s a means of reducing the rate of messages that the control-plane has to pr= ocess, but also warn about the loss of functionality associated with doing = so. <draft-beeram-mpls-rsvp-te-scaling> brings back the notion of ref= resh independent RSVP, but also includes recommendations that would make su= re that there is no loss of functionality when a large refresh interval is = used.

Regards,

-Pavan

=C2=A0

=

=C2=A0

On Thu, Mar 26, 2015 at 3:3= 1 PM, Loa Andersson <loa@= pi.nu> wrote:

Pavan,

The MPLS wg did "An Analysis of Scaling Issue= s in MPLS-TE Core Networks"
RFC 5439. This RFC is not mentioned in = draft-beeram-mpls-rsvp-
te-scaling. The topics seems close enough to mak= e worth look at that
document.

/Loa

=





On 2015-03-26= 14:09, Vishnu Pavan Beeram wrote:

https://tools.ietf.org/html/draft-beeram-mpls-= rsvp-te-scaling-01

Folks, Hi!

<draft-beeram-mpls-rsvp-= te-scaling> was presented earlier today in the
TEAS WG session. There= wasn't sufficient time to take in questions at
the end of the prese= ntation (apologize for that). So, I'm opening up
this thread to make= sure that all those questions get answered.

A few points to note:
1. These recommendations were put together for catering to current MP= LS
RSVP-TE Scalability needs. But since most of them have generic
app= licability, this draft is being discussed in TEAS.

2. There are 3 un= derlying principles driving these recommendations
- Completely eliminate= the reliance on refreshes for state sync.
- Completely eliminate the re= liance on refresh timeouts for stale state
cleanup.
- Implement per-p= eer flow control.

3. This is not a theoretical exercise. We have an = implementation that
religiously adopts these recommendations -- and the = savings in terms of
processing cycles for the control-plane (as a result= of the significant
reduction in I/O overhead) is quite significant.
=
Please do give these recommendations some serious consideration and let=
us know your questions/comments.

Regards,
-Pavan
(on behal= f of the authors)


<= /div>

= _______________________________________________
Teas mailing list
Teas@ietf.org
https://= www.ietf.org/mailman/listinfo/teas

=
--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS E= xpert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 loa@pi.= nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739 81 21 64=

=C2=A0

=C2=A0<= u>

=C2=A0

<= /div>

--001a11c157a480dd0f0512afa6c1-- From nobody Thu Apr 2 01:24:51 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350231B2BF2 for ; Thu, 2 Apr 2015 01:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNxbdXBhkD8s for ; Thu, 2 Apr 2015 01:24:44 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB211B2BE8 for ; Thu, 2 Apr 2015 01:24:43 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 4D686CAE943A0 for ; Thu, 2 Apr 2015 08:24:38 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t328OaEK024775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Apr 2015 10:24:37 +0200 Received: from [149.204.107.61] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 2 Apr 2015 10:24:37 +0200 Message-ID: <551CFCC3.3010606@alcatel-lucent.com> Date: Thu, 2 Apr 2015 10:24:35 +0200 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Vishnu Pavan Beeram References: <55145EA1.3010905@pi.nu> <0fe4c449812b4174b42aacbdcf10a8a5@MUC-S-EX13B.advaoptical.com> <79bd84a38c964717a963da3223359266@MUC-S-EX13B.advaoptical.com> <551BF98E.9050102@alcatel-lucent.com> In-Reply-To: Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] Archived-At: Cc: "teas@ietf.org" Subject: Re: [Teas] RSVP TE Scalability - Recommendations X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 08:24:48 -0000 Hi Pavan, all,

I agree with you that when a new draft is being developed in TEAS it should be applicable to all technologies including non-psc GMPLS.

However, if we figure out that an issue is very much technology specific, we may decide to develop a techno-specific I-D that will be
done in MPLS for example when it only applies to classical MPLS (psc).

Another aspect is compatibility of new mechanisms with implementations based on existing RFCs. So, I would expect a compatibility
section addressing backward compatibility and seamless introduction of new mechanisms or extensions into existing networks.


Thanks,
Dieter


On 01.04.2015 16:59, Vishnu Pavan Beeram wrote:
Dieter, Hi!

Please see inline..

Regards,
-Pavan

On Wed, Apr 1, 2015 at 9:58 AM, Dieter Beller <Dieter.Beller@alcatel-lucent.com> wrote:
Hi all,

two comments regarding the usage of RSVP in GMPLS enabled transport networks:
  1. In my view, RSVP requires LSP state cleanup in case of RSVP refresh timeouts (soft state protocol) - you may, however, suspend
    the refresh mechanism in case your signalling communication is broken while your data plane is working properly.

  1. RSVP-TE scalability may not be an issue in GMPLS enabled transport networks due to the fact that we have a limited number of
    LSPs per link (corresponding to the number of circuits per link)

 
[VPB] Totally agree that the scaling requirements imposed on MPLS RSVP-TE LSPs are very different from those imposed on non-psc RSVP-TE LSPs. The recommendations in this draft were put together to cater to the former set of requirements (and that would continue to be the primary focus of this draft). But one of the initial points that was made to us when we came out with this draft was that most of these recommendations are applicable to non-psc GMPLS LSPs as well -- and I don't think there is an argument against that statement (irrespective of whether "Scalability" is a current concern or not for GMPLS-enabled LSPs).

 
Thanks,
Dieter


On 01.04.2015 14:48, Paweł Brzozowski wrote:

Pavan,

 

you wrote:

 

“VPB<=> If the elements in this transport network of yours are running standard GMPLS Control-Plane (not some GMPLS based proprietary version), please elaborate why you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. If an implementation can cleanup the LSP-state when the refresh times out, then it should also be able to cleanup the LSP-state when the hello-adjacency goes down. I understand that there are proprietary implementations that do not cleanup the LSP-state when the refresh times out -- those proprietary implementations might need some additional procedures (this draft will not furnish those).”

I guess this is where our disconnect comes from. You certainly know RFCs better than me. I assumed that IETF recommendation for GMPLS running in transport networks would be NOT to cleanup lsp state when refreshes time out. Is it not the case?

 

Thanks,

Pawel

 

From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
Sent: Wednesday, April 01, 2015 12:13 AM
To: Paweł Brzozowski
Cc: teas@ietf.org
Subject: Re: [Teas] RSVP TE Scalability - Recommendations

 

Pawel, Hi!

Thanks for the response. Please see inline.

Regards,

-Pavan

 

On Tue, Mar 31, 2015 at 5:30 PM, Paweł Brzozowski <PBrzozowski@advaoptical.com> wrote:

Pavan,

 

I think this is great work and applies well to the packet networks. Imho the draft should be augmented to reflect to what is the degree of applicability to transport networks.

 

VPB <=> As mentioned earlier, the recommendations in the draft were put together to cater to MPLS RSVP-TE LSPs. The authors didn't consider the applicability of these recommendations to non-psc GMPLS LSPs at all in the initial revision -- we simply didn't care :). But since it was pointed out to us that most of these recommendations have generic applicability, I agree that it would be useful to clarify the degree of applicability to such networks in the next revision of the draft. At a high-level, everything except Section 2.5 (GMPLS RSVP-TE LSPs do not use Router-Alert for Paths) and Section 2.6 (there are different ways of checking data-plane readiness for non psc LSPs) should have generic applicability.

 

You said:

 

“There are 3 underlying principles driving these recommendations:

- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.”

 

In order to achieve these principles you recommend “Implementing coupling the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency.” (copied from the draft). Since in the transport network you really shouldn’t do that, I’m interested how you can fulfill above mentioned principles without it.

 

VPB<=> If the elements in this transport network of yours are running standard GMPLS Control-Plane (not some GMPLS based proprietary version), please elaborate why you can't couple the state of individual LSPs with the state of the corresponding RSVP-TE signaling adjacency. If an implementation can cleanup the LSP-state when the refresh times out, then it should also be able to cleanup the LSP-state when the hello-adjacency goes down. I understand that there are proprietary implementations that do not cleanup the LSP-state when the refresh times out -- those proprietary implementations might need some additional procedures (this draft will not furnish those).

To give an example:


Principle 2: “Completely eliminate the reliance on refresh timeouts for stale state”

 

In the draft you assume that stale state will be removed thanks to: a) reliable Tear/Err messages delivery and b) removing of lsp state after adjacency loss. Since b) does not work in transport, how can you cover scenarios involving a reboot of a RSVP speaker while the service is torn down e.g. by PathTear?

 

 

VPB <=> Again, please elaborate why you cannot remove LSP after adjacency loss if you are using standard GMPLS RSVP-TE. 
 

Thanks,

Pawel

 

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Thursday, March 26, 2015 3:56 PM
To: Loa Andersson
Cc: teas@ietf.org
Subject: Re: [Teas] RSVP TE Scalability - Recommendations

 

Loa, Hi!

Thanks for pointing it out.

Yes, not referencing/mentioning RFC 5439 was a mistake and that would be rectified in the next version. (But I did mention RFC5439 in this morning's presentation :)).

Both RFC2961 and RFC5439 do talk about having a large refresh interval as a means of reducing the rate of messages that the control-plane has to process, but also warn about the loss of functionality associated with doing so. <draft-beeram-mpls-rsvp-te-scaling> brings back the notion of refresh independent RSVP, but also includes recommendations that would make sure that there is no loss of functionality when a large refresh interval is used.

Regards,

-Pavan

 

 

On Thu, Mar 26, 2015 at 3:31 PM, Loa Andersson <loa@pi.nu> wrote:

Pavan,

The MPLS wg did "An Analysis of Scaling Issues in MPLS-TE Core Networks"
RFC 5439. This RFC is not mentioned in draft-beeram-mpls-rsvp-
te-scaling. The topics seems close enough to make worth look at that
document.

/Loa





On 2015-03-26 14:09, Vishnu Pavan Beeram wrote:

https://tools.ietf.org/html/draft-beeram-mpls-rsvp-te-scaling-01

Folks, Hi!

<draft-beeram-mpls-rsvp-te-scaling> was presented earlier today in the
TEAS WG session. There wasn't sufficient time to take in questions at
the end of the presentation (apologize for that). So, I'm opening up
this thread to make sure that all those questions get answered.

A few points to note:

1. These recommendations were put together for catering to current MPLS
RSVP-TE Scalability needs. But since most of them have generic
applicability, this draft is being discussed in TEAS.

2. There are 3 underlying principles driving these recommendations
- Completely eliminate the reliance on refreshes for state sync.
- Completely eliminate the reliance on refresh timeouts for stale state
cleanup.
- Implement per-peer flow control.

3. This is not a theoretical exercise. We have an implementation that
religiously adopts these recommendations -- and the savings in terms of
processing cycles for the control-plane (as a result of the significant
reduction in I/O overhead) is quite significant.

Please do give these recommendations some serious consideration and let
us know your questions/comments.

Regards,
-Pavan
(on behalf of the authors)



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas


--


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

 

 



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas




_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
From nobody Mon Apr 6 08:45:06 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D5E1A8A64 for ; Mon, 6 Apr 2015 08:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBClDIo4FRpm for ; Mon, 6 Apr 2015 08:44:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340001A8A57 for ; Mon, 6 Apr 2015 08:44:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRC16357; Mon, 06 Apr 2015 15:44:51 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Apr 2015 16:44:49 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML702-CHM.china.huawei.com ([169.254.4.237]) with mapi id 14.03.0158.001; Mon, 6 Apr 2015 08:44:45 -0700 From: Huaimo Chen To: "adrian@olddog.co.uk" , "teas@ietf.org" Thread-Topic: [Teas] Thought on draft-chen-teas-rsvp-ttz Thread-Index: AdBn4lyZAX8YC5BgQjCBQ1zfWtK9OgImnnuA Date: Mon, 6 Apr 2015 15:44:44 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E37DABC@SJCEML701-CHM.china.huawei.com> References: <020b01d067e2$654561a0$2fd024e0$@olddog.co.uk> In-Reply-To: <020b01d067e2$654561a0$2fd024e0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.180] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E37DABCSJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] Thought on draft-chen-teas-rsvp-ttz X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 15:44:59 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E37DABCSJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian, Thanks much for your comments. We are not going to propose a second or any new architecture. We will d= escribe our work in the context of draft-ietf-teas-interconnected-te-info-e= xchange. Best Regards, Huaimo -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, March 26, 2015 12:32 PM To: teas@ietf.org Subject: [Teas] Thought on draft-chen-teas-rsvp-ttz Hi, I'd really like to see this work described in the context of draft-ietf-tea= s-interconnected-te-info-exchange I want to understand whether you are proposing a second architecture or som= ething that develops from our existing architecture. Thanks, Adrian _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_5316A0AB3C851246A7CA5758973207D44E37DABCSJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
 
    Thanks much for your comments.
    We are not going to propose a second or any new arc= hitecture. We will describe our work in the context of draft-ietf-teas-inte= rconnected-te-info-exchange.
 
Best Regards,
Huaimo
-= ----Original Message-----
From: Teas [mailto:teas-bounces@ie= tf.org] On Behalf Of Adrian Farrel
Sent: Thursday, March 26, 2015 12:32 PM
To: teas@ietf.org
Subject: [Teas] Thought on draft-chen-teas-rsvp-ttz
 
H= i,
&= nbsp;
I= 'd really like to see this work described in the context of draft-ietf-teas= -interconnected-te-info-exchange
&= nbsp;
I= want to understand whether you are proposing a second architecture or some= thing that develops from our existing architecture.
&= nbsp;
T= hanks,
A= drian
&= nbsp;
_= ______________________________________________
T= eas mailing list
 
 --_000_5316A0AB3C851246A7CA5758973207D44E37DABCSJCEML701CHMchi_-- From nobody Mon Apr 6 09:34:41 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A001A8912; Mon, 6 Apr 2015 09:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5eUT39tx0vt; Mon, 6 Apr 2015 09:34:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F216F1A89AA; Mon, 6 Apr 2015 09:34:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUN69758; Mon, 06 Apr 2015 16:34:13 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Apr 2015 17:34:12 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Mon, 6 Apr 2015 09:34:09 -0700 From: Leeyoung To: "TEAS WG (teas@ietf.org)" , "actn@ietf.org" Thread-Topic: New Version Notification for draft-actn-requirement-02.txt Thread-Index: AQHQcIbDWzUGFJy5/0i2uqZfGK03D51ALJWA Date: Mon, 6 Apr 2015 16:34:08 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729CACB95@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.193] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Teas] FW: New Version Notification for draft-actn-requirement-02.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 16:34:39 -0000 SGksDQoNCkFDVE4gcmVxdWlyZW1lbnQgaGFzIGJlZW4gdXBkYXRlZCBhcyBwYXJ0IG9mIGFuIGFj dGlvbiBpdGVtIGZyb20gdGhlIFRFQVMgV0cgbWVldGluZyBpbiBEYWxsYXMuIA0KDQpXZSBoYXZl IGFkZGVkIGEgaGlnaC1sZXZlbCByZXF1aXJlbWVudCBzZWN0aW9uIHVwZnJvbnQgaW4gU2VjdGlv biAyIHRoYXQgaW5jbHVkZXMgd2hhdCB3YXMgcHJlc2VudGVkIGR1cmluZyB0aGUgbWVldGluZyBp biBhIFBQVCBmb3JtIGFuZCBvbmUgYWRkaXRpb25hbCBjbGFyaWZ5aW5nIHJlcXVpcmVtZW50IHRo YXQgQUNUTiBuZWVkcyB0byBzdXBwb3J0ICJEeW5hbWljaXR5IG9mIG5ldHdvcmsgY29udHJvbCBv cGVyYXRpb25zIiAoUmVxdWlyZW1lbnQgIzExKSBpbiBTZWN0aW9uIDIuDQoNClJlZ2FyZHMsDQpZ b3VuZyAob24gYmVoYWxmIG9mIG90aGVyIGNvLWF1dGhvcnMpDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBBcHJpbCAwNiwgMjAxNSAxMToyOSBB TQ0KVG86IERhbmllbGUgQ2VjY2FyZWxsaTsgTGVleW91bmc7IEtodXplbWEgUGl0aGV3YW47IERh bmllbGUgQ2VjY2FyZWxsaTsgTGVleW91bmc7IFNlcmdpbyBCZWxvdHRpOyBLaHV6ZW1hIFBpdGhl d2FuOyBTZXJnaW8gQmVsb3R0aQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1hY3RuLXJlcXVpcmVtZW50LTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1hY3RuLXJlcXVpcmVtZW50LTAyLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFlvdW5nIExlZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoN Ck5hbWU6CQlkcmFmdC1hY3RuLXJlcXVpcmVtZW50DQpSZXZpc2lvbjoJMDINClRpdGxlOgkJUmVx dWlyZW1lbnRzIGZvciBBYnN0cmFjdGlvbiBhbmQgQ29udHJvbCBvZiBUcmFuc3BvcnQgTmV0d29y a3MNCkRvY3VtZW50IGRhdGU6CTIwMTUtMDQtMDYNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQpQYWdlczoJCTI5DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtYWN0bi1yZXF1aXJlbWVudC0wMi50eHQNClN0YXR1czogICAgICAg ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hY3RuLXJlcXVpcmVtZW50 Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFjdG4t cmVxdWlyZW1lbnQtMDINCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1hY3RuLXJlcXVpcmVtZW50LTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBk cmFmdCBwcm92aWRlcyBhIHNldCBvZiByZXF1aXJlbWVudHMgZm9yIGFic3RyYWN0aW9uIGFuZA0K ICAgY29udHJvbCBvZiB0cmFuc3BvcnQgbmV0d29ya3MuDQoNCg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Apr 8 10:44:23 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496711A87B2 for ; Wed, 8 Apr 2015 10:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TflyG8jCggee for ; Wed, 8 Apr 2015 10:44:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D1B1A87AD for ; Wed, 8 Apr 2015 10:44:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRE45709; Wed, 08 Apr 2015 17:44:19 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Apr 2015 18:44:18 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 8 Apr 2015 10:44:13 -0700 From: Leeyoung To: "TEAS WG (teas@ietf.org)" Thread-Topic: New Version Notification for draft-lee-teas-actn-requirements-00.txt Thread-Index: AQHQciLEA98pWy3Lu0KSJ7Tf0RbYl51DYueg Date: Wed, 8 Apr 2015 17:44:12 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729CAE56F@dfweml706-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.193] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Teas] FW: New Version Notification for draft-lee-teas-actn-requirements-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 17:44:22 -0000 SGksIA0KDQpIZXJlJ3MgdGhlIEFDVE4gcmVxdWlyZW1lbnRzIGRyYWZ0IHVwbG9hZGVkLiBUaGlz IHVwZGF0ZSBpbmNvcnBvcmF0ZWQgY29tbWVudHMgZnJvbSB0aGUgV0cgbWVldGluZyBpbiBEYWxs YXMuIA0KDQoNClRoYW5rcywNCllvdW5nIChvbiBiZWhhbGYgb2YgY28tYXV0aG9ycykNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIEFwcmls IDA4LCAyMDE1IDEyOjM4IFBNDQpUbzogRGFuaWVsZSBDZWNjYXJlbGxpOyBEaHJ1diBEaG9keTsg TGVleW91bmc7IEtodXplbWEgUGl0aGV3YW47IERhbmllbGUgQ2VjY2FyZWxsaTsgRGhydXYgRGhv ZHk7IExlZXlvdW5nOyBTZXJnaW8gQmVsb3R0aTsgS2h1emVtYSBQaXRoZXdhbjsgU2VyZ2lvIEJl bG90dGkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGVlLXRl YXMtYWN0bi1yZXF1aXJlbWVudHMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWxlZS10ZWFzLWFjdG4tcmVxdWlyZW1lbnRzLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBZb3VuZyBMZWUgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0 b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbGVlLXRlYXMtYWN0bi1yZXF1aXJlbWVudHMNClJldmlzaW9u OgkwMA0KVGl0bGU6CQlSZXF1aXJlbWVudHMgZm9yIEFic3RyYWN0aW9uIGFuZCBDb250cm9sIG9m IFRyYW5zcG9ydCBOZXR3b3Jrcw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wNC0wOA0KR3JvdXA6CQlJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjcNClVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sZWUtdGVhcy1hY3RuLXJlcXVpcmVt ZW50cy0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1sZWUtdGVhcy1hY3RuLXJlcXVpcmVtZW50cy8NCkh0bWxpemVkOiAgICAgICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZWUtdGVhcy1hY3RuLXJlcXVpcmVtZW50 cy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkcmFmdCBwcm92aWRlcyBhIHNldCBvZiByZXF1 aXJlbWVudHMgZm9yIGFic3RyYWN0aW9uIGFuZA0KICAgY29udHJvbCBvZiB0cmFuc3BvcnQgbmV0 d29ya3MuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxl IGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Sat Apr 11 23:04:04 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7D71B34DB; Sat, 11 Apr 2015 23:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.5 X-Spam-Level: X-Spam-Status: No, score=-101.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg9XuZOWSdRu; Sat, 11 Apr 2015 23:03:56 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB731B34D8; Sat, 11 Apr 2015 23:03:55 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-7b-5529b4114d58 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F3.FD.12456.214B9255; Sun, 12 Apr 2015 01:53:54 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Sun, 12 Apr 2015 02:03:46 -0400 From: Gregory Mirsky To: "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+Cg== Date: Sun, 12 Apr 2015 06:03:46 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPoK7QFs1Qg6M7xSwuPnzKbHFr6UpW i89/tjFaNM3dxWTR+mMHiwOrx5IlP5k8vlz+zBbAFMVlk5Kak1mWWqRvl8CVsev+EfaCLXMZ K37OXM3SwPirg7GLkZNDQsBE4tmthWwQtpjEhXvrgWwuDiGBo4wS7dvfsUA4yxklfgOtAqli EzCSeLGxhx3EFhE4zSjxpVEJxGYW8JK49HwaM4gtLGAr0d/9hgmixknizLIrULaexJO578G2 sQioSmz7+JQFxOYV8JV4/PQeWJwR6Irvp9YwQcwUl7j1ZD4TxHUCEkv2nGeGsEUlXj7+xwph K0l8/D2fHaI+X2Lh+dtsEDMFJU7OfMIygVF4FpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY +8yBx0zI4gsY2VcxcpQWp5blphsZbGIERtIxCTbdHYx7XloeYhTgYFTi4X3grhEqxJpYVlyZ e4hRmoNFSZx30YODIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYhX0OJQgcSRWNLD3yTClF Idn9TnS22wvXBfnt/1f2fN5qLVvA/dm59ujJBeIV7wMuXjkVbrJy+36rzw9keCeYVlm98L8W P63tV5n+/bIbu88uVg9tttFnmPJ9v43V2h7pw8kz9klFB35qaBK/drRJVPf2v8l7sxztcooS 84quzv4gaGEcyletxFKckWioxVxUnAgAAAoC14UCAAA= Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: [Teas] Comments on draft-ietf-teas-rsvp-ingress-protection X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 06:03:59 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Editors, chairs, WG community, please find my comments to the current version of your work below: * Introduction o The first paragraph may leave an impression that local protection of tr= ansit LSRs is not being already addressed, neither by RFC 4090, nor RFC 487= 5; o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. * Section 3.1 o Third paragraph contains the following requirement: "For a P2P LSP, after the primary ingress fails, the backup ingress must us= e a method to reliably detect the failure of the primary ingress before the= PATH message for the LSP expires at the next hop of the primary ingress." But that is not obvious that such requirement is really needed. Since this = is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to c= ontrol switchover. Especially since, as noted in the last paragraph of Sect= ion 2.1, primary and backup ingress nodes must be connected by a logical li= nk, which in general case will be a tunnel. Thus this solution puts a requi= rement, implicitly though, to instantiate a tunnel per protection group, tu= nnel that would not be used to carry traffic. o In addition, what is importance of requirement quoted above: "... before the PATH message for the LSP expires at the next hop of the pri= mary ingress" o Fourth paragraph makes very questionable assumption in: "After the primary ingress fails, it will not be reachable after routing co= nvergence." I believe that if OAM session is between two nodes there's no reliable way = to differentiate between node and link failure. Thus, to declare a node unr= eachable there must be N tunnels for N OAM sessions that monitor all possib= le paths between two nodes. (Note, that if there was no requirement to use = a tunnel between primary and backup ingress, multi-hop BFD could be used th= ough its detection time being limited by IGP convergence, which may be too = slow comparing with your requirement of tens milliseconds). * Section 5.1 o Regarding "Ingress local protection in use" flag As demonstrated earlier, backup ingress node has no reliable way to detect = that primary ingress node is not reachable to the Source and thus protectio= n must be activated. Considering that backup ingress may initiate described in the document acti= ons not when primary ingress became unavailable to Source, I believe that c= ases that may produce false positives must be removed along with extensions= that intended to support these cases. In my opinion, the only viable case = of ingress protection is Source-centric where Source monitors availability = of both primary and backup ingress nodes and controls traffic switchover. I= 'd ask WG to discuss these comments and, if agreed, ask Editors to make app= ropriate changes to the document. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Editors, chairs, WG community,

please find my comments to the current version of yo= ur work below:

·         Introduction

o   The first paragraph may leave an impression = that local protection of transit LSRs is not being already addressed, neith= er by RFC 4090, nor RFC 4875;

o   I think that “global protection”= is not commonly used term, “end-to-end protection” seems to be= commonly used instead.

·         Section 3.1

o   Third paragraph contains the following requi= rement:

“For a P2P LSP, af= ter the primary ingress fails, the backup ingress must use a method to reli= ably detect the failure of the primary ingress before the PATH message for = the LSP expires at the next hop of the primary ingress.”

But that is not obvious = that such requirement is really needed. Since this is RSVP-TE LSP, why not = to use MP2MP construct and let the Source node to control switchover. Espec= ially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a lo= gical link, which in general case will be a tunnel. Thus this solution puts= a requirement, implicitly though, to instantiate a tunnel per protection g= roup, tunnel that would not be used to carry traffic.

o   In addition, what is importance of requireme= nt quoted above:

“… before th= e PATH message for the LSP expires at the next hop of the primary ingress&#= 8221;

o   Fourth paragraph makes very questionable ass= umption in:

“After the primary= ingress fails, it will not be reachable after routing convergence.”<= o:p>

I believe that if OAM se= ssion is between two nodes there’s no reliable way to differentiate b= etween node and link failure. Thus, to declare a node unreachable there mus= t be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirem= ent to use a tunnel between primary and backup ingress, multi-hop BFD could= be used though its detection time being limited by IGP convergence, which = may be too slow comparing with your requirement of tens milliseconds).

·         Section 5.1

o   Regarding “Ingress local protection in= use” flag

As demonstrated earlier,= backup ingress node has no reliable way to detect that primary ingress nod= e is not reachable to the Source and thus protection must be activated.

 

Considering that backup ingress may initiate describ= ed in the document actions not when primary ingress became unavailable to S= ource, I believe that cases that may produce false positives must be remove= d along with extensions that intended to support these cases. In my opinion, the only viable case of ingress pro= tection is Source-centric where Source monitors availability of both primar= y and backup ingress nodes and controls traffic switchover. I’d ask W= G to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B948347eusaamb103erics_-- From nobody Sun Apr 12 11:04:26 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED1BB1A1B60; Sun, 12 Apr 2015 11:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_K4h-p9ygPo; Sun, 12 Apr 2015 11:04:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127251A1B5E; Sun, 12 Apr 2015 11:04:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRH69625; Sun, 12 Apr 2015 18:04:15 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 12 Apr 2015 19:04:14 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Sun, 12 Apr 2015 11:03:39 -0700 From: Huaimo Chen To: Gregory Mirsky , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+CgBSx/EQ Date: Sun, 12 Apr 2015 18:03:38 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.94] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [Teas] [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2015 18:04:26 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, April 12, 2015 2:04 AM To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@iet= f.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Dear Editors, chairs, WG community, please find my comments to the current version of your work below: * Introduction o The first paragraph may leave an impression that local protection of tr= ansit LSRs is not being already addressed, neither by RFC 4090, nor RFC 487= 5; [Huaimo] Will revise it accordingly. o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. [Huaimo] It seems that "global protection" is better here since we mentione= d "local protection" here. It seems that Global Protection is used often. * Section 3.1 o Third paragraph contains the following requirement: "For a P2P LSP, after the primary ingress fails, the backup ingress must us= e a method to reliably detect the failure of the primary ingress before the= PATH message for the LSP expires at the next hop of the primary ingress." But that is not obvious that such requirement is really needed. Since this = is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to c= ontrol switchover. Especially since, as noted in the last paragraph of Sect= ion 2.1, primary and backup ingress nodes must be connected by a logical li= nk, which in general case will be a tunnel. Thus this solution puts a requi= rement, implicitly though, to instantiate a tunnel per protection group, tu= nnel that would not be used to carry traffic. [Huaimo] The requirement above seems necessary. If the backup ingress does = not detect the failure of the primary ingress before the timer for the PATH= message for the LSP at the next hop of the primary ingress expires, the LS= P will be down after the primary ingress fails. If the backup ingress detec= ts the failure and sends/refreshes the PATH message to the next hop before = the timer expires after the primary egress fails, the LSP will continue bei= ng up and carry the traffic from the backup ingress via the backup LSP. For a P2P LSP, it seems that MP2MP construct is not used in RFC 4090 to pro= tect a transit node of a P2P LSP. The logical link between the primary ingr= ess and the backup ingress can be a direct link or a tunnel. It seems that = a direct link is common. o In addition, what is importance of requirement quoted above: "... before the PATH message for the LSP expires at the next hop of the pri= mary ingress" [Huaimo] This seems very important. If the timer for the PATH message for t= he LSP at the next hop of the primary egress expires, then the LSP will be = down. So the PATH message must be refreshed before the timer for the PATH m= essage for the LSP expires at the next hop of the primary LSP. o Fourth paragraph makes very questionable assumption in: "After the primary ingress fails, it will not be reachable after routing co= nvergence." I believe that if OAM session is between two nodes there's no reliable way = to differentiate between node and link failure. Thus, to declare a node unr= eachable there must be N tunnels for N OAM sessions that monitor all possib= le paths between two nodes. (Note, that if there was no requirement to use = a tunnel between primary and backup ingress, multi-hop BFD could be used th= ough its detection time being limited by IGP convergence, which may be too = slow comparing with your requirement of tens milliseconds). [Huaimo] It is true that "After the primary ingress fails, it will not be r= eachable after routing convergence." From routing's point of view, there i= s no need for us to have any OAM session between two nodes. The timer for a= PATH message seems in tens of seconds. Routing convergence is not limited = to tens of milliseconds. * Section 5.1 o Regarding "Ingress local protection in use" flag As demonstrated earlier, backup ingress node has no reliable way to detect = that primary ingress node is not reachable to the Source and thus protectio= n must be activated. [Huaimo] It seems that there is no need for the backup ingress to detect wh= ether the primary ingress is reachable to the Source and the focus is on th= e failure of the primary ingress. Considering that backup ingress may initiate described in the document acti= ons not when primary ingress became unavailable to Source, I believe that c= ases that may produce false positives must be removed along with extensions= that intended to support these cases. In my opinion, the only viable case = of ingress protection is Source-centric where Source monitors availability = of both primary and backup ingress nodes and controls traffic switchover. I= 'd ask WG to discuss these comments and, if agreed, ask Editors to make app= ropriate changes to the document. [Huaimo] It seems that the current version already indicates that the sourc= e-detect (i.e., Source detects the failure of the primary ingress and switc= hes traffic to the backup ingress when the primary ingress fails) is used. = There were a few of modes for detecting the failure of the primary ingress= that were proposed in the previous versions of the document. A different m= ode may have a different control on the traffic switch over and/or forwardi= ng. After discussions, the current version selects the source-detect. Can you give more details about the cases in which false positives may be p= roduced? Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, April 12, 2015 2:04 AM
To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-cha= irs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection<= o:p>

 

Dear Editors, chairs, WG community,

please find my comments to the current version of yo= ur work below:

·        Introduction

o   The first paragraph may leave an impression = that local protection of transit LSRs is not being already addressed, neith= er by RFC 4090, nor RFC 4875;

[Huaimo] Will revise i= t accordingly.

o   I think that “global protection”= is not commonly used term, “end-to-end protection” seems to be= commonly used instead.

[Huaimo] It seems that= “global protection” is better here since we mentioned “l= ocal protection” here. It seems that Global Protection is used often.=

·        Section 3.1

o   Third paragraph contains the following requi= rement:

“For a P2P LSP, af= ter the primary ingress fails, the backup ingress must use a method to reli= ably detect the failure of the primary ingress before the PATH message for = the LSP expires at the next hop of the primary ingress.”

But that is not obvious = that such requirement is really needed. Since this is RSVP-TE LSP, why not = to use MP2MP construct and let the Source node to control switchover. Espec= ially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a lo= gical link, which in general case will be a tunnel. Thus this solution puts= a requirement, implicitly though, to instantiate a tunnel per protection g= roup, tunnel that would not be used to carry traffic.

[Huaimo] The requireme= nt above seems necessary. If the backup ingress does not detect the failure= of the primary ingress before the timer for the PATH message for the LSP a= t the next hop of the primary ingress expires, the LSP will be down after the primary ingress fails. If the back= up ingress detects the failure and sends/refreshes the PATH message to the = next hop before the timer expires after the primary egress fails, the LSP w= ill continue being up and carry the traffic from the backup ingress via the backup LSP. =

For a P2P LSP, it seem= s that MP2MP construct is not used in RFC 4090 to protect a transit node of= a P2P LSP. The logical link between the primary ingress and the backup ing= ress can be a direct link or a tunnel. It seems that a direct link is common.

o   In addition, what is importance of requireme= nt quoted above:

“… before th= e PATH message for the LSP expires at the next hop of the primary ingress&#= 8221;

[Huaimo] This seems ve= ry important. If the timer for the PATH message for the LSP at the next hop= of the primary egress expires, then the LSP will be down. So the PATH mess= age must be refreshed before the timer for the PATH message for the LSP expires at the next hop of the primary LS= P.

o   Fourth paragraph makes very questionable ass= umption in:

“After the primary= ingress fails, it will not be reachable after routing convergence.”<= o:p>

I believe that if OAM se= ssion is between two nodes there’s no reliable way to differentiate b= etween node and link failure. Thus, to declare a node unreachable there mus= t be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirem= ent to use a tunnel between primary and backup ingress, multi-hop BFD could= be used though its detection time being limited by IGP convergence, which = may be too slow comparing with your requirement of tens milliseconds).

[Huaimo] It is true th= at “After the primary ingress fails, it will not be reachable after r= outing convergence.”  From routing’s point of view, there = is no need for us to have any OAM session between two nodes. The timer for a PATH message seems in tens of seconds. Routing convergence= is not limited to tens of milliseconds.

·        Section 5.1

o   Regarding “Ingress local protection in= use” flag

As demonstrated earlier,= backup ingress node has no reliable way to detect that primary ingress nod= e is not reachable to the Source and thus protection must be activated.

[Huaimo] It seems that= there is no need for the backup ingress to detect whether the primary ingr= ess is reachable to the Source and the focus is on the failure of the prima= ry ingress.

 

Considering that backup ingress may initiate describ= ed in the document actions not when primary ingress became unavailable to S= ource, I believe that cases that may produce false positives must be remove= d along with extensions that intended to support these cases. In my opinion, the only viable case of ingress pro= tection is Source-centric where Source monitors availability of both primar= y and backup ingress nodes and controls traffic switchover. I’d ask W= G to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

[Huaimo] It seems that= the current version already indicates that the source-detect (i.e., Source= detects the failure of the primary ingress and switches traffic to the bac= kup ingress when the primary ingress fails) is used.  There were a few of modes for detecting the failure = of the primary ingress that were proposed in the previous versions of the d= ocument. A different mode may have a different control on the traffic switc= h over and/or forwarding.  After discussions, the current version selects the source-detect.

Can you give more deta= ils about the cases in which false positives may be produced?

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_5316A0AB3C851246A7CA5758973207D44E37EE98SJCEML701CHMchi_-- From nobody Mon Apr 13 09:11:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11FF1A013B for ; Mon, 13 Apr 2015 09:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_bAViNLVBjF for ; Mon, 13 Apr 2015 09:11:16 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54521A0104 for ; Mon, 13 Apr 2015 09:11:16 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t3DGB44H028463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 12:11:04 -0400 Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 13 Apr 2015 12:11:03 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 13 Apr 2015 12:11:03 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1076.000; Mon, 13 Apr 2015 12:11:03 -0400 From: Igor Bryskin To: Lou Berger , Xufeng Liu , Vishnu Pavan Beeram , Tarek Saad , Himanshu Shah Thread-Topic: Regarding IPR on draft-liu-teas-yang-te-topo Thread-Index: AQHQawjT756XyM8shkqXiLpvczj+KZ1LMgAQ Date: Mon, 13 Apr 2015 16:11:01 +0000 Message-ID: <0ca1479bc3db4422b8726e37ce92a0ba@ATL-SRV-MBX1.advaoptical.com> References: <55197D63.4050803@labn.net> In-Reply-To: <55197D63.4050803@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-13_03:2015-04-10,2015-04-13,1970-01-01 signatures=0 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Regarding IPR on draft-liu-teas-yang-te-topo X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 16:11:18 -0000 No, I am not aware of any IPR that applies to this draft. Igor -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Monday, March 30, 2015 12:44 PM To: Xufeng Liu; Igor Bryskin; Vishnu Pavan Beeram; Tarek Saad; Himanshu Sha= h Cc: TEAS WG Subject: Regarding IPR on draft-liu-teas-yang-te-topo Authors, Contributors, (TEAS) As part of the preparation for polling for WG document adoption: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/grou= p/iesg/trac/wiki/IntellectualProperty. Thank you, TEAS WG Chairs PS Please include all listed in the headers of this message in your respons= e. From nobody Mon Apr 13 11:08:30 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498AD1B29AB for ; Mon, 13 Apr 2015 11:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYMnw-yaWE4w for ; Mon, 13 Apr 2015 11:08:27 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 0AD431AD36B for ; Mon, 13 Apr 2015 11:08:27 -0700 (PDT) Received: (qmail 16690 invoked by uid 0); 13 Apr 2015 18:08:25 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 13 Apr 2015 18:08:25 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id Fc8M1q00K2SSUrH01c8QXR; Mon, 13 Apr 2015 18:08:24 -0600 X-Authority-Analysis: v=2.1 cv=C4J6l2/+ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=SY9aFQKHIdAA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=e9J7MTPGsLIA:10 a=Ng_RB-xFv2c8B7-wkS4A:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=u1nMZKXwb1LStAK3P0Qq8htDz+8w7FaY1twRw69j/vQ=; b=IEPKvbehADNAJVZkObYVVqZJOU26jrV6fZyHq+hv3RcACH0D5/yWp+6jiTYocwTQzwYxud08S5lUgV1t1IYvLfBCenS7WR3B5if6pQKCtG+sJkEnkY6YorY759yDEWgH; Received: from box313.bluehost.com ([69.89.31.113]:47035 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YhimU-0007Q4-MO for teas@ietf.org; Mon, 13 Apr 2015 12:08:22 -0600 Message-ID: <552C0611.70500@labn.net> Date: Mon, 13 Apr 2015 14:08:17 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: TEAS WG Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 18:08:28 -0000 All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send email to the list indicating yes/support or no/do not support. If indicating no, please state your technical reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and the intent is for this work to serve as the foundation for the WG's normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product. The DT will be closed once we have a WG document on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) From nobody Mon Apr 13 11:58:42 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ABE1B2FDD; Mon, 13 Apr 2015 11:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmZbqyi_vR7v; Mon, 13 Apr 2015 11:58:35 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965A61B2A2D; Mon, 13 Apr 2015 11:58:35 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-5d-552baee739f4 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 40.FB.17241.7EEAB255; Mon, 13 Apr 2015 13:56:23 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Mon, 13 Apr 2015 14:58:28 -0400 From: Gregory Mirsky To: "draft-ietf-teas-rsvp-egress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: Comments to draft-ietf-teas-rsvp-egress-protection Thread-Index: AdB055+jr3+smJ3uSuiCZj3/NJvp6A== Date: Mon, 13 Apr 2015 18:58:28 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B948D85@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPn+7zddqhBluatS2mvv3JbHFr6UpW i89/tjFaNM3dxWTR+mMHiwOrx5IlP5k8vlz+zBbAFMVlk5Kak1mWWqRvl8CVMWFNL3PBdM+K 8xPOsjQwbrfvYuTgkBAwkZhxuqiLkRPIFJO4cG89WxcjF4eQwFFGiYWXeplBEkICyxklNp4N A7HZBIwkXmzsYQexRQROMkr83Q5mMwt4SVx6Pg2sXljARmLe5S5GkPkiAo4SKxfnQJTrSax5 DtHKIqAq8flLHwtICa+Ar8ST7fogYUagE76fWsMEMVFc4taT+UwQpwlILNlznhnCFpV4+fgf K4StJDFp6TlWiPp8ie/rp7CA2LwCghInZz5hmcAoPAvJqFlIymYhKYOI60gs2P2JDcLWlli2 8DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDcxAqPnmASb4w7GBZ8sDzEKcDAq8fAmVGmFCrEm lhVX5h5ilOZgURLnLbtyMERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD4+GANV6lIdocZzVW qm8+3rrleElRfmzOPKbFO9yfJlj2qXVvYZZTupPJ929XiUWXvoXCcxZbz51pb2bGXDnO4rFG Xe36qh1Cvh8c02yE70hYt3Us0U5fYv4rw5UtwuNY3Ycbv23/ydxfdvqkS9a/r+XyD24rHpu3 58izKRumFDjlXQ25XM56XomlOCPRUIu5qDgRAKBq0SN/AgAA Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: [Teas] Comments to draft-ietf-teas-rsvp-egress-protection X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 18:58:38 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Editors, please kindly consider my comments to the current version of this work: * Introduction o The third paragraph mentions that an end-to-end protection may be slowe= r to detect failure and perform switchover then an arbitrary local protecti= on method. I believe that that is not the case and, as been demonstrated by= deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec= switchover and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec. o The last in Section 1.1 suggests that node R3 may detect failure of the= node L1 through monitoring BFD session between two nodes. Firstly, if this= is multi-hop BFD session over IP network, then there's no guarantee that i= ts path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed= that RFC 5884 may be used, I have to remind, that RFC 5884 operates betwee= n LSP end points and R1 is not end point. Thus, Sub-Path Maintenance Entity= (SPME) co-routed with the segment R1-L3 MUST be established. * Section 5.2 o The third paragraph assumes that if a PLR cannot establish LSP to any l= isted LSR in the EGRESS_BACKUP object it SHOULD select it locally and recor= d it in the EGRESS_BACKUP object. I believe that that implies that a PLR, i= .e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that = is required when selecting backup egress. That is serious security concern = and must be properly addressed in Security Considerations section of the dr= aft. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Editors,

please kindly consider my comments to the current ve= rsion of this work:

·         Introduction

o   The third paragraph mentions that an end-to-= end protection may be slower to detect failure and perform switchover then = an arbitrary local protection method. I believe that that is not the case a= nd, as been demonstrated by deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec switchover = and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec.

o   The last in Section 1.1 suggests that node R= 3 may detect failure of the node L1 through monitoring BFD session between = two nodes. Firstly, if this is multi-hop BFD session over IP network, then = there’s no guarantee that its path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed that R= FC 5884 may be used, I have to remind, that RFC 5884 operates between LSP e= nd points and R1 is not end point. Thus, Sub-Path Maintenance Entity (SPME)= co-routed with the segment R1-L3 MUST be established.

·         Section 5.2

o   The third paragraph assumes that if a PLR ca= nnot establish LSP to any listed LSR in the EGRESS_BACKUP object it SHOULD = select it locally and record it in the EGRESS_BACKUP object. I believe that= that implies that a PLR, i.e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that is requ= ired when selecting backup egress. That is serious security concern and mus= t be properly addressed in Security Considerations section of the draft.

 

Regards,

    &= nbsp;           Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B948D85eusaamb103erics_-- From nobody Mon Apr 13 12:18:44 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3C41B31AF for ; Mon, 13 Apr 2015 12:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ektecPt-kdCy for ; Mon, 13 Apr 2015 12:18:41 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533231B31B2 for ; Mon, 13 Apr 2015 12:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1261; q=dns/txt; s=iport; t=1428952719; x=1430162319; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uSfAsWieeD5DxY6RR8HIADRtvfs9Ld1vZHBiFK+AgQg=; b=NSlLxAsw3CQgbkn2nyg7LObC683hyK9x8TpN06tGYzNE9NcfG5h1HJ1n ssj/yEYiwHQWHWYd4mmlOlD+GtyC6nsuS6LTsAscWawjwBJ6tF1JA4EjU 86Q6QrV4uwU4gSqzpWQm9ZKcycES5kp43CSzaTfNv5rkaf8yEBtxGJ9u7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BxBQCjFSxV/51dJa1cgwxSXAXGWwqGAQKBPEwBAQEBAQF+hB8BAQEEAQEBNzQLDAQCAQgOAwQBAQsUCQcnCxQJCAIEAQ0FCIgiDc03AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLK4QZEQEgMQcGgxGBFgWQaSOLLIM3jEuDTSKDb2+BCzl/AQEB X-IronPort-AV: E=Sophos;i="5.11,571,1422921600"; d="scan'208";a="411509639" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 13 Apr 2015 19:18:39 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t3DJIcP2006669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 Apr 2015 19:18:38 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.90]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 14:18:38 -0500 From: "Matt Hartley (mhartley)" To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTcRaiLQvA6yUSxdtLRJDp3yJ1LUVKQ Date: Mon, 13 Apr 2015 19:18:37 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC29C1EF43@xmb-rcd-x03.cisco.com> References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Matt Hartley \(mhartley\)" Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 19:18:43 -0000 Support Cheers Matt > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Monday, April 13, 2015 2:08 PM > To: TEAS WG > Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG > document >=20 > All, >=20 > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send > email to the list indicating "yes/support" or "no/do not support". > If indicating no, please state your technical reservations with the > document. If yes, please also feel free to provide comments you'd like t= o > see addressed once the document is a WG document. >=20 > This document is the product of the TE Topology YANG Model Design Team an= d > the intent is for this work to serve as the foundation for the WG's norma= l > activities in this area, i.e., the document is the starting point for the > WG -- not a finished product. The DT will be closed once we have a WG > document on this topic. >=20 > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 13 12:36:46 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165031B328A for ; Mon, 13 Apr 2015 12:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.9 X-Spam-Level: X-Spam-Status: No, score=-99.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iewkw2Iv64r for ; Mon, 13 Apr 2015 12:36:44 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05521B3289 for ; Mon, 13 Apr 2015 12:36:43 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3DJafUu006730; Mon, 13 Apr 2015 20:36:41 +0100 Received: from 950129200 (ANancy-651-1-125-52.w90-48.abo.wanadoo.fr [90.48.30.52]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id t3DJaeDw006713 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2015 20:36:41 +0100 From: "Adrian Farrel" To: "'Lou Berger'" , "'TEAS WG'" References: <552C0611.70500@labn.net> In-Reply-To: Date: Mon, 13 Apr 2015 20:36:42 +0100 Message-ID: <025101d07621$2b98b1d0$82ca1570$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMTEhcf0WlBqFkj/ZCSupbxwsGBUprGEzEQgAAK22A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21474.002 X-TM-AS-Result: No--15.130-10.0-31-10 X-imss-scan-details: No--15.130-10.0-31-10 X-TMASE-MatchedRID: HXSqh3WYKftjDV//SvkH3mZUc2jtcaSdKX6lhgF7CVSvloAnGr4qhh91 nu4tP5W0CKlVV1A1xTUMo1U+ogv8V5vxTUCbTIIRzNY33yIEF4bE+tSSoKDaKT9ohhNcm0PQzjs +m829nTrnpxCxCXIK2HLEXBbQP/X3HdkkLawA7SGZroPNdqiG87qGBW9J0Yqjktc0kse+BTCKqv zS2KCdDsJJebCozntWXt8ATw/RltVhaj10i6TXQEK9qlwiTElfdZPoD9V2prSbKItl61J/ycnjL TA/UDoAxpQ77C1A1tqOhzOa6g8KrZRMZUCEHkRt Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 19:36:46 -0000 Oh, yes please. We keenly need to adopt a draft to provide a focus so that we don't proliferate "competing" drafts. This one would be a good starting point and, once adopted, the WG can work on making it say what they want. Adrian > > -----Original Message----- > > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > > Sent: 13 April 2015 19:08 > > To: TEAS WG > > Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document > > > > All, > > > > This is start of a two week poll on making > > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please > > send email to the list indicating "yes/support" or "no/do not support". > > If indicating no, please state your technical reservations with the > > document. If yes, please also feel free to provide comments you'd like > > to see addressed once the document is a WG document. > > > > This document is the product of the TE Topology YANG Model Design Team > > and the intent is for this work to serve as the foundation for the WG's > > normal activities in this area, i.e., the document is the starting point > > for the WG -- not a finished product. The DT will be closed once we > > have a WG document on this topic. > > > > The poll ends Monday April 27th > > Thanks, > > Lou (and Pavan, who is a co-author) > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 13 12:42:54 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7381A1A11 for ; Mon, 13 Apr 2015 12:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0peiNyfyFLA for ; Mon, 13 Apr 2015 12:42:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 641141A014E for ; Mon, 13 Apr 2015 12:42:51 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-d1-552bb94b5f36 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 74.FE.17241.B49BB255; Mon, 13 Apr 2015 14:40:44 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Mon, 13 Apr 2015 15:42:49 -0400 From: Gregory Mirsky To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTdL9sWGcTEfUquUgsHpbpv/51LV9JA Date: Mon, 13 Apr 2015 19:42:48 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B948E74@eusaamb103.ericsson.se> References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXRPlK7PTu1Qg1NTmSw6mt+yWLT+2MHi wOSxZMlPJo8Pm5rZApiiuGxSUnMyy1KL9O0SuDLOfN7FWrCFs2LVwQ+MDYzn2bsYOTkkBEwk FuxZzQhhi0lcuLeerYuRi0NI4CijxP2Zz1ggnOWMEk8OHWcCqWITMJJ4sbEHrFtEwEqi48BO sLiwQKDE4usv2SDiQRJr3z9ihLCNJBatnsQCYrMIqEosfvsdrIZXwFfi/dpJYLYQUHzmhxnM IDangJrEqYU3wOKMQBd9P7UGbD6zgLjErSfzmSAuFZBYsuc8M4QtKvHy8T9WCFtJYtLSc6wQ 9ToSC3Z/YoOwtSWWLXzNDLFXUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyFFanFqWm25k uIkRGA/HJNgcdzAu+GR5iFGAg1GJhzehSitUiDWxrLgy9xCjNAeLkjhv2ZWDIUIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYEyKZpL93FYVsOvRVM8xo3uw38+wUHZS8cqTCw85ctngv6bs1 /wRbXU3p0yXOn5p6nkRceHppA5vb3l6WI/ef/dKJnctzRzbryvVjmt9Ouu7hvypiscD7dMIL OenJLdYBf791s/oWhbSekpwwo3AtgzOr1W6e8GvPvPZquK95di2/hOeEc5aZEktxRqKhFnNR cSIAyc9/LGgCAAA= Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 19:42:52 -0000 Yes, support Regards, Greg -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, April 13, 2015 11:08 AM To: TEAS WG Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send e= mail to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the documen= t. If yes, please also feel free to provide comments you'd like to see add= ressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and = the intent is for this work to serve as the foundation for the WG's normal = activities in this area, i.e., the document is the starting point for the W= G -- not a finished product. The DT will be closed once we have a WG docum= ent on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 13 16:53:13 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075461B29D9 for ; Mon, 13 Apr 2015 16:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ucmrqh3ziqpz for ; Mon, 13 Apr 2015 16:53:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0726.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:726]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83411B29CE for ; Mon, 13 Apr 2015 16:53:10 -0700 (PDT) Received: from BY2PR05MB192.namprd05.prod.outlook.com (10.242.39.149) by BY2PR05MB192.namprd05.prod.outlook.com (10.242.39.149) with Microsoft SMTP Server (TLS) id 15.1.130.23; Mon, 13 Apr 2015 23:52:50 +0000 Received: from BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.12]) by BY2PR05MB192.namprd05.prod.outlook.com ([169.254.11.12]) with mapi id 15.01.0130.020; Mon, 13 Apr 2015 23:52:50 +0000 From: Santosh Esale To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTbioS/yoyoFEeTvdzDD6g6Mp1LKH0A Date: Mon, 13 Apr 2015 23:52:49 +0000 Message-ID: References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] authentication-results: labn.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB192; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(52044002)(479174004)(164054003)(24454002)(377454003)(86362001)(76176999)(62966003)(36756003)(102836002)(66066001)(15975445007)(54356999)(50986999)(230783001)(4001350100001)(19580405001)(19580395003)(2656002)(87936001)(83506001)(77156002)(2950100001)(107886001)(122556002)(92566002)(46102003)(99286002)(106116001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB192; H:BY2PR05MB192.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR05MB192; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB192; x-forefront-prvs: 0545EFAC9A Content-Type: text/plain; charset="utf-8" Content-ID: <6440E988D5D2F74D9C577151A5BFE16B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2015 23:52:49.9569 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB192 Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 23:53:13 -0000 WWVzL1N1cHBvcnQuDQoNCg0KLVNhbnRvc2gNCg0KT24gNC8xMy8xNSwgMTE6MDggQU0sICJMb3Ug QmVyZ2VyIiA8bGJlcmdlckBsYWJuLm5ldD4gd3JvdGU6DQoNCj5BbGwsDQo+DQo+VGhpcyBpcyBz dGFydCBvZiBhIHR3byB3ZWVrIHBvbGwgb24gbWFraW5nDQo+ZHJhZnQtbGl1LXRlYXMteWFuZy10 ZS10b3BvLTAxIGEgVEVBUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiBQbGVhc2UNCj5zZW5kIGVt YWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcg4oCceWVzL3N1cHBvcnTigJ0gb3Ig4oCcbm8vZG8g bm90IHN1cHBvcnTigJ0uDQo+SWYgaW5kaWNhdGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIgdGVj aG5pY2FsIHJlc2VydmF0aW9ucyB3aXRoIHRoZQ0KPmRvY3VtZW50LiAgSWYgeWVzLCBwbGVhc2Ug YWxzbyBmZWVsIGZyZWUgdG8gcHJvdmlkZSBjb21tZW50cyB5b3UnZCBsaWtlDQo+dG8gc2VlIGFk ZHJlc3NlZCBvbmNlIHRoZSBkb2N1bWVudCBpcyBhIFdHIGRvY3VtZW50Lg0KPg0KPlRoaXMgZG9j dW1lbnQgaXMgdGhlIHByb2R1Y3Qgb2YgdGhlIFRFIFRvcG9sb2d5IFlBTkcgTW9kZWwgRGVzaWdu IFRlYW0NCj5hbmQgdGhlIGludGVudCBpcyBmb3IgdGhpcyB3b3JrIHRvIHNlcnZlIGFzIHRoZSBm b3VuZGF0aW9uIGZvciB0aGUgV0cncw0KPm5vcm1hbCBhY3Rpdml0aWVzIGluIHRoaXMgYXJlYSwg aS5lLiwgdGhlIGRvY3VtZW50IGlzIHRoZSBzdGFydGluZyBwb2ludA0KPmZvciB0aGUgV0cgLS0g bm90IGEgZmluaXNoZWQgcHJvZHVjdC4gIFRoZSBEVCB3aWxsIGJlIGNsb3NlZCBvbmNlIHdlDQo+ aGF2ZSBhIFdHIGRvY3VtZW50IG9uIHRoaXMgdG9waWMuDQo+DQo+VGhlIHBvbGwgZW5kcyBNb25k YXkgQXByaWwgMjd0aA0KPlRoYW5rcywNCj5Mb3UgKGFuZCBQYXZhbiwgd2hvIGlzIGEgY28tYXV0 aG9yKQ0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+VGVhcyBtYWlsaW5nIGxpc3QNCj5UZWFzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQoNCg== From nobody Mon Apr 13 17:02:40 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1599B1B29E7 for ; Mon, 13 Apr 2015 17:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DW60cpXTdvd for ; Mon, 13 Apr 2015 17:02:37 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756591B29E2 for ; Mon, 13 Apr 2015 17:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1077; q=dns/txt; s=iport; t=1428969757; x=1430179357; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=XnwN5w1TVo7CCk1mSqJBAn7bgHBXPL4iVbrLlz0KmAc=; b=lCRF4wv7hDd+K0ITSwjQMQ4ZSGCAxVfDZBV6RpP1ML9gT8lniRaXYCtM Eu6kolnAqrHV3CgcEhcWKqqYRUDGkeI5kWD4WlGazPVIbvkETZAHfRkU7 9uu3sxHNKI2LZQep8Zey+3rDo7PbgKsZtslPYqvbX38DyQhhXENpNW0ks U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BQBADVVyxV/5xdJa1cgwxSXAXFEAmBRAqGAQKBQDgUAQEBAQEBAX2EIAEBBAEBAWsdAQgOXwslAgQBEogqDc0JAQEBAQEBAQMBAQEBAQEBFwSLK4QZEQEeOoQtBYp8hW0jig+BHYM3jEuDTSKDb2+BCzl/AQEB X-IronPort-AV: E=Sophos;i="5.11,573,1422921600"; d="scan'208";a="140917168" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 14 Apr 2015 00:02:36 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3E02anZ011686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Apr 2015 00:02:36 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.108]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Mon, 13 Apr 2015 19:02:36 -0500 From: "Rakesh Gandhi (rgandhi)" To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTcaHLyxjNnCk+e1cU7fxN6dp1LsTSA Date: Tue, 14 Apr 2015 00:02:35 +0000 Message-ID: In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.86.247.238] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <08F0E05387E104499843D7C2B2718AFB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 00:02:39 -0000 Hi Lou, yes/support. Regards, Rakesh On 2015-04-13 2:08 PM, "Lou Berger" wrote: >All, > >This is start of a two week poll on making >draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please >send email to the list indicating =B3yes/support=B2 or =B3no/do not suppor= t=B2. >If indicating no, please state your technical reservations with the >document. If yes, please also feel free to provide comments you'd like >to see addressed once the document is a WG document. > >This document is the product of the TE Topology YANG Model Design Team >and the intent is for this work to serve as the foundation for the WG's >normal activities in this area, i.e., the document is the starting point >for the WG -- not a finished product. The DT will be closed once we >have a WG document on this topic. > >The poll ends Monday April 27th >Thanks, >Lou (and Pavan, who is a co-author) > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 13 17:56:11 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048351A8A1F for ; Mon, 13 Apr 2015 17:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPAES9iAtrWM for ; Mon, 13 Apr 2015 17:56:07 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0678.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::678]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED351A8911 for ; Mon, 13 Apr 2015 17:56:06 -0700 (PDT) Received: from DB5PR04MB0981.eurprd04.prod.outlook.com (25.161.196.25) by DB5PR04MB0981.eurprd04.prod.outlook.com (25.161.196.25) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 14 Apr 2015 00:54:12 +0000 Received: from DB5PR04MB0981.eurprd04.prod.outlook.com ([25.161.196.25]) by DB5PR04MB0981.eurprd04.prod.outlook.com ([25.161.196.25]) with mapi id 15.01.0136.014; Tue, 14 Apr 2015 00:54:12 +0000 From: "Doolan, Paul (Coriant - US/Irving)" To: Lou Berger Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTe9fUehaCAVU2G5q2A51JkOZ1Lrt8A Date: Tue, 14 Apr 2015 00:54:12 +0000 Message-ID: References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: labn.net; dkim=none (message not signed) header.d=none; x-originating-ip: [2601:6:8900:c42c:226:bbff:fe67:cade] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR04MB0981; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(51704005)(164054003)(52044002)(19580395003)(82746002)(87936001)(122556002)(46102003)(86362001)(2656002)(92566002)(106116001)(36756003)(15975445007)(102836002)(54356999)(50986999)(77156002)(19580405001)(230783001)(110136001)(2900100001)(2950100001)(33656002)(83716003)(62966003)(76176999)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR04MB0981; H:DB5PR04MB0981.eurprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DB5PR04MB0981; BCL:0; PCL:0; RULEID:; SRVR:DB5PR04MB0981; x-forefront-prvs: 054642504A Content-Type: text/plain; charset="Windows-1252" Content-ID: <81B17A88FFC9AF4C9B0B62F6871C21C7@eurprd04.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2015 00:54:12.1737 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 76595477-907e-4695-988b-a6b39087332d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR04MB0981 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 00:56:10 -0000 Hi Lou,=20 > Please > send email to the list indicating =93yes/support=94 or =93no/do not suppo= rt=94. yes/support > If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. TEAS is "Traffic Engineering Architecture and Signaling". This is a draft f= or a YANG (and therefore) data model for 'TE topologies' which is but one p= art of the puzzle; it's necessary but not sufficient. Somewhere the TEAS WG= needs to document a bunch of other things and, until we dismiss the need = or find another home for them, I suggest we address them in this document. Amongst the things I think need covering are: architectural background/fra= mework; definition of terms; use cases; examples; performance consideration= s and relationship to/alignment with work in other WG's/organizations (see= Adrian's comment). I think we should also try hard to separate fundamental= topology matters from things like scheduling. All that said this draft is a good place to start from. pd On Apr 13, 2015, at 2:08 PM, Lou Berger wrote: > All, >=20 > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please > send email to the list indicating =93yes/support=94 or =93no/do not suppo= rt=94. > If indicating no, please state your technical reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. >=20 > This document is the product of the TE Topology YANG Model Design Team > and the intent is for this work to serve as the foundation for the WG's > normal activities in this area, i.e., the document is the starting point > for the WG -- not a finished product. The DT will be closed once we > have a WG document on this topic. >=20 > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 13 18:12:17 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1C11B2A88 for ; Mon, 13 Apr 2015 18:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.761 X-Spam-Level: X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROl1YWXG-ICR for ; Mon, 13 Apr 2015 18:12:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F1E1AD350 for ; Mon, 13 Apr 2015 18:12:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUU65680; Tue, 14 Apr 2015 01:12:10 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Apr 2015 02:12:09 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.171]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Tue, 14 Apr 2015 09:12:06 +0800 From: "Zhangxian (Xian)" To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTdEf064KpJ4UupGbJJjh9bAJ1LsI1Q Date: Tue, 14 Apr 2015 01:12:06 +0000 Message-ID: References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 01:12:16 -0000 WWVzL3N1cHBvcnQuDQoNCkkgd291bGQgbGlrZSBzZWUgdGhlIGNoYW5nZXMgbWVudGlvbmVkIGFu ZCBjb21tZW50cyByYWlzZWQgZHVyaW5nIElFVEY5MiB0byBiZSByZWZsZWN0ZWQgZWl0aGVyIHdp dGhpbiB0aGlzIGRvY3VtZW50IG9yIGluIGFub3RoZXIgZm9ybS4gUGF1bCBhbHJlYWR5IHByb3Zp ZGVzIGEgZ29vZCBzdW1tYXJ5LCBiZXNpZGVzIHRoZSBtaW51dGVzLCBJIHNlZSBubyBuZWVkIHRv IHJlcGVhdC4gOi0pDQoNClJlZ2FyZHMsDQpYaWFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBUZWFzIFttYWlsdG86dGVhcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTG91IEJlcmdlcg0KU2VudDogMjAxNcTqNNTCMTTI1SAyOjA4DQpUbzogVEVBUyBXRw0KU3Vi amVjdDogW1RlYXNdIFBvbGwgb24gbWFraW5nIGRyYWZ0LWxpdS10ZWFzLXlhbmctdGUtdG9wby0w MSBhIFdHIGRvY3VtZW50DQoNCkFsbCwNCg0KVGhpcyBpcyBzdGFydCBvZiBhIHR3byB3ZWVrIHBv bGwgb24gbWFraW5nDQpkcmFmdC1saXUtdGVhcy15YW5nLXRlLXRvcG8tMDEgYSBURUFTIHdvcmtp bmcgZ3JvdXAgZG9jdW1lbnQuIFBsZWFzZQ0Kc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0 aW5nIKGweWVzL3N1cHBvcnShsSBvciChsG5vL2RvIG5vdCBzdXBwb3J0obEuDQpJZiBpbmRpY2F0 aW5nIG5vLCBwbGVhc2Ugc3RhdGUgeW91ciB0ZWNobmljYWwgcmVzZXJ2YXRpb25zIHdpdGggdGhl DQpkb2N1bWVudC4gIElmIHllcywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29t bWVudHMgeW91J2QgbGlrZQ0KdG8gc2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBkb2N1bWVudCBpcyBh IFdHIGRvY3VtZW50Lg0KDQpUaGlzIGRvY3VtZW50IGlzIHRoZSBwcm9kdWN0IG9mIHRoZSBURSBU b3BvbG9neSBZQU5HIE1vZGVsIERlc2lnbiBUZWFtDQphbmQgdGhlIGludGVudCBpcyBmb3IgdGhp cyB3b3JrIHRvIHNlcnZlIGFzIHRoZSBmb3VuZGF0aW9uIGZvciB0aGUgV0cncw0Kbm9ybWFsIGFj dGl2aXRpZXMgaW4gdGhpcyBhcmVhLCBpLmUuLCB0aGUgZG9jdW1lbnQgaXMgdGhlIHN0YXJ0aW5n IHBvaW50DQpmb3IgdGhlIFdHIC0tIG5vdCBhIGZpbmlzaGVkIHByb2R1Y3QuICBUaGUgRFQgd2ls bCBiZSBjbG9zZWQgb25jZSB3ZQ0KaGF2ZSBhIFdHIGRvY3VtZW50IG9uIHRoaXMgdG9waWMuDQoN ClRoZSBwb2xsIGVuZHMgTW9uZGF5IEFwcmlsIDI3dGgNClRoYW5rcywNCkxvdSAoYW5kIFBhdmFu LCB3aG8gaXMgYSBjby1hdXRob3IpDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpUZWFzIG1haWxpbmcgbGlzdA0KVGVhc0BpZXRmLm9yZw0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQo= From nobody Mon Apr 13 18:43:23 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6690C1B2C2B for ; Mon, 13 Apr 2015 18:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx12Ulz_4TxI for ; Mon, 13 Apr 2015 18:43:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F761B2C29 for ; Mon, 13 Apr 2015 18:43:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUU67269; Tue, 14 Apr 2015 01:43:17 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Apr 2015 02:43:17 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Mon, 13 Apr 2015 18:43:10 -0700 From: Huaimo Chen To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdlK+1ymFqU3ZHEKYBAov+2TcT51Lu8Dg Date: Tue, 14 Apr 2015 01:43:09 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E37F01C@SJCEML701-CHM.china.huawei.com> References: <552C0611.70500@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 01:43:21 -0000 Support. Best Regards, Huaimo -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger To: TEAS WG Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send e= mail to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the documen= t. If yes, please also feel free to provide comments you'd like to see add= ressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and = the intent is for this work to serve as the foundation for the WG's normal = activities in this area, i.e., the document is the starting point for the W= G -- not a finished product. The DT will be closed once we have a WG docum= ent on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 13 19:28:08 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0D61B315D for ; Mon, 13 Apr 2015 19:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQ8A-HHWv3Cn for ; Mon, 13 Apr 2015 19:28:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422B11B3168 for ; Mon, 13 Apr 2015 19:28:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUU69701; Tue, 14 Apr 2015 02:27:58 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Apr 2015 03:27:57 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.219]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Tue, 14 Apr 2015 10:27:51 +0800 From: Mach Chen To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTcOEjRSr4JlEKVObkLebvVPp1LyMxw Date: Tue, 14 Apr 2015 02:27:50 +0000 Message-ID: References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 02:28:07 -0000 Yes/support. Best regards, Mach > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, April 14, 2015 2:08 AM > To: TEAS WG > Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docume= nt >=20 > All, >=20 > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send > email to the list indicating "yes/support" or "no/do not support". > If indicating no, please state your technical reservations with the docum= ent. > If yes, please also feel free to provide comments you'd like to see addre= ssed > once the document is a WG document. >=20 > This document is the product of the TE Topology YANG Model Design Team an= d > the intent is for this work to serve as the foundation for the WG's norma= l > activities in this area, i.e., the document is the starting point for the= WG -- not > a finished product. The DT will be closed once we have a WG document on > this topic. >=20 > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 13 20:19:40 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE37C1B3291; Mon, 13 Apr 2015 20:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8qd5lRbyHBD; Mon, 13 Apr 2015 20:19:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B057F1B3293; Mon, 13 Apr 2015 20:19:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUU73010; Tue, 14 Apr 2015 03:19:30 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Apr 2015 04:19:29 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Mon, 13 Apr 2015 20:19:26 -0700 From: Huaimo Chen To: Gregory Mirsky , "draft-ietf-teas-rsvp-egress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Thread-Index: AdB055+jr3+smJ3uSuiCZj3/NJvp6ABbWMEw Date: Tue, 14 Apr 2015 03:19:26 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E37F079@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948D85@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B948D85@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.193] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [Teas] [mpls] Comments to draft-ietf-teas-rsvp-egress-protection X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 03:19:36 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Monday, April 13, 2015 2:58 PM To: draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; teas-chairs@ietf= .org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection Dear Editors, please kindly consider my comments to the current version of this work: * Introduction o The third paragraph mentions that an end-to-end protection may be slowe= r to detect failure and perform switchover then an arbitrary local protecti= on method. I believe that that is not the case and, as been demonstrated by= deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec= switchover and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec. [Huaimo] It seems that the statement in the paragraph is true. For a globa= l protection (or an end-to-end protection), it may take more time since the= time includes the propagation time and processing time. The propagation ti= me may depend on the size of the network. In general, the bigger the networ= k, the longer the propagation delay. The processing time may comprise the r= elated processing time on every node along the path from the egress node to= a node interesting the failure and doing switchover. o The last in Section 1.1 suggests that node R3 may detect failure of the= node L1 through monitoring BFD session between two nodes. Firstly, if this= is multi-hop BFD session over IP network, then there's no guarantee that i= ts path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed= that RFC 5884 may be used, I have to remind, that RFC 5884 operates betwee= n LSP end points and R1 is not end point. Thus, Sub-Path Maintenance Entity= (SPME) co-routed with the segment R1-L3 MUST be established. [Huaimo] It seems that R3 is the upstream node of L1 and there is no multi-= hop BFD session between R3 and L1. This current version of the document focuses on extending the protection of= RFC 4090 from a transit node to an egress node. It seems that it is better= to have another document for others if needed. * Section 5.2 o The third paragraph assumes that if a PLR cannot establish LSP to any l= isted LSR in the EGRESS_BACKUP object it SHOULD select it locally and recor= d it in the EGRESS_BACKUP object. I believe that that implies that a PLR, i= .e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that = is required when selecting backup egress. That is serious security concern = and must be properly addressed in Security Considerations section of the dr= aft. [Huaimo] This paragraph says that the upstream node of the primary egress k= nows/determines that there is not any backup egress given for the primary = egress. In this case, the upstream node selects a backup egress according t= o a local policy. The upstream node may not need to be aware of any service= s or CEs. Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [ma= ilto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Monday, April 13, 2015 2:58 PM
To: draft-ietf-teas-rsvp-egress-protection@tools.ietf.org; teas-chai= rs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: [mpls] Comments to draft-ietf-teas-rsvp-egress-protection

 

Dear Editors,

please kindly consider my comments to the current ve= rsion of this work:

·        Introduction

o   The third paragraph mentions that an end-to-= end protection may be slower to detect failure and perform switchover then = an arbitrary local protection method. I believe that that is not the case a= nd, as been demonstrated by deployments of G.8031, G.8032 and RFC 6378 end-to-end provides sub-50 msec switchover = and G.8013/Y.1731 and RFC 5884 failure detection is 10 msec.

[Huaimo] It seems that= the statement in the paragraph is true.  For a global protection (or = an end-to-end protection), it may take more time since the time includes th= e propagation time and processing time. The propagation time may depend on the size of the network. In general, the bi= gger the network, the longer the propagation delay. The processing time may= comprise the related processing time on every node along the path from the= egress node to a node interesting the failure and doing switchover.

o   The last in Section 1.1 suggests that node R= 3 may detect failure of the node L1 through monitoring BFD session between = two nodes. Firstly, if this is multi-hop BFD session over IP network, then = there’s no guarantee that its path is co-routed with the LSP segment R1-L3. Secondly, if it is assumed that R= FC 5884 may be used, I have to remind, that RFC 5884 operates between LSP e= nd points and R1 is not end point. Thus, Sub-Path Maintenance Entity (SPME)= co-routed with the segment R1-L3 MUST be established.

[Huaimo] It seems that= R3 is the upstream node of L1 and there is no multi-hop BFD session betwee= n R3 and L1.

This current version o= f the document focuses on extending the protection of RFC 4090 from a trans= it node to an egress node. It seems that it is better to have another docum= ent for others if needed.

·        Section 5.2

o   The third paragraph assumes that if a PLR ca= nnot establish LSP to any listed LSR in the EGRESS_BACKUP object it SHOULD = select it locally and record it in the EGRESS_BACKUP object. I believe that= that implies that a PLR, i.e. any LSR in the MPLS domain is aware of all services, i.e. CEs, as that is requ= ired when selecting backup egress. That is serious security concern and mus= t be properly addressed in Security Considerations section of the draft.

[Huaimo] This paragrap= h says that the upstream node of the primary egress knows/determines that &= nbsp;there is not any backup egress given for the primary egress. In this c= ase, the upstream node selects a backup egress according to a local policy. The upstream node may not need to be aware of= any services or CEs.    

 

Regards,

    &= nbsp;           Greg=

--_000_5316A0AB3C851246A7CA5758973207D44E37F079SJCEML701CHMchi_-- From nobody Mon Apr 13 23:06:53 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781AE1B340E for ; Mon, 13 Apr 2015 23:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a2kBMNH11eb for ; Mon, 13 Apr 2015 23:06:49 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7BE1B340D for ; Mon, 13 Apr 2015 23:06:49 -0700 (PDT) X-AuditID: c1b4fb3a-f79146d0000070a3-4a-552cae76f002 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 12.91.28835.67EAC255; Tue, 14 Apr 2015 08:06:47 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.84]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0210.002; Tue, 14 Apr 2015 08:06:46 +0200 From: Daniele Ceccarelli To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTbisRONl4SF0innoyOLyHU251MBg/w Date: Tue, 14 Apr 2015 06:06:45 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48128C928B@ESESSMB301.ericsson.se> References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvjW75Op1Qg+UrOC06mt+yWLT+2MHi wOSxZMlPJo8Pm5rZApiiuGxSUnMyy1KL9O0SuDJWL1/AXPCes2LS6a8sDYxf2bsYOTkkBEwk 3jxcBGWLSVy4t56ti5GLQ0jgKKNE75MuJghnMaPEmp9dQFUcHGwCVhJPDvmANIgAmR0HdjKB 2MICgRKLr79kg4gHSax9/4gRwjaSOP35HiuIzSKgKnFqwhKwZbwCvhIbdzwGiwsBxWd+mMEM YnMKqEmcWngDbA6jgKzEhN2LwOYwC4hL3HoynwniUAGJJXvOM0PYohIvH/9jhbCVJBbd/swE Ua8ncWPqFDYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjKLFqcXFuelG RnqpRZnJxcX5eXp5qSWbGIFxcnDLb6sdjAefOx5iFOBgVOLhXVCiEyrEmlhWXJl7iFGag0VJ nNfO+FCIkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsa1XbINs68k3ZtzkZPFJ3S17Pn+bYsO sTpHKE12lzi6k2NPmpzW1oB10bM+2wr6buUNzXKT/3TsDp/mkniPrPrrb3kSrERu7V0UqTtV b/Pursfh4V93eifludefKe6yE+k9NvvO7UqDz8Lt/6NLkgIrFdM/v+p8y3ckOvDtPuug56dn b5CW2KrEUpyRaKjFXFScCACGYnZRdAIAAA== Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 06:06:51 -0000 Yes/support BR Daniele > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: luned=EC 13 aprile 2015 20:08 > To: TEAS WG > Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG > document >=20 > All, >=20 > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send > email to the list indicating "yes/support" or "no/do not support". > If indicating no, please state your technical reservations with the docum= ent. > If yes, please also feel free to provide comments you'd like to see addre= ssed > once the document is a WG document. >=20 > This document is the product of the TE Topology YANG Model Design Team > and the intent is for this work to serve as the foundation for the WG's n= ormal > activities in this area, i.e., the document is the starting point for the= WG -- > not a finished product. The DT will be closed once we have a WG document > on this topic. >=20 > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 13 23:57:53 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 858A41B3488 for ; Mon, 13 Apr 2015 23:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCihBDBDICYe for ; Mon, 13 Apr 2015 23:57:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FB41B3487 for ; Mon, 13 Apr 2015 23:57:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUU88373; Tue, 14 Apr 2015 06:57:49 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Apr 2015 07:57:48 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.135]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Tue, 14 Apr 2015 14:57:41 +0800 From: "Dongjie (Jimmy)" To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTc4GYLey+6tU6PL4caJ6kMLJ1ME7DQ Date: Tue, 14 Apr 2015 06:57:40 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92757D04B89@nkgeml512-mbx.china.huawei.com> References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 06:57:52 -0000 Hi Lou,=20 Yes/support. Agree with what Adrian said: this document can be a good start= ing point. Best regards, Jie > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, April 14, 2015 2:08 AM > To: TEAS WG > Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docume= nt >=20 > All, >=20 > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send > email to the list indicating "yes/support" or "no/do not support". > If indicating no, please state your technical reservations with the docum= ent. If > yes, please also feel free to provide comments you'd like to see addresse= d once > the document is a WG document. >=20 > This document is the product of the TE Topology YANG Model Design Team an= d > the intent is for this work to serve as the foundation for the WG's norma= l > activities in this area, i.e., the document is the starting point for the= WG -- not a > finished product. The DT will be closed once we have a WG document on th= is > topic. >=20 > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Tue Apr 14 06:14:26 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40931A90F3 for ; Tue, 14 Apr 2015 06:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVr5Si8zNyp0 for ; Tue, 14 Apr 2015 06:14:22 -0700 (PDT) Received: from mail.advaoptical.com (mail.advaoptical.com [91.217.199.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D031A90EB for ; Tue, 14 Apr 2015 06:14:12 -0700 (PDT) Received: from MUC-SRV-MAIL10.advaoptical.com (muc-srv-mail10.advaoptical.com [172.20.1.59]) by muc-vsrv-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t3EDE9aS002820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Apr 2015 15:14:10 +0200 Received: from MUC-S-EX13B.advaoptical.com (172.20.1.17) by MUC-SRV-MAIL10.advaoptical.com (172.20.1.59) with Microsoft SMTP Server (TLS) id 14.3.210.2; Tue, 14 Apr 2015 15:14:09 +0200 Received: from MUC-S-EX13B.advaoptical.com (172.20.1.17) by MUC-S-EX13B.advaoptical.com (172.20.1.17) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 14 Apr 2015 15:14:09 +0200 Received: from MUC-S-EX13B.advaoptical.com ([fe80::f1d8:4863:55fc:7577]) by MUC-S-EX13B.advaoptical.com ([fe80::f1d8:4863:55fc:7577%15]) with mapi id 15.00.1076.000; Tue, 14 Apr 2015 15:14:09 +0200 From: =?iso-8859-2?Q?Pawe=B3_Brzozowski?= To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTcZTio1+Axq0G8BPt0IMWk1Z1MfYIA Date: Tue, 14 Apr 2015 13:14:09 +0000 Message-ID: <9c5af0b9fb784d5ea947a636ddeab503@MUC-S-EX13B.advaoptical.com> References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: pl-PL, de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.27.50] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-14_03:2015-04-14,2015-04-14,1970-01-01 signatures=0 Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:14:24 -0000 Yes/support.=20 Regards, Pawel -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, April 13, 2015 2:08 PM To: TEAS WG Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send e= mail to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the documen= t. If yes, please also feel free to provide comments you'd like to see add= ressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and = the intent is for this work to serve as the foundation for the WG's normal = activities in this area, i.e., the document is the starting point for the W= G -- not a finished product. The DT will be closed once we have a WG docum= ent on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Tue Apr 14 06:24:47 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA4B1A90D0 for ; Tue, 14 Apr 2015 06:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyI2BZiDI_Id for ; Tue, 14 Apr 2015 06:24:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751D71A9127 for ; Tue, 14 Apr 2015 06:24:39 -0700 (PDT) Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BN1PR05MB042.namprd05.prod.outlook.com (10.255.202.147) with Microsoft SMTP Server (TLS) id 15.1.112.19; Tue, 14 Apr 2015 13:24:36 +0000 Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.243]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.14.243]) with mapi id 15.01.0112.000; Tue, 14 Apr 2015 13:24:36 +0000 From: Gert Grammel To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTbMudrwZEcskupvayDZge+CZ1MgBuw Date: Tue, 14 Apr 2015 13:24:36 +0000 Message-ID: References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [193.110.55.14] authentication-results: labn.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB042; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(164054003)(52044002)(40100003)(2656002)(87936001)(76176999)(54356999)(2950100001)(2900100001)(99286002)(102836002)(74316001)(50986999)(19580395003)(15975445007)(66066001)(86362001)(19580405001)(62966003)(92566002)(46102003)(76576001)(77156002)(230783001)(4001410100001)(122556002)(106116001)(33656002)(107886001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB042; H:BN1PR05MB041.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN1PR05MB042; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB042; x-forefront-prvs: 054642504A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2015 13:24:36.1486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB042 Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:24:46 -0000 Support Gert -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: 13 April 2015 20:08 To: TEAS WG Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send e= mail to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the documen= t. If yes, please also feel free to provide comments you'd like to see add= ressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and = the intent is for this work to serve as the foundation for the WG's normal = activities in this area, i.e., the document is the starting point for the W= G -- not a finished product. The DT will be closed once we have a WG docum= ent on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Tue Apr 14 06:44:28 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458931A9232 for ; Tue, 14 Apr 2015 06:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jWshUJ87wLt for ; Tue, 14 Apr 2015 06:44:25 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE04B1A9169 for ; Tue, 14 Apr 2015 06:44:24 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t3EDiMoE029722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Apr 2015 09:44:22 -0400 Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 14 Apr 2015 09:44:22 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 14 Apr 2015 09:44:22 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1076.000; Tue, 14 Apr 2015 09:44:22 -0400 From: Aihua Guo To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTdzcem8DWRs0me5n5jPA58k51MhYUg Date: Tue, 14 Apr 2015 13:44:20 +0000 Message-ID: References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-14_04:2015-04-14,2015-04-14,1970-01-01 signatures=0 Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 13:44:27 -0000 Yes, support. Aihua -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, April 13, 2015 2:08 PM To: TEAS WG Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send e= mail to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the documen= t. If yes, please also feel free to provide comments you'd like to see add= ressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and = the intent is for this work to serve as the foundation for the WG's normal = activities in this area, i.e., the document is the starting point for the W= G -- not a finished product. The DT will be closed once we have a WG docum= ent on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Tue Apr 14 07:01:33 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DA61A9237 for ; Tue, 14 Apr 2015 07:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddUyAqrYWyJb for ; Tue, 14 Apr 2015 07:01:24 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9E51A1A50 for ; Tue, 14 Apr 2015 07:01:10 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-8d-552cbaa99f57 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 2E.81.17241.9AABC255; Tue, 14 Apr 2015 08:58:49 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Tue, 14 Apr 2015 10:01:00 -0400 From: Jeff Tantsura To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdrtuLzgEax8vZE+urnv5kInJrQ== Date: Tue, 14 Apr 2015 14:00:59 +0000 Message-ID: References: <552C0611.70500@labn.net> <4A1562797D64E44993C5CBF38CF1BE48128C928B@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48128C928B@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <59E04D7E0B3CC24A886E8BD27C1822D2@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXSPt+7KXTqhBkv+S1l0NL9lsWj9sYPF gcljyZKfTB4fNjWzBTBFcdmkpOZklqUW6dslcGUc3b6eqaCZu+LKpOmMDYx/OLoYOTkkBEwk Wl7fYoWwxSQu3FvP1sXIxSEkcJRR4uSSG1DOckaJG2evs4NUsQkYSPz/dpwFxBYRsJLoOLCT CcQWFgiU+HX1OlQ8SGLt+0eMELaexImPC8BsFgFViauHZgPZHBy8AuYSq99ZgYSFBDIlpq9Z xAoS5hTwk3i/RBgkzAh0z/dTa8CmMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//A7tfFGjTsw2b 2SHiShKTlp5jhejVk7gxdQobhG0tMX/aZChbW2LZwtdgc3gFBCVOznzCMoFRfBaSdbOQtM9C 0j4LSfssJO0LGFlXMXKUFqeW5aYbGW5iBMbUMQk2xx2MCz5ZHmIU4GBU4uFVYNEJFWJNLCuu zD3EKM3BoiTOW3blYIiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxqmvLzrbb/63ened29EJ OufOGy1K5LyR0aJgZPxTeH/88dXMbeylWlY7dTY42Uz1v+czN09y9f+XsR+/qpQdUnyfkG0T /Ppd8a7OXpHHrxqrRN7t3LdogfKBJveZTgxaTwRmJGef3e0qstz+FUvNmRnFBn1cAUqS8bsn nvh9/khtfRcvn52emRJLcUaioRZzUXEiAPoesGKKAgAA Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 14:01:32 -0000 Yes/support Cheers, Jeff >>From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger >> Sent: luned=EC 13 aprile 2015 20:08 >> To: TEAS WG >> Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG >> document >>=20 >> All, >>=20 >> This is start of a two week poll on making >> draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please >>send >> email to the list indicating "yes/support" or "no/do not support". >> If indicating no, please state your technical reservations with the >>document. >> If yes, please also feel free to provide comments you'd like to see >>addressed >> once the document is a WG document. >>=20 >> This document is the product of the TE Topology YANG Model Design Team >> and the intent is for this work to serve as the foundation for the WG's >>normal >> activities in this area, i.e., the document is the starting point for >>the WG -- >> not a finished product. The DT will be closed once we have a WG >>document >> on this topic. >>=20 >> The poll ends Monday April 27th >> Thanks, >> Lou (and Pavan, who is a co-author) >>=20 >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Tue Apr 14 08:49:24 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E941B2D5B for ; Tue, 14 Apr 2015 08:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVNAToCtHWoN for ; Tue, 14 Apr 2015 08:49:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AB11B2D5C for ; Tue, 14 Apr 2015 08:49:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRJ75901; Tue, 14 Apr 2015 15:49:14 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Apr 2015 16:49:13 +0100 Received: from DFWEML706-CHM.china.huawei.com ([10.193.5.225]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Tue, 14 Apr 2015 08:49:07 -0700 From: Leeyoung To: TEAS WG , Lou Berger Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTeIlbXDO38sUOKAhCKgVy2C51MkKyAgAAYB/A= Date: Tue, 14 Apr 2015 15:49:06 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729CAFD0D@dfweml706-chm> References: <552C0611.70500@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 15:49:23 -0000 Yes/support. My comment is that there should be a clear scope of this model to be applie= d to in the introduction section. Specifically, if this is a device model o= r a controller-controller model or both. It will be also good to describe w= hat information element is being captured by the YANG model before jumping = into the YANG model. =20 Young -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Monday, April 13, 2015 1:08 PM To: TEAS WG Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send e= mail to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the documen= t. If yes, please also feel free to provide comments you'd like to see add= ressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and = the intent is for this work to serve as the foundation for the WG's normal = activities in this area, i.e., the document is the starting point for the W= G -- not a finished product. The DT will be closed once we have a WG docum= ent on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Tue Apr 14 16:34:10 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8B1B3092 for ; Tue, 14 Apr 2015 16:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpDJzFackBQB for ; Tue, 14 Apr 2015 16:34:06 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226581B3091 for ; Tue, 14 Apr 2015 16:34:06 -0700 (PDT) Received: by qkx62 with SMTP id 62so45617133qkx.0 for ; Tue, 14 Apr 2015 16:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fhu3EezNQ5UwINZInW/ZfHza/X5cB7xpJCkNU6g3qvg=; b=KL5uXQ1Ky2NmVy/9B36IuO7bRJzOmWVsbCWBDNgpINYhEz6wnHGVDIpcb1VZiLWnfA LxNgnjic/YQ4xbHmCw/kdps0Igu9jSDbO162oHt5m/sRUtyb5NUmGJo+mZqTOFR3Gys6 9AJBApVgff6qdEUeN0rijB3Na/OGzfQiS0NPI9Vv4vJLka2rMVqCJzMknr5Irk4uYXCl CLzuJrz9mKcpI4pFCnxvMmV/62+UWcSoZxWdNOIy1xWecNZrDnkJHdBhXL2rcCVMLPTj JhLjh2gbaXcqjM5zpusCPT2iZgww/8yyYFSN9el2oR5X2d0pbSdhzFOR7UbJ38CIRE0h fBgw== MIME-Version: 1.0 X-Received: by 10.55.27.42 with SMTP id b42mr45842368qkb.53.1429054432371; Tue, 14 Apr 2015 16:33:52 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Tue, 14 Apr 2015 16:33:52 -0700 (PDT) In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729CAE56F@dfweml706-chm> References: <7AEB3D6833318045B4AE71C2C87E8E1729CAE56F@dfweml706-chm> Date: Tue, 14 Apr 2015 19:33:52 -0400 Message-ID: From: Vishnu Pavan Beeram To: Leeyoung Content-Type: multipart/alternative; boundary=001a1147ea3cce69e60513b7a9c1 Archived-At: Cc: "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] FW: New Version Notification for draft-lee-teas-actn-requirements-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 23:34:08 -0000 --001a1147ea3cce69e60513b7a9c1 Content-Type: text/plain; charset=UTF-8 @Young - Thanks for uploading the requirements document. WG, Please review this document and let the authors know your comments. Regards, -Pavan On Wed, Apr 8, 2015 at 1:44 PM, Leeyoung wrote: > Hi, > > Here's the ACTN requirements draft uploaded. This update incorporated > comments from the WG meeting in Dallas. > > > Thanks, > Young (on behalf of co-authors) > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, April 08, 2015 12:38 PM > To: Daniele Ceccarelli; Dhruv Dhody; Leeyoung; Khuzema Pithewan; Daniele > Ceccarelli; Dhruv Dhody; Leeyoung; Sergio Belotti; Khuzema Pithewan; Sergio > Belotti > Subject: New Version Notification for > draft-lee-teas-actn-requirements-00.txt > > > A new version of I-D, draft-lee-teas-actn-requirements-00.txt > has been successfully submitted by Young Lee and posted to the IETF > repository. > > Name: draft-lee-teas-actn-requirements > Revision: 00 > Title: Requirements for Abstraction and Control of Transport > Networks > Document date: 2015-04-08 > Group: Individual Submission > Pages: 27 > URL: > http://www.ietf.org/internet-drafts/draft-lee-teas-actn-requirements-00.txt > Status: > https://datatracker.ietf.org/doc/draft-lee-teas-actn-requirements/ > Htmlized: > http://tools.ietf.org/html/draft-lee-teas-actn-requirements-00 > > > Abstract: > This draft provides a set of requirements for abstraction and > control of transport networks. > > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a1147ea3cce69e60513b7a9c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
@Young - Thanks for uploading the requ= irements document.

WG,
Please review this document a= nd let the authors know your comments.

Regards,
-Pava= n

On Wed, Apr = 8, 2015 at 1:44 PM, Leeyoung <leeyoung@huawei.com> wrote:<= br>
H= i,

Here's the ACTN requirements draft uploaded. This update incorporated c= omments from the WG meeting in Dallas.


Thanks,
Young (on behalf of co-authors)

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Wednesday, April 08, 2015 12:38 PM
To: Daniele Ceccarelli; Dhruv Dhody; Leeyoung; Khuzema Pithewan; Daniele Ce= ccarelli; Dhruv Dhody; Leeyoung; Sergio Belotti; Khuzema Pithewan; Sergio B= elotti
Subject: New Version Notification for draft-lee-teas-actn-requirements-00.t= xt


A new version of I-D, draft-lee-teas-actn-requirements-00.txt
has been successfully submitted by Young Lee and posted to the IETF reposit= ory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-lee-teas-actn-requireme= nts
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Requirements for Abstraction and C= ontrol of Transport Networks
Document date:=C2=A0 2015-04-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 27
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-lee-teas-actn-requirements-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://data= tracker.ietf.org/doc/draft-lee-teas-actn-requirements/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org= /html/draft-lee-teas-actn-requirements-00


Abstract:
=C2=A0 =C2=A0This draft provides a set of requirements for abstraction and<= br> =C2=A0 =C2=A0control of transport networks.






Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

--001a1147ea3cce69e60513b7a9c1-- From nobody Tue Apr 14 18:13:04 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CA21B2AF7 for ; Tue, 14 Apr 2015 18:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rp4jZ351wwZX for ; Tue, 14 Apr 2015 18:13:01 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A071B2AF5 for ; Tue, 14 Apr 2015 18:13:01 -0700 (PDT) Received: by qkgx75 with SMTP id x75so47775978qkg.1 for ; Tue, 14 Apr 2015 18:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B0GoIKSR4vdA2fCzsXGDGZpOslYTlqdjsBxqYMmeu+k=; b=VmDt68hOR/YI9uYiaEqnq8sPcGjvGhzeHnxMaJjmgfI1PtJVx5X5ZvPuSI9QD4QNbx 7n6mG18knOxRkyHI23JdVp5Pcaz2V/4C7VvZL/HCnm9M4ae0OdCk4ehfEyATWCrW4vKf BmMt85J8kHygYVGVqSIlwqwpcTEWjUcftKHzbI+Dpm6oOKijj2T5i6A+BOZ1GtJ1MPWc pe6BsQ7OWYjTDjXgHcqBaVAJEsqRQRs2EQDnq0crDDWwTCoZx3c/gBA08ukj+hX1wSzL GmGbkNibGg24ZX4GjRzPvPNIaWoBR7L0+WeGtrUdi7WuyXuZugvJbHGwL/9n/XgB3gVe bnyA== MIME-Version: 1.0 X-Received: by 10.55.23.162 with SMTP id 34mr45839982qkx.76.1429060372677; Tue, 14 Apr 2015 18:12:52 -0700 (PDT) Received: by 10.140.19.109 with HTTP; Tue, 14 Apr 2015 18:12:52 -0700 (PDT) In-Reply-To: References: <7AEB3D6833318045B4AE71C2C87E8E1729CAE56F@dfweml706-chm> Date: Tue, 14 Apr 2015 21:12:52 -0400 Message-ID: From: Vishnu Pavan Beeram To: Leeyoung Content-Type: multipart/alternative; boundary=001a11473d0ce049890513b90b7c Archived-At: Cc: "TEAS WG \(teas@ietf.org\)" Subject: Re: [Teas] FW: New Version Notification for draft-lee-teas-actn-requirements-00.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 01:13:03 -0000 --001a11473d0ce049890513b90b7c Content-Type: text/plain; charset=UTF-8 ...please do send the comments to the list. -Pavan On Tue, Apr 14, 2015 at 7:33 PM, Vishnu Pavan Beeram wrote: > @Young - Thanks for uploading the requirements document. > > WG, > Please review this document and let the authors know your comments. > > Regards, > -Pavan > > > On Wed, Apr 8, 2015 at 1:44 PM, Leeyoung wrote: > >> Hi, >> >> Here's the ACTN requirements draft uploaded. This update incorporated >> comments from the WG meeting in Dallas. >> >> >> Thanks, >> Young (on behalf of co-authors) >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, April 08, 2015 12:38 PM >> To: Daniele Ceccarelli; Dhruv Dhody; Leeyoung; Khuzema Pithewan; Daniele >> Ceccarelli; Dhruv Dhody; Leeyoung; Sergio Belotti; Khuzema Pithewan; Sergio >> Belotti >> Subject: New Version Notification for >> draft-lee-teas-actn-requirements-00.txt >> >> >> A new version of I-D, draft-lee-teas-actn-requirements-00.txt >> has been successfully submitted by Young Lee and posted to the IETF >> repository. >> >> Name: draft-lee-teas-actn-requirements >> Revision: 00 >> Title: Requirements for Abstraction and Control of Transport >> Networks >> Document date: 2015-04-08 >> Group: Individual Submission >> Pages: 27 >> URL: >> http://www.ietf.org/internet-drafts/draft-lee-teas-actn-requirements-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-lee-teas-actn-requirements/ >> Htmlized: >> http://tools.ietf.org/html/draft-lee-teas-actn-requirements-00 >> >> >> Abstract: >> This draft provides a set of requirements for abstraction and >> control of transport networks. >> >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas >> > > --001a11473d0ce049890513b90b7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
...please do send the comments to the list.

-Pavan

On Tue, Apr 14, 2015 at 7:33 PM, Vishnu Pavan Beeram <vis= hnupavan@gmail.com> wrote:
=
@Young - Thanks for uploading the requ= irements document.

WG,
Please review this document a= nd let the authors know your comments.

Regards,
-Pava= n


On Wed, Apr 8, 2015 at 1:44 PM, Leeyoung <<= a href=3D"mailto:leeyoung@huawei.com" target=3D"_blank">leeyoung@huawei.com= > wrote:
Hi,

Here's the ACTN requirements draft uploaded. This update incorporated c= omments from the WG meeting in Dallas.


Thanks,
Young (on behalf of co-authors)

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, April 08, 2015 12:38 PM
To: Daniele Ceccarelli; Dhruv Dhody; Leeyoung; Khuzema Pithewan; Daniele Ce= ccarelli; Dhruv Dhody; Leeyoung; Sergio Belotti; Khuzema Pithewan; Sergio B= elotti
Subject: New Version Notification for draft-lee-teas-actn-requirements-00.t= xt


A new version of I-D, draft-lee-teas-actn-requirements-00.txt
has been successfully submitted by Young Lee and posted to the IETF reposit= ory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-lee-teas-actn-requireme= nts
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Requirements for Abstraction and C= ontrol of Transport Networks
Document date:=C2=A0 2015-04-08
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 27
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-lee-teas-actn-requirements-00.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://data= tracker.ietf.org/doc/draft-lee-teas-actn-requirements/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org= /html/draft-lee-teas-actn-requirements-00


Abstract:
=C2=A0 =C2=A0This draft provides a set of requirements for abstraction and<= br> =C2=A0 =C2=A0control of transport networks.






Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas


--001a11473d0ce049890513b90b7c-- From nobody Wed Apr 15 09:48:14 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE221B3629 for ; Wed, 15 Apr 2015 09:43:07 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khu1vMdLU7Rg for ; Wed, 15 Apr 2015 09:43:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9A81B3620 for ; Wed, 15 Apr 2015 09:43:05 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id DA2102DC194 for ; Wed, 15 Apr 2015 18:43:03 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id BB838238062 for ; Wed, 15 Apr 2015 18:43:03 +0200 (CEST) Received: from [10.193.71.25] (10.197.38.2) by PEXCVZYH01.corporate.adroot.infra.ftgroup (10.114.1.186) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 15 Apr 2015 18:42:52 +0200 Message-ID: <19332_1429116183_552E9517_19332_1756_1_552E950C.10801@orange.com> Date: Wed, 15 Apr 2015 18:42:52 +0200 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "pce@ietf.org" Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.197.38.2] X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.13.120621 Archived-At: X-Mailman-Approved-At: Wed, 15 Apr 2015 09:48:12 -0700 Subject: [Teas] PCE WG Last Call on draft-ietf-pce-pcep-domain-sequence-07 X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "pce@ietf.org" List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 16:43:07 -0000 Dear PCE & TEAS WGs, This message initiates a 2-week WG last call on draft-ietf-pce-pcep-domain-sequence-07. Please send your comments to the PCE mailing list by Wednesday April 29. Thanks, JP & Julien _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Wed Apr 15 11:03:04 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E881A0016 for ; Wed, 15 Apr 2015 11:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pNAms0dE64O for ; Wed, 15 Apr 2015 11:03:01 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5101D1A000F for ; Wed, 15 Apr 2015 11:03:01 -0700 (PDT) Received: by widdi4 with SMTP id di4so164812476wid.0 for ; Wed, 15 Apr 2015 11:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mgdi8VF/03BLk965J+jm9hJJRAAH8Q5bfxEYEGV0/v8=; b=oU0heoddscZ5nDVShJE5Zp1L5ahqmIvkM0Pzr5lZQ0tPxCjEv+MnjULZ5VxbI3Kwy8 5LX6Cet+/0g1W71XUvbLyuICNYVfjGzKHbN2Hby65m6RWgULMwo+rhzAetLK/lfnI3xi g9LjEUSM9LKEF0fOvAKU3d6UW+ncjRaf3DrJqzb74TLy60GIZ47WPH1iUZ0O6HDw6WHC YFqVW8dR/cEsNpvCWWiFXN28fUWukEwUMpjJy0e57OqmLoZEy9tpg1fWm2qCse1TSFO7 DsFjVUpCM3KeHo8/st9IvB/NuXUPfm40hX21tSDGNeKmRJi6eXl7zvxhI0lcxJJafEZf x1XA== MIME-Version: 1.0 X-Received: by 10.194.121.68 with SMTP id li4mr50069852wjb.84.1429120980142; Wed, 15 Apr 2015 11:03:00 -0700 (PDT) Received: by 10.27.174.212 with HTTP; Wed, 15 Apr 2015 11:02:59 -0700 (PDT) In-Reply-To: <552C0611.70500@labn.net> References: <552C0611.70500@labn.net> Date: Wed, 15 Apr 2015 14:02:59 -0400 Message-ID: From: Cyril Margaria To: Lou Berger Content-Type: multipart/alternative; boundary=089e01176f115cd15a0513c728e6 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 18:03:03 -0000 --089e01176f115cd15a0513c728e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes/Support BR Cyril On 13 April 2015 at 14:08, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please > send email to the list indicating =E2=80=9Cyes/support=E2=80=9D or =E2=80= =9Cno/do not support=E2=80=9D. > If indicating no, please state your technical reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > This document is the product of the TE Topology YANG Model Design Team > and the intent is for this work to serve as the foundation for the WG's > normal activities in this area, i.e., the document is the starting point > for the WG -- not a finished product. The DT will be closed once we > have a WG document on this topic. > > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --089e01176f115cd15a0513c728e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes/Support

BR
Cyril

On 13 April 2= 015 at 14:08, Lou Berger <lberger@labn.net> wrote:
All,

This is start of a two week poll on making
draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please
send email to the list indicating =E2=80=9Cyes/support=E2=80=9D or =E2=80= =9Cno/do not support=E2=80=9D.
If indicating no, please state your technical reservations with the
document.=C2=A0 If yes, please also feel free to provide comments you'd= like
to see addressed once the document is a WG document.

This document is the product of the TE Topology YANG Model Design Team
and the intent is for this work to serve as the foundation for the WG's=
normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product.=C2=A0 The DT will be closed once we have a WG document on this topic.

The poll ends Monday April 27th
Thanks,
Lou (and Pavan, who is a co-author)

_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

--089e01176f115cd15a0513c728e6-- From nobody Wed Apr 15 21:20:50 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0461B2E35 for ; Wed, 15 Apr 2015 21:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xqMfPUn9PsU for ; Wed, 15 Apr 2015 21:20:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AF41B2E31 for ; Wed, 15 Apr 2015 21:20:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUX76764; Thu, 16 Apr 2015 04:20:46 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 16 Apr 2015 05:20:46 +0100 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.185]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0158.001; Thu, 16 Apr 2015 09:50:42 +0530 From: Dhruv Dhody To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTewETq3gw+E0+C5kHmcEFIK51PDHrg Date: Thu, 16 Apr 2015 04:20:41 +0000 Message-ID: <23CE718903A838468A8B325B80962F9B870969B5@BLREML509-MBX.china.huawei.com> References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.146.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 04:20:50 -0000 Support!=20 +1 to comments from Paul, Young and Xian Regards, Dhruv > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 13 April 2015 23:38 > To: TEAS WG > Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docume= nt >=20 > All, >=20 > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send > email to the list indicating "yes/support" or "no/do not support". > If indicating no, please state your technical reservations with the docum= ent. > If yes, please also feel free to provide comments you'd like to see addre= ssed > once the document is a WG document. >=20 > This document is the product of the TE Topology YANG Model Design Team an= d > the intent is for this work to serve as the foundation for the WG's norma= l > activities in this area, i.e., the document is the starting point for the= WG > -- not a finished product. The DT will be closed once we have a WG docum= ent > on this topic. >=20 > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Wed Apr 15 23:27:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FE91B29CA for ; Wed, 15 Apr 2015 23:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF_-PPyE7n4C for ; Wed, 15 Apr 2015 23:27:17 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767BD1B29C9 for ; Wed, 15 Apr 2015 23:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1085; q=dns/txt; s=iport; t=1429165637; x=1430375237; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cQKqxMj5xeamo3Wc8N/fawO8ShBZDw4T8IXiFaHaqYo=; b=SCaiSibL/ThGzcq3FEIlvK/yBsOF6bk8uqctSFr5tsfWXumlynECuGkV /W3XaKJ72NzztQVhrMU+N8dQWDuRQbiynCQyY8uU40G+5Iobys20cNdv0 SLWUo/48EuNA9foQnp5tJTcKrupu8LSWpLtcJe4XdwkfcQRq8a10c0n1g Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BYBADkVC9V/5tdJa1cgwxSXAXFDWYJgUUKhgMCgT44FAEBAQEBAQF9hCABAQEDAQEBAWsLBQsCAQgOCi4nCyUCBA4FiCIIDcYyAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLK4QZEQEeMweDF4EWBZBzI4oZgR2DOYxYg00ig29vgQs5fwEBAQ X-IronPort-AV: E=Sophos;i="5.11,586,1422921600"; d="scan'208";a="141698445" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 16 Apr 2015 06:27:16 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t3G6RG2v031679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Apr 2015 06:27:16 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.189]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 16 Apr 2015 01:27:16 -0500 From: "Giovanni Martinelli (giomarti)" To: Lou Berger Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTcbfa8x18IX0uq3dKWZCppBJ1PhGyA Date: Thu, 16 Apr 2015 06:27:15 +0000 Message-ID: <44F0A1A1-42E0-400F-A816-ADAF5AEC8B40@cisco.com> References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.148.212.128] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4658A857D232E441A915EBB2CE04E8DA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 06:27:19 -0000 yes/support ~G > On 13 Apr 2015, at 20:08, Lou Berger wrote: >=20 > All, >=20 > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please > send email to the list indicating =93yes/support=94 or =93no/do not suppo= rt=94. > If indicating no, please state your technical reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. >=20 > This document is the product of the TE Topology YANG Model Design Team > and the intent is for this work to serve as the foundation for the WG's > normal activities in this area, i.e., the document is the starting point > for the WG -- not a finished product. The DT will be closed once we > have a WG document on this topic. >=20 > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas From nobody Thu Apr 16 16:58:14 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D641A033B; Thu, 16 Apr 2015 16:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.2 X-Spam-Level: X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKOP9Gn9E8Hz; Thu, 16 Apr 2015 16:58:04 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A599C1A028A; Thu, 16 Apr 2015 16:58:03 -0700 (PDT) X-AuditID: c618062d-f79686d0000030a8-04-552ff59759ef Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.95.12456.795FF255; Thu, 16 Apr 2015 19:47:04 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 16 Apr 2015 19:57:58 -0400 From: Gregory Mirsky To: Huaimo Chen , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AQHQdUsbhXhJtQ5lC02wWl3AD+NymZ1QUc6g Date: Thu, 16 Apr 2015 23:57:58 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B94CD49@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXSPn+6Mr/qhBlOPM1lcfPiU2WLr0yuM FreWrmS1+PxnG6NF09xdTBatP3awOLB5tBx5y+qxZMlPJo8vlz+zBTBHcdmkpOZklqUW6dsl cGVMObyfreDyG8aKGx8WMzYwLj7D2MXIySEhYCJx9cFxJghbTOLCvfVsILaQwFFGifvTNboY uYDs5YwSXe8+s4Mk2ASMJF5s7GEHSYgIfGaU+LL6CStIglnAS+LS82nMILawgLtE180DYLaI gIfEimtzgKZyANlGEm83uIKEWQRUJV7uewZWwivgK3Fv/zw2iGUzGSV2rPwMdgWnQJjE7D3z wK5jBLru+6k1TBC7xCVuPZkPdbWAxJI955khbFGJl4//sULYihL7+qezQ9TnSzye3gW1TFDi 5MwnLBMYRWchGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FSNHaXFqWW66 kcEmRmA0HpNg093BuOel5SFGAQ5GJR7eBeL6oUKsiWXFlbmHGKU5WJTEeRc9OBgiJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgTGaZffp/YX/tk/e+2CxgsqKmKinqqyRxlOPHfH6UN54SeVa xuE5B87JFCkK/Q/8bPz9Xkb6t3b1eTpFV+oVLI0erj03W3TDt5JTs5fee/0gbkd2jZ2x7vvU ksfF0oGXDV+v/bI6tLV5fSLDA3XbdQ0iXEILapjun35+la2ofPJm/dspy/LVbzgrsRRnJBpq MRcVJwIAJY6OpKcCAAA= Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [Teas] [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 23:58:10 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Huaimo, thank you for kind consideration of my comments. Please find more in-lined = and tagged GIM>> notes. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Sunday, April 12, 2015 11:04 AM To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org;= teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, April 12, 2015 2:04 AM To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Dear Editors, chairs, WG community, please find my comments to the current version of your work below: * Introduction o The first paragraph may leave an impression that local protection of tr= ansit LSRs is not being already addressed, neither by RFC 4090, nor RFC 487= 5; [Huaimo] Will revise it accordingly. o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. [Huaimo] It seems that "global protection" is better here since we mentione= d "local protection" here. It seems that Global Protection is used often. * Section 3.1 o Third paragraph contains the following requirement: "For a P2P LSP, after the primary ingress fails, the backup ingress must us= e a method to reliably detect the failure of the primary ingress before the= PATH message for the LSP expires at the next hop of the primary ingress." But that is not obvious that such requirement is really needed. Since this = is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to c= ontrol switchover. Especially since, as noted in the last paragraph of Sect= ion 2.1, primary and backup ingress nodes must be connected by a logical li= nk, which in general case will be a tunnel. Thus this solution puts a requi= rement, implicitly though, to instantiate a tunnel per protection group, tu= nnel that would not be used to carry traffic. [Huaimo] The requirement above seems necessary. If the backup ingress does = not detect the failure of the primary ingress before the timer for the PATH= message for the LSP at the next hop of the primary ingress expires, the LS= P will be down after the primary ingress fails. If the backup ingress detec= ts the failure and sends/refreshes the PATH message to the next hop before = the timer expires after the primary egress fails, the LSP will continue bei= ng up and carry the traffic from the backup ingress via the backup LSP. For a P2P LSP, it seems that MP2MP construct is not used in RFC 4090 to pro= tect a transit node of a P2P LSP. The logical link between the primary ingr= ess and the backup ingress can be a direct link or a tunnel. It seems that = a direct link is common. GIM>> I think it is strange to cite requirement on scale of seconds if not = tens of seconds in discussion of method of local protection that supposed t= o perform protection switchover in sub-second if not sub-50msec time. o In addition, what is importance of requirement quoted above: "... before the PATH message for the LSP expires at the next hop of the pri= mary ingress" [Huaimo] This seems very important. If the timer for the PATH message for t= he LSP at the next hop of the primary egress expires, then the LSP will be = down. So the PATH message must be refreshed before the timer for the PATH m= essage for the LSP expires at the next hop of the primary LSP. GIM>> As noted above, these seem as requirements of different scale. o Fourth paragraph makes very questionable assumption in: "After the primary ingress fails, it will not be reachable after routing co= nvergence." I believe that if OAM session is between two nodes there's no reliable way = to differentiate between node and link failure. Thus, to declare a node unr= eachable there must be N tunnels for N OAM sessions that monitor all possib= le paths between two nodes. (Note, that if there was no requirement to use = a tunnel between primary and backup ingress, multi-hop BFD could be used th= ough its detection time being limited by IGP convergence, which may be too = slow comparing with your requirement of tens milliseconds). [Huaimo] It is true that "After the primary ingress fails, it will not be r= eachable after routing convergence." From routing's point of view, there i= s no need for us to have any OAM session between two nodes. The timer for a= PATH message seems in tens of seconds. Routing convergence is not limited = to tens of milliseconds. GIM>> Routing convergence may take seconds. Is that acceptable as failure d= etection time for local protection? Protection switchover expected to be fa= st, perhaps on sub-50 msec scale. From TDM world we carry 10 msec failure d= etection, and BFD implementations can support that. but here, it appears, y= ou describe failure detection mechanism with detection time on scale of sec= onds if not tens of seconds. * Section 5.1 o Regarding "Ingress local protection in use" flag As demonstrated earlier, backup ingress node has no reliable way to detect = that primary ingress node is not reachable to the Source and thus protectio= n must be activated. [Huaimo] It seems that there is no need for the backup ingress to detect wh= ether the primary ingress is reachable to the Source and the focus is on th= e failure of the primary ingress. GIM>> In that case, the text is not needed either. Considering that backup ingress may initiate described in the document acti= ons not when primary ingress became unavailable to Source, I believe that c= ases that may produce false positives must be removed along with extensions= that intended to support these cases. In my opinion, the only viable case = of ingress protection is Source-centric where Source monitors availability = of both primary and backup ingress nodes and controls traffic switchover. I= 'd ask WG to discuss these comments and, if agreed, ask Editors to make app= ropriate changes to the document. [Huaimo] It seems that the current version already indicates that the sourc= e-detect (i.e., Source detects the failure of the primary ingress and switc= hes traffic to the backup ingress when the primary ingress fails) is used. = There were a few of modes for detecting the failure of the primary ingress= that were proposed in the previous versions of the document. A different m= ode may have a different control on the traffic switch over and/or forwardi= ng. After discussions, the current version selects the source-detect. GIM>> If this is historical part, then it may be moved to Appendix or taken= from the document altogether. Can you give more details about the cases in which false positives may be p= roduced? GIM>> If current proposal is limited to Source-detect case only then possi= bility of false positive/negative depends on Source to Ingress connection a= nd OAM mechanism used. But that is deployment issue and is outside of scope= of this document Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Huaimo,<= /span>

thank you for kind con= sideration of my comments. Please find more in-lined and tagged GIM>>= notes.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Huaimo C= hen [mailto:huaimo.chen@huawei.com]
Sent: Sunday, April 12, 2015 11:04 AM
To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ie= tf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf= .org] On Behalf Of Gregory Mirsky
Sent: Sunday, April 12, 2015 2:04 AM
To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection<= o:p>

 

Dear Editors, chairs, WG community,

please find my comments to the current version of yo= ur work below:

·         Introduction

o   The first paragraph may leave an impression = that local protection of transit LSRs is not being already addressed, neith= er by RFC 4090, nor RFC 4875;

[Huaimo] Will revise i= t accordingly.

o   I think that “global protection”= is not commonly used term, “end-to-end protection” seems to be= commonly used instead.

[Huaimo] It seems that= “global protection” is better here since we mentioned “l= ocal protection” here. It seems that Global Protection is used often.=

·         Section 3.1

o   Third paragraph contains the following requi= rement:

“For a P2P LSP, af= ter the primary ingress fails, the backup ingress must use a method to reli= ably detect the failure of the primary ingress before the PATH message for = the LSP expires at the next hop of the primary ingress.”

But that is not obvious = that such requirement is really needed. Since this is RSVP-TE LSP, why not = to use MP2MP construct and let the Source node to control switchover. Espec= ially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a lo= gical link, which in general case will be a tunnel. Thus this solution puts= a requirement, implicitly though, to instantiate a tunnel per protection g= roup, tunnel that would not be used to carry traffic.

[Huaimo] The requireme= nt above seems necessary. If the backup ingress does not detect the failure= of the primary ingress before the timer for the PATH message for the LSP a= t the next hop of the primary ingress expires, the LSP will be down after the primary ingress fails. If the back= up ingress detects the failure and sends/refreshes the PATH message to the = next hop before the timer expires after the primary egress fails, the LSP w= ill continue being up and carry the traffic from the backup ingress via the backup LSP. =

For a P2P LSP, it seem= s that MP2MP construct is not used in RFC 4090 to protect a transit node of= a P2P LSP. The logical link between the primary ingress and the backup ing= ress can be a direct link or a tunnel. It seems that a direct link is common.

GIM>> I think it= is strange to cite requirement on scale of seconds if not tens of seconds = in discussion of method of local protection that supposed to perform protec= tion switchover in sub-second if not sub-50msec time.

 

o   In addition, what is importance of requireme= nt quoted above:

“… before th= e PATH message for the LSP expires at the next hop of the primary ingress&#= 8221;

[Huaimo] This seems ve= ry important. If the timer for the PATH message for the LSP at the next hop= of the primary egress expires, then the LSP will be down. So the PATH mess= age must be refreshed before the timer for the PATH message for the LSP expires at the next hop of the primary LS= P.

GIM>> As noted a= bove, these seem as requirements of different scale.

 

o   Fourth paragraph makes very questionable ass= umption in:

“After the primary= ingress fails, it will not be reachable after routing convergence.”<= o:p>

I believe that if OAM se= ssion is between two nodes there’s no reliable way to differentiate b= etween node and link failure. Thus, to declare a node unreachable there mus= t be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirem= ent to use a tunnel between primary and backup ingress, multi-hop BFD could= be used though its detection time being limited by IGP convergence, which = may be too slow comparing with your requirement of tens milliseconds).

[Huaimo] It is true th= at “After the primary ingress fails, it will not be reachable after r= outing convergence.”  From routing’s point of view, there = is no need for us to have any OAM session between two nodes. The timer for a PATH message seems in tens of seconds. Routing convergence= is not limited to tens of milliseconds.

GIM>> Routing co= nvergence may take seconds. Is that acceptable as failure detection time fo= r local protection? Protection switchover expected to be fast, perhaps on s= ub-50 msec scale. From TDM world we carry 10 msec failure detection, and BFD implementations can support that. but h= ere, it appears, you describe failure detection mechanism with detection ti= me on scale of seconds if not tens of seconds.

 

·         Section 5.1

o   Regarding “Ingress local protection in= use” flag

As demonstrated earlier,= backup ingress node has no reliable way to detect that primary ingress nod= e is not reachable to the Source and thus protection must be activated.

[Huaimo] It seems that= there is no need for the backup ingress to detect whether the primary ingr= ess is reachable to the Source and the focus is on the failure of the prima= ry ingress.

GIM>> In that ca= se, the text is not needed either.

 

Considering that backup ingress may initiate describ= ed in the document actions not when primary ingress became unavailable to S= ource, I believe that cases that may produce false positives must be remove= d along with extensions that intended to support these cases. In my opinion, the only viable case of ingress pro= tection is Source-centric where Source monitors availability of both primar= y and backup ingress nodes and controls traffic switchover. I’d ask W= G to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

[Huaimo] It seems that= the current version already indicates that the source-detect (i.e., Source= detects the failure of the primary ingress and switches traffic to the bac= kup ingress when the primary ingress fails) is used.  There were a few of modes for detecting the failure = of the primary ingress that were proposed in the previous versions of the d= ocument. A different mode may have a different control on the traffic switc= h over and/or forwarding.  After discussions, the current version selects the source-detect.

GIM>> If this is= historical part, then it may be moved to Appendix or taken from the docume= nt altogether.

 

Can you give more deta= ils about the cases in which false positives may be produced?

GIM>> If current= proposal is limited to Source-detect case only  then possibility of f= alse positive/negative depends on Source to Ingress connection and OAM mech= anism used. But that is deployment issue and is outside of scope of this document

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_7347100B5761DC41A166AC17F22DF1121B94CD49eusaamb103erics_-- From nobody Thu Apr 16 17:01:25 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E2A1A037D for ; Thu, 16 Apr 2015 17:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pD8xJC9tu2S for ; Thu, 16 Apr 2015 17:01:23 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 9E9CD1A038B for ; Thu, 16 Apr 2015 17:01:23 -0700 (PDT) Received: (qmail 23414 invoked by uid 0); 17 Apr 2015 00:01:23 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 17 Apr 2015 00:01:23 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Gu1J1q00X2SSUrH01u1MJQ; Fri, 17 Apr 2015 00:01:21 -0600 X-Authority-Analysis: v=2.1 cv=ae7yw3Yt c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=SY9aFQKHIdAA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=e9J7MTPGsLIA:10 a=60CpFMp27n9GLAiktu4A:9 a=QEXdDO2ut3YA:10 a=nlUKtJe5vXgA:10 a=uCOKgLPf4YAA:10 a=-rvzrao-qfIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=2d/844zw9DugXEjBNR/DdonF/1Y54jwd0si0NWDdIzE=; b=cCMIcGvqThzY+1qyijAnp6oETtaODSFvngNNEa3L1CyG5df7siFmpTXb364YaqOWOAxQXWto6Y9FzFVsTdanHUWIInNfLNP6x2B/kOY8ZHZjKVAJgdc4cO2Z+2O0Sfkq; Received: from box313.bluehost.com ([69.89.31.113]:57390 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1Yitii-000094-8K; Thu, 16 Apr 2015 18:01:20 -0600 Message-ID: <55304D4A.9050604@labn.net> Date: Thu, 16 Apr 2015 20:01:14 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: draft-ietf-teas-lsp-diversity@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: TEAS WG Subject: [Teas] use of the FEC term in draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 00:01:24 -0000 Authors/WG, I'm a bit uncomfortable with the document's use of FEC in the context if RSVP-TE. RFC3209's usage of FEC is very loose and rfc4379 only gives an indirect definition in one context. I think that either the draft should avoid the term or it should point to a to be written formal definition of the term in the context of RSVP-TE (including in its GMPLS form). Thoughts? Lou (with any / all hats) From nobody Thu Apr 16 21:49:17 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EF81ACD01; Thu, 16 Apr 2015 21:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUfbcaDTCSxa; Thu, 16 Apr 2015 21:49:14 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FF771ACD02; Thu, 16 Apr 2015 21:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1050; q=dns/txt; s=iport; t=1429246154; x=1430455754; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9YZtQ3yLAE3Faw5m1pGUFJXIhCzD2wyCgDm3jFGCN38=; b=maXAjIls+1QOxgAcnroyEOVglsDtJ2s6xkEB8Ku+hC+dZnntMWpDkIP9 z0tjargxY9t2nNJBW6rCM2ZOg5UW9WJlUkupqNw+eOJlBJjjUhA0Dob2h DV/LNL68O1f64HRIhsxhPwF9VdSUIg4jaCuStWEk9xDMPNQHOmi2G82Vl 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BpBACPkDBV/4gNJK1dgwxSXAXFfwmBRQqEcYESAoFROBQBAQEBAQEBfYQgAQEBBAEBAWsLDAYBCA4DAwECVgsdCAIEAQ0FiCoNx3oBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsphHwHBoQnAQSRGooalQMig29vgUR/AQEB X-IronPort-AV: E=Sophos;i="5.11,591,1422921600"; d="scan'208";a="142038403" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-7.cisco.com with ESMTP; 17 Apr 2015 04:49:02 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3H4n2V0002377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Apr 2015 04:49:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.189]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 16 Apr 2015 23:49:02 -0500 From: "Zafar Ali (zali)" To: Lou Berger , "draft-ietf-teas-lsp-diversity@ietf.org" Thread-Topic: [Teas] use of the FEC term in draft-ietf-teas-lsp-diversity Thread-Index: AQHQeKGoxPHfrUZ9FkaBXWM7e6qcMp1QtK0A Date: Fri, 17 Apr 2015 04:49:01 +0000 Message-ID: In-Reply-To: <55304D4A.9050604@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.86.252.14] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: TEAS WG Subject: Re: [Teas] use of the FEC term in draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 04:49:15 -0000 Lou-=20 How about we change the terminology to use RSVP-TE "LSP identifier" or "tunnel identifier", depending on the context, instead? Thanks Regards =8A Zafar -----Original Message----- From: "lberger@labn.net" Date: Thursday, April 16, 2015 8:01 PM To: "draft-ietf-teas-lsp-diversity@ietf.org" Cc: TEAS WG Subject: [Teas] use of the FEC term in draft-ietf-teas-lsp-diversity >Authors/WG, > I'm a bit uncomfortable with the document's use of FEC in the >context if RSVP-TE. RFC3209's usage of FEC is very loose and rfc4379 >only gives an indirect definition in one context. I think that either >the draft should avoid the term or it should point to a to be written >formal definition of the term in the context of RSVP-TE (including in >its GMPLS form). > >Thoughts? > >Lou (with any / all hats) > > >_______________________________________________ >Teas mailing list >Teas@ietf.org >https://www.ietf.org/mailman/listinfo/teas From nobody Fri Apr 17 01:23:20 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A4B1B2AD8; Fri, 17 Apr 2015 01:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU9EXQ_BPQZF; Fri, 17 Apr 2015 01:23:17 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CED1B2AD4; Fri, 17 Apr 2015 01:23:17 -0700 (PDT) Received: from [192.168.0.100] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 503CD1801127; Fri, 17 Apr 2015 10:23:15 +0200 (CEST) Message-ID: <5530C2EA.90809@pi.nu> Date: Fri, 17 Apr 2015 10:23:06 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Lou Berger , draft-ietf-teas-lsp-diversity@ietf.org References: <55304D4A.9050604@labn.net> In-Reply-To: <55304D4A.9050604@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: TEAS WG Subject: Re: [Teas] use of the FEC term in draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 08:23:20 -0000 Lou, On 2015-04-17 02:01, Lou Berger wrote: > Authors/WG, > I'm a bit uncomfortable with the document's use of FEC in the > context if RSVP-TE. Yes, I share that concern, the FEC terminology originated in LDP context, but have since developed developed. > RFC3209's usage of FEC is very loose and rfc4379 > only gives an indirect definition in one context. I think that either > the draft should avoid the term or it should point to a to be written > formal definition of the term in the context of RSVP-TE (including in > its GMPLS form). I've been looking for a while for that defintion, and as far as I can there is no RSVP-TE message or object that actually carry a FEC. It has been said the the FEC definition is "implicit", but I don't think that is a solution, rather it is part of the problem. I think that "avoid" would be easiest, but if the authors go for defining a FEC in RSVP-TE context, I think that the consensus call for such a definiton need to involve teas and mpls, but I think ccamp and pce should also be notified for the such a consesus call. /Loa > > Thoughts? > > Lou (with any / all hats) > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Apr 17 01:32:37 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F891B2B78; Fri, 17 Apr 2015 01:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqjZkRzzlSU1; Fri, 17 Apr 2015 01:32:34 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B66221B2B75; Fri, 17 Apr 2015 01:32:33 -0700 (PDT) Received: from [192.168.0.100] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4185E1801127; Fri, 17 Apr 2015 10:32:32 +0200 (CEST) Message-ID: <5530C520.2020904@pi.nu> Date: Fri, 17 Apr 2015 10:32:32 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Zafar Ali (zali)" , Lou Berger , "draft-ietf-teas-lsp-diversity@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: TEAS WG Subject: Re: [Teas] use of the FEC term in draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 08:32:35 -0000 Zafar, On 2015-04-17 06:49, Zafar Ali (zali) wrote: > Lou- > > How about we change the terminology to use RSVP-TE "LSP identifier" or > "tunnel identifier", depending on the context, instead? I guess this is "avoiding" - which is fine with me. It bothers me a (little) bit that "LSP-id" or "tunnel-id" should be equivalent with "FEC". FEC is used to decide what goes on (the same) LSP, while the id's are identifiers for the LSP or the tunnel. /Loa > > Thanks > > Regards Zafar > > > -----Original Message----- > From: "lberger@labn.net" > Date: Thursday, April 16, 2015 8:01 PM > To: "draft-ietf-teas-lsp-diversity@ietf.org" > > Cc: TEAS WG > Subject: [Teas] use of the FEC term in draft-ietf-teas-lsp-diversity > >> Authors/WG, >> I'm a bit uncomfortable with the document's use of FEC in the >> context if RSVP-TE. RFC3209's usage of FEC is very loose and rfc4379 >> only gives an indirect definition in one context. I think that either >> the draft should avoid the term or it should point to a to be written >> formal definition of the term in the context of RSVP-TE (including in >> its GMPLS form). >> >> Thoughts? >> >> Lou (with any / all hats) >> >> >> _______________________________________________ >> Teas mailing list >> Teas@ietf.org >> https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Fri Apr 17 02:44:30 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6FB1ACEA8 for ; Fri, 17 Apr 2015 02:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWc4oaj1mAYb for ; Fri, 17 Apr 2015 02:44:24 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id D46741A1A25 for ; Fri, 17 Apr 2015 02:44:24 -0700 (PDT) Received: (qmail 9599 invoked by uid 0); 17 Apr 2015 09:44:23 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 17 Apr 2015 09:44:23 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id GxkG1q00F2SSUrH01xkKXJ; Fri, 17 Apr 2015 03:44:21 -0600 X-Authority-Analysis: v=2.1 cv=FPmImYYs c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=gaoa-Wm5cTEA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=AqI0xvK1tnMA:10 a=e9J7MTPGsLIA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=X8t1Sf7AzTTqTJ123F0A:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=IQ8ybdpb0rKoq9WEJ3LfPKemom1X2JOt5L5jnnxrEu4=; b=QWSO8ogmfwhK1/pRHAjpRXAg0ilV0SL9fBHN5pgW56Wkr56jQq4wQbxm8MJdK8Z3zHYCsYdC6hteRmgs76Ow91l9MmacWVCsCmxQGJHxG1BloESiAHKWzLTMvGTptcNb; Received: from [74.96.190.213] (port=51998 helo=[11.4.0.117]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Yj2os-0000hB-Eq; Fri, 17 Apr 2015 03:44:18 -0600 From: Lou Berger To: "Zafar Ali (zali)" , Date: Fri, 17 Apr 2015 05:44:17 -0400 Message-ID: <14cc6c3a9b0.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.5.19 (build: 21050019) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.96.190.213 authed with lberger@labn.net} Archived-At: Cc: TEAS WG Subject: Re: [Teas] use of the FEC term in draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 09:44:26 -0000 Hi Zafar, On April 17, 2015 12:49:50 AM "Zafar Ali (zali)" wrote: > Lou- > > How about we change the terminology to use RSVP-TE "LSP identifier" or > "tunnel identifier", depending on the context, instead? > I think any wording that unambiguously reflects your / the authors' / wg's intent is just fine. Thanks, Lou > Thanks > > Regards Š Zafar > > > -----Original Message----- > From: "lberger@labn.net" > Date: Thursday, April 16, 2015 8:01 PM > To: "draft-ietf-teas-lsp-diversity@ietf.org" > > Cc: TEAS WG > Subject: [Teas] use of the FEC term in draft-ietf-teas-lsp-diversity > > >Authors/WG, > > I'm a bit uncomfortable with the document's use of FEC in the > >context if RSVP-TE. RFC3209's usage of FEC is very loose and rfc4379 > >only gives an indirect definition in one context. I think that either > >the draft should avoid the term or it should point to a to be written > >formal definition of the term in the context of RSVP-TE (including in > >its GMPLS form). > > > >Thoughts? > > > >Lou (with any / all hats) > > > > > >_______________________________________________ > >Teas mailing list > >Teas@ietf.org > >https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Fri Apr 17 02:48:59 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8B71AD0BC for ; Fri, 17 Apr 2015 02:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxO22AiTFlk3 for ; Fri, 17 Apr 2015 02:48:57 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 21CAB1AD0AA for ; Fri, 17 Apr 2015 02:48:49 -0700 (PDT) Received: (qmail 14048 invoked by uid 0); 17 Apr 2015 09:48:48 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy9.mail.unifiedlayer.com with SMTP; 17 Apr 2015 09:48:48 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id Gxod1q0062SSUrH01xogpE; Fri, 17 Apr 2015 03:48:46 -0600 X-Authority-Analysis: v=2.1 cv=QKX7GG7L c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=gaoa-Wm5cTEA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=AqI0xvK1tnMA:10 a=e9J7MTPGsLIA:10 a=48vgC7mUAAAA:8 a=i0EeH86SAAAA:8 a=_DPyRagTQV-TBVbyZJUA:9 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID:Date:CC:To:From; bh=xBqGdq+yEjLtL6EHE7MK7vCccbInp2seD9bZxSQVlww=; b=hVI9BjRVOuNOHmR/9LJO6tDRUs18U2QiJGUcIXP39xT2Huiiv7+xB4yexVFMsxDeO4RKgdt06DEaQSmTTw9I5YveBCBTmOIgsaDLGoaFGa+VtzNVxn0VXODAGFpN+2Bt; Received: from [74.96.190.213] (port=52002 helo=[11.4.0.117]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Yj2t5-00005Q-2v; Fri, 17 Apr 2015 03:48:39 -0600 From: Lou Berger To: Loa Andersson , Date: Fri, 17 Apr 2015 05:48:38 -0400 Message-ID: <14cc6c7a538.27e9.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <5530C2EA.90809@pi.nu> References: <55304D4A.9050604@labn.net> <5530C2EA.90809@pi.nu> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.5.19 (build: 21050019) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 74.96.190.213 authed with lberger@labn.net} Archived-At: Cc: TEAS WG Subject: Re: [Teas] use of the FEC term in draft-ietf-teas-lsp-diversity X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 09:48:58 -0000 Hi Loa, On April 17, 2015 4:23:52 AM Loa Andersson wrote: > Lou, > > On 2015-04-17 02:01, Lou Berger wrote: > > Authors/WG, > > I'm a bit uncomfortable with the document's use of FEC in the > > context if RSVP-TE. > Yes, I share that concern, the FEC terminology originated in LDP > context, but have since developed developed. > > > RFC3209's usage of FEC is very loose and rfc4379 > > only gives an indirect definition in one context. I think that either > > the draft should avoid the term or it should point to a to be written > > formal definition of the term in the context of RSVP-TE (including in > > its GMPLS form). > > I've been looking for a while for that defintion, and as far as I can > there is no RSVP-TE message or object that actually carry a FEC. It has > been said the the FEC definition is "implicit", but I don't think that > is a solution, rather it is part of the problem. > > I think that "avoid" would be easiest, This seems to be what Zafar was proposing. > but if the authors go for > defining a FEC in RSVP-TE context, I think that the consensus call for > such a definiton need to involve teas and mpls, but I think ccamp and > pce should also be notified for the such a consesus call. > I completely agree. I also think this must be in its own document. Lou > /Loa > > > > Thoughts? > > > > Lou (with any / all hats) > > > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org > > https://www.ietf.org/mailman/listinfo/teas > > > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > From nobody Fri Apr 17 11:59:55 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3C1B2F7B for ; Fri, 17 Apr 2015 11:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VT47CYwkXbQ for ; Fri, 17 Apr 2015 11:59:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B082B1B2F75 for ; Fri, 17 Apr 2015 11:59:51 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id C0B798F1119A7; Fri, 17 Apr 2015 18:59:45 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t3HIxmKX005020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Apr 2015 14:59:48 -0400 Received: from [135.224.9.213] (135.5.27.18) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 17 Apr 2015 14:59:47 -0400 Message-ID: <55315820.70304@alcatel-lucent.com> Date: Fri, 17 Apr 2015 20:59:44 +0200 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Lou Berger , TEAS WG References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.5.27.18] Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 18:59:54 -0000 Hi Lou, all,

yes/support - however, other than +1 to comments from Paul, Young, and Xian, I would like to emphasize again what I commented
during the discussion in Dallas:

An introduction and a description of the information model (similar to that in draft-ietf-i2rs-yang-network-topo-00) is needed in the
beginning of the document that explains the YANG data model. This section would describe the relationships of the managed entities
(objects) and their attributes with references to the YANG model tree structure and the model definition.

Moreover, for example in the context of ACTN, the model also needs to describe how it can support an arbitrary number of TE
topology hierarchies. I have seen that the current model already provides some means for that, but this should be described in
more detail and some examples should be provided.


Thanks,
Dieter


On 13.04.2015 20:08, Lou Berger wrote:
All,

This is start of a two week poll on making
draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please
send email to the list indicating yes/support or no/do not support.
If indicating no, please state your technical reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.

This document is the product of the TE Topology YANG Model Design Team
and the intent is for this work to serve as the foundation for the WG's
normal activities in this area, i.e., the document is the starting point
for the WG -- not a finished product.  The DT will be closed once we
have a WG document on this topic.

The poll ends Monday April 27th
Thanks,
Lou (and Pavan, who is a co-author)

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
From nobody Sun Apr 19 19:33:33 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5B81ABD3A for ; Sun, 19 Apr 2015 19:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqo046SMJLC6 for ; Sun, 19 Apr 2015 19:33:31 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id F16B71ABB19 for ; Sun, 19 Apr 2015 19:33:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: Date: Sun, 19 Apr 2015 22:33:25 -0400 Message-ID: <000001d07b12$6231c100$26954300$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D07AF0.DB21A7A0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdB7EUxP4dhDrIhqRO28DtwfSwKQ0A== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 02:33:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D07AF0.DB21A7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Support. This document provides an important step to creating TE virtual links and topologies. Clarifying the definitions in future drafts would be helpful. Sue Haers ------=_NextPart_000_0001_01D07AF0.DB21A7A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support.  This document provides an important = step to creating TE virtual links and topologies.  Clarifying the = definitions in future drafts would be helpful.

 

Sue Haers =

------=_NextPart_000_0001_01D07AF0.DB21A7A0-- From nobody Sun Apr 19 22:47:38 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49A911ACDBE for ; Sun, 19 Apr 2015 22:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtKESJoqd4Aq for ; Sun, 19 Apr 2015 22:47:34 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E267E1ACDBD for ; Sun, 19 Apr 2015 22:47:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: "'Dieter Beller'" , "'Lou Berger'" , "'TEAS WG'" References: <552C0611.70500@labn.net> <55315820.70304@alcatel-lucent.com> In-Reply-To: <55315820.70304@alcatel-lucent.com> Date: Mon, 20 Apr 2015 01:47:28 -0400 Message-ID: <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01D07B0B.F7372F30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMTEhcf0WlBqFkj/ZCSupbxwsGBUgHwgZL8msCeeFA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 05:47:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002C_01D07B0B.F7372F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dieter: Do you think the arbitrary number of TE topologies are arbitrary in a hierarchy (1-N levels) or a wide topologies (1-N topologies). Sue From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Friday, April 17, 2015 3:00 PM To: Lou Berger; TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Hi Lou, all, yes/support - however, other than +1 to comments from Paul, Young, and Xian, I would like to emphasize again what I commented during the discussion in Dallas: An introduction and a description of the information model (similar to that in draft-ietf-i2rs-yang-network-topo-00) is needed in the beginning of the document that explains the YANG data model. This section would describe the relationships of the managed entities (objects) and their attributes with references to the YANG model tree structure and the model definition. Moreover, for example in the context of ACTN, the model also needs to describe how it can support an arbitrary number of TE topology hierarchies. I have seen that the current model already provides some means for that, but this should be described in more detail and some examples should be provided. Thanks, Dieter On 13.04.2015 20:08, Lou Berger wrote: All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and the intent is for this work to serve as the foundation for the WG's normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product. The DT will be closed once we have a WG document on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas ------=_NextPart_000_002C_01D07B0B.F7372F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dieter:

 

Do you think the arbitrary number of TE topologies are arbitrary in a = hierarchy (1-N levels) or a wide topologies (1-N topologies). =

 

Sue

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter = Beller
Sent: Friday, April 17, 2015 3:00 PM
To: Lou = Berger; TEAS WG
Subject: Re: [Teas] Poll on making = draft-liu-teas-yang-te-topo-01 a WG = document

 

Hi Lou, all,

yes/support - = however, other than +1 to comments from Paul, Young, and Xian, I would = like to emphasize again what I commented
during the discussion in = Dallas:

An introduction and a description of the information = model (similar to that in draft-ietf-i2rs-yang-network-topo-00) is = needed in the
beginning of the document that explains the YANG data = model. This section would describe the relationships of the managed = entities
(objects) and their attributes with references to the YANG = model tree structure and the model definition.

Moreover, for = example in the context of ACTN, the model also needs to describe how it = can support an arbitrary number of TE
topology = hierarchies.  I have seen that the current model already = provides some means for that, but this should be described in
more = detail and some examples should be = provided.


Thanks,
Dieter

On 13.04.2015 20:08, Lou Berger = wrote:

All,
= 
 
This is start of a two week poll on =
making
draft-liu-teas-yang-te-topo-01 a TEAS =
working group document. Please
send email to the =
list indicating “yes/support” or “no/do not =
support”.
If indicating no, please state your =
technical reservations with the
document.  If =
yes, please also feel free to provide comments you'd =
like
to see addressed once the document is a WG =
document.
 
This document =
is the product of the TE Topology YANG Model Design =
Team
and the intent is for this work to serve as =
the foundation for the WG's
normal activities in =
this area, i.e., the document is the starting =
point
for the WG -- not a finished product.  =
The DT will be closed once we
have a WG document on =
this topic.
 
The poll =
ends Monday April =
27th
Thanks,
Lou (and Pavan, =
who is a =
co-author)
 
_____________=
__________________________________
Teas mailing =
list
Teas@ietf.org
https://www.ietf.org/=
mailman/listinfo/teas
------=_NextPart_000_002C_01D07B0B.F7372F30-- From nobody Mon Apr 20 00:44:38 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B621ACE88 for ; Mon, 20 Apr 2015 00:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6Hg7nUqE040 for ; Mon, 20 Apr 2015 00:44:36 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237BE1ACE86 for ; Mon, 20 Apr 2015 00:44:35 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 5882B3C6BBD3D; Mon, 20 Apr 2015 07:44:30 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t3K7iVaC016334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Apr 2015 09:44:31 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 20 Apr 2015 09:44:31 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: TEAS WG , Lou Berger Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTnoFP/JdaNUkehVOgDXQ8rx51VjQ7w Date: Mon, 20 Apr 2015 07:44:31 +0000 Message-ID: References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 07:44:38 -0000 Hi Lou, all, yes/support - however, I completely share comments from from Paul, Young, X= ian, and Dieter. Thanks Sergio -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: luned=EC 13 aprile 2015 20:08 To: TEAS WG Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send e= mail to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the documen= t. If yes, please also feel free to provide comments you'd like to see add= ressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and = the intent is for this work to serve as the foundation for the WG's normal = activities in this area, i.e., the document is the starting point for the W= G -- not a finished product. The DT will be closed once we have a WG docum= ent on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 20 06:24:00 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D8F1B2B43 for ; Mon, 20 Apr 2015 06:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.54 X-Spam-Level: X-Spam-Status: No, score=0.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7ouTTcBdPaR for ; Mon, 20 Apr 2015 06:23:56 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B8D91B2B3C for ; Mon, 20 Apr 2015 06:23:56 -0700 (PDT) Received: from [192.168.0.101] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 30C6B1801127 for ; Mon, 20 Apr 2015 15:23:55 +0200 (CEST) Message-ID: <5534FDED.3090906@pi.nu> Date: Mon, 20 Apr 2015 15:23:57 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: teas@ietf.org References: <552C0611.70500@labn.net> In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:23:58 -0000 Lou, et.al., I'm on the same page as Xian, support the adoption but there are comments that need addressed. /Loa On 2015-04-14 03:12, Zhangxian (Xian) wrote: > Yes/support. > > I would like see the changes mentioned and comments raised during IETF92 to be reflected either within this document or in another form. Paul already provides a good summary, besides the minutes, I see no need to repeat. :-) > > Regards, > Xian > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 2015414 2:08 > To: TEAS WG > Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document > > All, > > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please > send email to the list indicating yes/support or no/do not support. > If indicating no, please state your technical reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > This document is the product of the TE Topology YANG Model Design Team > and the intent is for this work to serve as the foundation for the WG's > normal activities in this area, i.e., the document is the starting point > for the WG -- not a finished product. The DT will be closed once we > have a WG document on this topic. > > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Apr 21 05:55:19 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2281ACD8C for ; Tue, 21 Apr 2015 05:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcDAA7MBTbjN for ; Tue, 21 Apr 2015 05:55:16 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F8D1ACD91 for ; Tue, 21 Apr 2015 05:55:13 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id DA4C9F4F28E44; Tue, 21 Apr 2015 12:55:08 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3LCt4o7002392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Apr 2015 14:55:09 +0200 Received: from [149.204.107.61] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 21 Apr 2015 14:55:05 +0200 Message-ID: <553648A8.5070800@alcatel-lucent.com> Date: Tue, 21 Apr 2015 14:55:04 +0200 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Susan Hares , "'Lou Berger'" , "'TEAS WG'" References: <552C0611.70500@labn.net> <55315820.70304@alcatel-lucent.com> <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> In-Reply-To: <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 12:55:18 -0000 Hi Sue, all,


On 20.04.2015 07:47, Susan Hares wrote:

Dieter:

Do you think the arbitrary number of TE topologies are arbitrary in a hierarchy (1-N levels) or a wide topologies (1-N topologies).

I am having some difficulties to really understand your question. Let me try to clarify what I meant with my comment:

An abstract topology is according to my understanding composed of links and vertices (nodes) and a vertex could be an abstract
node that represents an underlying abstract topology. This underlying abstract topology can be decomposed again into links and
vertices (nodes) when you zoom into an abstract node.

Based on this principle of recursion, you can create a hierarchy that can have arbitrary levels and a further decomposition is possible
until you have not reached the physical node level (bottom of the hierarchy).

I hope this helps.


Thanks,
Dieter

Sue

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Friday, April 17, 2015 3:00 PM
To: Lou Berger; TEAS WG
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document

Hi Lou, all,

yes/support - however, other than +1 to comments from Paul, Young, and Xian, I would like to emphasize again what I commented
during the discussion in Dallas:

An introduction and a description of the information model (similar to that in draft-ietf-i2rs-yang-network-topo-00) is needed in the
beginning of the document that explains the YANG data model. This section would describe the relationships of the managed entities
(objects) and their attributes with references to the YANG model tree structure and the model definition.

Moreover, for example in the context of ACTN, the model also needs to describe how it can support an arbitrary number of TE
topology hierarchies. I have seen that the current model already provides some means for that, but this should be described in
more detail and some examples should be provided.


Thanks,
Dieter

On 13.04.2015 20:08, Lou Berger wrote:

All,
This is start of a two week poll on making
draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please
send email to the list indicating yes/support or no/do not support.
If indicating no, please state your technical reservations with the
document. If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.
This document is the product of the TE Topology YANG Model Design Team
and the intent is for this work to serve as the foundation for the WG's
normal activities in this area, i.e., the document is the starting point
for the WG -- not a finished product. The DT will be closed once we
have a WG document on this topic.
The poll ends Monday April 27th
Thanks,
Lou (and Pavan, who is a co-author)
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas


_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
From nobody Tue Apr 21 06:38:48 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE7D1A1BDD for ; Tue, 21 Apr 2015 06:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEQiB262mkvd for ; Tue, 21 Apr 2015 06:38:43 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE231A1BCF for ; Tue, 21 Apr 2015 06:38:40 -0700 (PDT) X-AuditID: c1b4fb25-f79126d000004b89-2b-553652dee3f7 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 68.34.19337.ED256355; Tue, 21 Apr 2015 15:38:39 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.223]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0210.002; Tue, 21 Apr 2015 15:38:38 +0200 From: Daniele Ceccarelli To: Dieter Beller , Susan Hares , 'Lou Berger' , 'TEAS WG' Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQey2EBBbDt7rbx0eSProrm9jvU51XTOMAgAAtQNA= Date: Tue, 21 Apr 2015 13:38:38 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48128EA137@ESESSMB301.ericsson.se> References: <552C0611.70500@labn.net> <55315820.70304@alcatel-lucent.com> <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> <553648A8.5070800@alcatel-lucent.com> In-Reply-To: <553648A8.5070800@alcatel-lucent.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48128EA137ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3Rvd+kFmowYab/BZPJ9xnsuhofsti 8efNKxaL1h87WBxYPFqf7WX1WLLkJ5PHh03NbB6zX19nDWCJ4rJJSc3JLEst0rdL4Mo40reE uWBxccXq/ZMYGxhvJncxcnJICJhInNgwmQXCFpO4cG89WxcjF4eQwFFGieeNl1kgnCWMEi0/ vjN1MXJwsAlYSTw55AMSFxGYyChx6v0SZpBuYYFAiRXtt9hAbBGBIIkLG54yQdhWErN/X2QH sVkEVCWe/p4MVsMr4CvRP20NK8SCeYwSJ3etBiviFDCS+Hu8FewkRgFZiQm7FzGC2MwC4hK3 nsxngjhVQGLJnvPMELaoxMvH/1hBjpMQUJRY3i8HYjIL5EssXqsEsUpQ4uTMJywTGEVmIRk0 C6FqFpIqiBI9iRtTp7BB2NoSyxa+ZoawdSVm/DvEgiy+gJF9FaNocWpxUm66kbFealFmcnFx fp5eXmrJJkZg9B3c8lt1B+PlN46HGAU4GJV4eBXWm4YKsSaWFVfmHmKU5mBREue1Mz4UIiSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoEx6P7Tffd1Nfeqq7CllG7qOTwta+oZ1yX3LXmif79Z uNr90d9K64CgRW6vi5cJOArZbKtgNV995dXHgxXGkjkfvcpu6fB7xOV7WpyY/OJH0tNDEz9v qgvQ1ecIi/7g8L7my6+S2wduVLX5O7zLPy1/RfH960kvq12vMCgHSqjHylcor8pMW31PiaU4 I9FQi7moOBEAKqY5Vp8CAAA= Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 13:38:47 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48128EA137ESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree Dieter, and I think this maps to "hierarchy" in Susan' commets. Actually, if my understanding of "wide topology" is correct (I guess it ref= ers to the split of a big topology in smaller "domains") I think that we sh= ould consider both. BR Daniele From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: marted=EC 21 aprile 2015 14:55 To: Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Sue, all, On 20.04.2015 07:47, Susan Hares wrote: Dieter: Do you think the arbitrary number of TE topologies are arbitrary in a hiera= rchy (1-N levels) or a wide topologies (1-N topologies). I am having some difficulties to really understand your question. Let me tr= y to clarify what I meant with my comment: An abstract topology is according to my understanding composed of links and= vertices (nodes) and a vertex could be an abstract node that represents an underlying abstract topology. This underlying abstr= act topology can be decomposed again into links and vertices (nodes) when you zoom into an abstract node. Based on this principle of recursion, you can create a hierarchy that can h= ave arbitrary levels and a further decomposition is possible until you have not reached the physical node level (bottom of the hierarchy= ). I hope this helps. Thanks, Dieter Sue From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Friday, April 17, 2015 3:00 PM To: Lou Berger; TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Lou, all, yes/support - however, other than +1 to comments from Paul, Young, and Xian= , I would like to emphasize again what I commented during the discussion in Dallas: An introduction and a description of the information model (similar to that= in draft-ietf-i2rs-yang-network-topo-00) is needed in the beginning of the document that explains the YANG data model. This section w= ould describe the relationships of the managed entities (objects) and their attributes with references to the YANG model tree struc= ture and the model definition. Moreover, for example in the context of ACTN, the model also needs to descr= ibe how it can support an arbitrary number of TE topology hierarchies. I have seen that the current model already provides = some means for that, but this should be described in more detail and some examples should be provided. Thanks, Dieter On 13.04.2015 20:08, Lou Berger wrote: All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and the intent is for this work to serve as the foundation for the WG's normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product. The DT will be closed once we have a WG document on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_4A1562797D64E44993C5CBF38CF1BE48128EA137ESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Agree Dieter, and I think= this maps to “hierarchy” in Susan’ commets.

 <= /p>

Actually, if my understan= ding of “wide topology” is correct (I guess it refers to the sp= lit of a big topology in smaller “domains”) I think that we sho= uld consider both.

 <= /p>

BR
Daniele

 <= /p>

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: marted=EC 21 aprile 2015 14:55
To: Susan Hares; 'Lou Berger'; 'TEAS WG'
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Hi Sue, all,

On 20.04.2015 07:47, Susan Hares wrote:

Dieter:

 <= /p>

Do you think the arbitrar= y number of TE topologies are arbitrary in a hierarchy (1-N levels) or a wi= de topologies (1-N topologies).

I am having some difficulties to really understand y= our question. Let me try to clarify what I meant with my comment:

An abstract topology is according to my understanding composed of links and= vertices (nodes) and a vertex could be an abstract
node that represents an underlying abstract topology. This underlying abstr= act topology can be decomposed again into links and
vertices (nodes) when you zoom into an abstract node.

Based on this principle of recursion, you can create a hierarchy that can h= ave arbitrary levels and a further decomposition is possible
until you have not reached the physical node level (bottom of the hierarchy= ).

I hope this helps.


Thanks,
Dieter
 

 <= /p>

Sue

 <= /p>

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Friday, April 17, 2015 3:00 PM
To: Lou Berger; TEAS WG
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Hi Lou, all,

yes/support - however, other than +1 to comments from Paul, Young, and = Xian, I would like to emphasize again what I commented
during the discussion in Dallas:

An introduction and a description of the information model (similar to that= in draft-ietf-i2rs-yang-network-topo-00) is needed in the
beginning of the document that explains the YANG data model. This section w= ould describe the relationships of the managed entities
(objects) and their attributes with references to the YANG model tree struc= ture and the model definition.

Moreover, for example in the context of ACTN, the model also needs to descr= ibe how it can support an arbitrary number of TE
topology hierarchies.  I have seen that the current model already = provides some means for that, but this should be described in
more detail and some examples should be provided.


Thanks,
Dieter


On 13.04.2015 20:08, Lou Berger wrote: 

All,
 
This is start of a two week poll on making
draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please
send email to the list indicating “yes/support” or “=
no/do not support”.
If indicating no, please state your technical reservations with the
document.  If yes, please also feel free to provide comments you'=
d like
to see addressed once the document is a WG document.
 
This document is the product of the TE Topology YANG Model Design Team=

and the intent is for this work to serve as the foundation for the WG'=
s
normal activities in this area, i.e., the document is the starting poi=
nt
for the WG -- not a finished product.  The DT will be closed once=
 we
have a WG document on this topic.
 
The poll ends Monday April 27th
Thanks,
Lou (and Pavan, who is a co-author)
 
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.iet=
f.org/mailman/listinfo/teas




_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.iet=
f.org/mailman/listinfo/teas
--_000_4A1562797D64E44993C5CBF38CF1BE48128EA137ESESSMB301erics_-- From nobody Tue Apr 21 08:27:46 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C0A1ACE5E; Tue, 21 Apr 2015 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGje1vuHflgg; Tue, 21 Apr 2015 08:27:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1351ACE4D; Tue, 21 Apr 2015 08:27:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRQ88849; Tue, 21 Apr 2015 15:27:27 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Apr 2015 16:27:26 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Tue, 21 Apr 2015 08:27:23 -0700 From: Huaimo Chen To: Gregory Mirsky , "draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" Thread-Topic: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Thread-Index: AdBz6EeHlPEjW31GTZaF4ZwMtm3+CgBSx/EQAOobtwAA2TtZ4A== Date: Tue, 21 Apr 2015 15:27:22 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D44E3804B5@SJCEML701-CHM.china.huawei.com> References: <7347100B5761DC41A166AC17F22DF1121B948347@eusaamb103.ericsson.se> <5316A0AB3C851246A7CA5758973207D44E37EE98@SJCEML701-CHM.china.huawei.com> <7347100B5761DC41A166AC17F22DF1121B94CD49@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B94CD49@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.156] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "mpls@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [Teas] [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 15:27:44 -0000 --_000_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thanks for your comments. My answers/explanations are inline below with [Huaimo 2]. Best Regards, Huaimo From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, April 16, 2015 7:58 PM To: Huaimo Chen; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; te= as-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Huaimo, thank you for kind consideration of my comments. Please find more in-lined = and tagged GIM>> notes. Regards, Greg From: Huaimo Chen [mailto:huaimo.chen@huawei.com] Sent: Sunday, April 12, 2015 11:04 AM To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org<= mailto:draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org>; teas-chairs= @ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Hi Greg, Thanks for your comments. My answers/explanations are inline below. Best Regards, Huaimo From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, April 12, 2015 2:04 AM To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org Cc: mpls@ietf.org; rtg-bfd@ietf.org Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection Dear Editors, chairs, WG community, please find my comments to the current version of your work below: * Introduction o The first paragraph may leave an impression that local protection of tr= ansit LSRs is not being already addressed, neither by RFC 4090, nor RFC 487= 5; [Huaimo] Will revise it accordingly. o I think that "global protection" is not commonly used term, "end-to-end= protection" seems to be commonly used instead. [Huaimo] It seems that "global protection" is better here since we mentione= d "local protection" here. It seems that Global Protection is used often. * Section 3.1 o Third paragraph contains the following requirement: "For a P2P LSP, after the primary ingress fails, the backup ingress must us= e a method to reliably detect the failure of the primary ingress before the= PATH message for the LSP expires at the next hop of the primary ingress." But that is not obvious that such requirement is really needed. Since this = is RSVP-TE LSP, why not to use MP2MP construct and let the Source node to c= ontrol switchover. Especially since, as noted in the last paragraph of Sect= ion 2.1, primary and backup ingress nodes must be connected by a logical li= nk, which in general case will be a tunnel. Thus this solution puts a requi= rement, implicitly though, to instantiate a tunnel per protection group, tu= nnel that would not be used to carry traffic. [Huaimo] The requirement above seems necessary. If the backup ingress does = not detect the failure of the primary ingress before the timer for the PATH= message for the LSP at the next hop of the primary ingress expires, the LS= P will be down after the primary ingress fails. If the backup ingress detec= ts the failure and sends/refreshes the PATH message to the next hop before = the timer expires after the primary egress fails, the LSP will continue bei= ng up and carry the traffic from the backup ingress via the backup LSP. For a P2P LSP, it seems that MP2MP construct is not used in RFC 4090 to pro= tect a transit node of a P2P LSP. The logical link between the primary ingr= ess and the backup ingress can be a direct link or a tunnel. It seems that = a direct link is common. GIM>> I think it is strange to cite requirement on scale of seconds if not = tens of seconds in discussion of method of local protection that supposed t= o perform protection switchover in sub-second if not sub-50msec time. [Huaimo 2] The requirement is for the control plane. More specifically, it = is for the PATH message (not to be cleaned up) for the LSP at the next hop = of the primary ingress of the LSP when the primary ingress fails. After the= primary ingress fails, the next hop will not receive any PATH message from= the primary ingress. In order to prevent the PATH message from clean up at= the next hop, the backup ingress seems required to detect the failure of t= he primary ingress and send/refresh the PATH message to the next hop before= the PATH message is cleaned up. Thus it seems reasonable for the requireme= nt to have the time for detecting the failure of the primary ingress in sec= onds or even tens of seconds instead of sub-seconds or within 50 ms. o In addition, what is importance of requirement quoted above: "... before the PATH message for the LSP expires at the next hop of the pri= mary ingress" [Huaimo] This seems very important. If the timer for the PATH message for t= he LSP at the next hop of the primary egress expires, then the LSP will be = down. So the PATH message must be refreshed before the timer for the PATH m= essage for the LSP expires at the next hop of the primary LSP. GIM>> As noted above, these seem as requirements of different scale. [Huaimo 2] See the explanation above. o Fourth paragraph makes very questionable assumption in: "After the primary ingress fails, it will not be reachable after routing co= nvergence." I believe that if OAM session is between two nodes there's no reliable way = to differentiate between node and link failure. Thus, to declare a node unr= eachable there must be N tunnels for N OAM sessions that monitor all possib= le paths between two nodes. (Note, that if there was no requirement to use = a tunnel between primary and backup ingress, multi-hop BFD could be used th= ough its detection time being limited by IGP convergence, which may be too = slow comparing with your requirement of tens milliseconds). [Huaimo] It is true that "After the primary ingress fails, it will not be r= eachable after routing convergence." From routing's point of view, there i= s no need for us to have any OAM session between two nodes. The timer for a= PATH message seems in tens of seconds. Routing convergence is not limited = to tens of milliseconds. GIM>> Routing convergence may take seconds. Is that acceptable as failure d= etection time for local protection? Protection switchover expected to be fa= st, perhaps on sub-50 msec scale. From TDM world we carry 10 msec failure d= etection, and BFD implementations can support that. but here, it appears, y= ou describe failure detection mechanism with detection time on scale of sec= onds if not tens of seconds. [Huaimo 2] The routing convergence is for the control plane. Refer to the e= xplanation above. * Section 5.1 o Regarding "Ingress local protection in use" flag As demonstrated earlier, backup ingress node has no reliable way to detect = that primary ingress node is not reachable to the Source and thus protectio= n must be activated. [Huaimo] It seems that there is no need for the backup ingress to detect wh= ether the primary ingress is reachable to the Source and the focus is on th= e failure of the primary ingress. GIM>> In that case, the text is not needed either. [Huaimo 2] Can you give more details regarding to "the text is not needed e= ither"? Which part of the text (do you think) is not needed in section 5.1? Considering that backup ingress may initiate described in the document acti= ons not when primary ingress became unavailable to Source, I believe that c= ases that may produce false positives must be removed along with extensions= that intended to support these cases. In my opinion, the only viable case = of ingress protection is Source-centric where Source monitors availability = of both primary and backup ingress nodes and controls traffic switchover. I= 'd ask WG to discuss these comments and, if agreed, ask Editors to make app= ropriate changes to the document. [Huaimo] It seems that the current version already indicates that the sourc= e-detect (i.e., Source detects the failure of the primary ingress and switc= hes traffic to the backup ingress when the primary ingress fails) is used. = There were a few of modes for detecting the failure of the primary ingress= that were proposed in the previous versions of the document. A different m= ode may have a different control on the traffic switch over and/or forwardi= ng. After discussions, the current version selects the source-detect. GIM>> If this is historical part, then it may be moved to Appendix or taken= from the document altogether. [Huaimo 2] A couple of detection modes were removed from the document. One = more will be smoothed out. Thus there will be only one mode in the document= . Can you give more details about the cases in which false positives may be p= roduced? GIM>> If current proposal is limited to Source-detect case only then possi= bility of false positive/negative depends on Source to Ingress connection a= nd OAM mechanism used. But that is deployment issue and is outside of scope= of this document Regards, Greg --_000_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below with [Huaimo 2].<= /span>

Best Regards,

Huaimo

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Thursday, April 16, 2015 7:58 PM
To: Huaimo Chen; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.= org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Huaimo,<= /span>

thank you for kind con= sideration of my comments. Please find more in-lined and tagged GIM>>= notes.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Huaimo C= hen [mailto:huaimo.chen@huawei.co= m]
Sent: Sunday, April 12, 2015 11:04 AM
To: Gregory Mirsky; draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: RE: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protect= ion

 

Hi Greg,

 

Thanks for your comments.

My answers/explanations are inline below.

 

Best Regards,

Huaimo

From: mpls [mailto:mpls-bounces@ietf= .org] On Behalf Of Gregory Mirsky
Sent: Sunday, April 12, 2015 2:04 AM
To: draft-ietf-teas-rsvp-ingress-protection@tools.ietf.org; teas-chairs@ietf.org; teas@ietf.org
Cc: mpls@ietf.org; rtg-bfd@ietf.org
Subject: [mpls] Comments on draft-ietf-teas-rsvp-ingress-protection<= o:p>

 

Dear Editors, chairs, WG community,

please find my comments to the current version of yo= ur work below:

·        Introduction

o   The first paragraph may leave an impression = that local protection of transit LSRs is not being already addressed, neith= er by RFC 4090, nor RFC 4875;

[Huaimo] Will revise i= t accordingly.

o   I think that “global protection”= is not commonly used term, “end-to-end protection” seems to be= commonly used instead.

[Huaimo] It seems that= “global protection” is better here since we mentioned “l= ocal protection” here. It seems that Global Protection is used often.=

·        Section 3.1

o   Third paragraph contains the following requi= rement:

“For a P2P LSP, af= ter the primary ingress fails, the backup ingress must use a method to reli= ably detect the failure of the primary ingress before the PATH message for = the LSP expires at the next hop of the primary ingress.”

But that is not obvious = that such requirement is really needed. Since this is RSVP-TE LSP, why not = to use MP2MP construct and let the Source node to control switchover. Espec= ially since, as noted in the last paragraph of Section 2.1, primary and backup ingress nodes must be connected by a lo= gical link, which in general case will be a tunnel. Thus this solution puts= a requirement, implicitly though, to instantiate a tunnel per protection g= roup, tunnel that would not be used to carry traffic.

[Huaimo] The requireme= nt above seems necessary. If the backup ingress does not detect the failure= of the primary ingress before the timer for the PATH message for the LSP a= t the next hop of the primary ingress expires, the LSP will be down after the primary ingress fails. If the back= up ingress detects the failure and sends/refreshes the PATH message to the = next hop before the timer expires after the primary egress fails, the LSP w= ill continue being up and carry the traffic from the backup ingress via the backup LSP. =

For a P2P LSP, it seem= s that MP2MP construct is not used in RFC 4090 to protect a transit node of= a P2P LSP. The logical link between the primary ingress and the backup ing= ress can be a direct link or a tunnel. It seems that a direct link is common.

GIM>> I think it= is strange to cite requirement on scale of seconds if not tens of seconds = in discussion of method of local protection that supposed to perform protec= tion switchover in sub-second if not sub-50msec time.

[Huaimo 2] The require= ment is for the control plane. More specifically, it is for the PATH messag= e (not to be cleaned up) for the LSP at the next hop of the primary ingress= of the LSP when the primary ingress fails. After the primary ingress fails, the next hop will not receive any = PATH message from the primary ingress. In order to prevent the PATH message= from clean up at the next hop, the backup ingress seems required to detect= the failure of the primary ingress and send/refresh the PATH message to the next hop before the PATH message = is cleaned up. Thus it seems reasonable for the requirement to have the tim= e for detecting the failure of the primary ingress in seconds or even tens = of seconds instead of sub-seconds or within 50 ms.

 

o   In addition, what is importance of requireme= nt quoted above:

“… before th= e PATH message for the LSP expires at the next hop of the primary ingress&#= 8221;

[Huaimo] This seems ve= ry important. If the timer for the PATH message for the LSP at the next hop= of the primary egress expires, then the LSP will be down. So the PATH mess= age must be refreshed before the timer for the PATH message for the LSP expires at the next hop of the primary LS= P.

GIM>> As noted a= bove, these seem as requirements of different scale.

[Huaimo 2] See the exp= lanation above.

 

o   Fourth paragraph makes very questionable ass= umption in:

“After the primary= ingress fails, it will not be reachable after routing convergence.”<= o:p>

I believe that if OAM se= ssion is between two nodes there’s no reliable way to differentiate b= etween node and link failure. Thus, to declare a node unreachable there mus= t be N tunnels for N OAM sessions that monitor all possible paths between two nodes. (Note, that if there was no requirem= ent to use a tunnel between primary and backup ingress, multi-hop BFD could= be used though its detection time being limited by IGP convergence, which = may be too slow comparing with your requirement of tens milliseconds).

[Huaimo] It is true th= at “After the primary ingress fails, it will not be reachable after r= outing convergence.”  From routing’s point of view, there = is no need for us to have any OAM session between two nodes. The timer for a PATH message seems in tens of seconds. Routing convergence= is not limited to tens of milliseconds.

GIM>> Routing co= nvergence may take seconds. Is that acceptable as failure detection time fo= r local protection? Protection switchover expected to be fast, perhaps on s= ub-50 msec scale. From TDM world we carry 10 msec failure detection, and BFD implementations can support that. but h= ere, it appears, you describe failure detection mechanism with detection ti= me on scale of seconds if not tens of seconds.

[Huaimo 2] The routing= convergence is for the control plane. Refer to the explanation above.=

 

·        Section 5.1

o   Regarding “Ingress local protection in= use” flag

As demonstrated earlier,= backup ingress node has no reliable way to detect that primary ingress nod= e is not reachable to the Source and thus protection must be activated.

[Huaimo] It seems that= there is no need for the backup ingress to detect whether the primary ingr= ess is reachable to the Source and the focus is on the failure of the prima= ry ingress.

GIM>> In that ca= se, the text is not needed either.

[Huaimo 2] Can you giv= e more details regarding to “the text is not needed either”? Wh= ich part of the text (do you think) is not needed in section 5.1?

 

Considering that backup ingress may initiate describ= ed in the document actions not when primary ingress became unavailable to S= ource, I believe that cases that may produce false positives must be remove= d along with extensions that intended to support these cases. In my opinion, the only viable case of ingress pro= tection is Source-centric where Source monitors availability of both primar= y and backup ingress nodes and controls traffic switchover. I’d ask W= G to discuss these comments and, if agreed, ask Editors to make appropriate changes to the document.

[Huaimo] It seems that= the current version already indicates that the source-detect (i.e., Source= detects the failure of the primary ingress and switches traffic to the bac= kup ingress when the primary ingress fails) is used.  There were a few of modes for detecting the failure = of the primary ingress that were proposed in the previous versions of the d= ocument. A different mode may have a different control on the traffic switc= h over and/or forwarding.  After discussions, the current version selects the source-detect.

GIM>> If this is= historical part, then it may be moved to Appendix or taken from the docume= nt altogether.

[Huaimo 2] A couple of= detection modes were removed from the document. One more will be smoothed = out. Thus there will be only one mode in the document.

 

Can you give more deta= ils about the cases in which false positives may be produced?

GIM>> If current= proposal is limited to Source-detect case only  then possibility of f= alse positive/negative depends on Source to Ingress connection and OAM mech= anism used. But that is deployment issue and is outside of scope of this document

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

--_000_5316A0AB3C851246A7CA5758973207D44E3804B5SJCEML701CHMchi_-- From nobody Tue Apr 21 10:19:13 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362021A7026 for ; Tue, 21 Apr 2015 10:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHEcWsF-mw6j for ; Tue, 21 Apr 2015 10:19:08 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F085A1A1B87 for ; Tue, 21 Apr 2015 10:19:07 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id D96F7A2623549; Tue, 21 Apr 2015 17:19:01 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3LHJ1uZ015311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Apr 2015 19:19:01 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Tue, 21 Apr 2015 19:19:00 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Daniele Ceccarelli , "Beller, Dieter (Dieter)" , Susan Hares , "'Lou Berger'" , "'TEAS WG'" Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQey2FIBj7yF4xq06Iqba2nJF52J1XTOMAgAAMLACAAF0O8A== Date: Tue, 21 Apr 2015 17:19:00 +0000 Message-ID: References: <552C0611.70500@labn.net> <55315820.70304@alcatel-lucent.com> <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> <553648A8.5070800@alcatel-lucent.com> <4A1562797D64E44993C5CBF38CF1BE48128EA137@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48128EA137@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B75CB99CFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 17:19:12 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75CB99CFR711WXCHMBA05z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Daniele, but I think Dieter's comment is in fact linked particularly to = requirement coming e.g. from ACTN, that surely, fall into the first case (= hierarchy) not explicitly into the second, that, if understand your stateme= nt is more related to horizontal segmentation e.g. for scalability reason t= han to the possibility to present different level of topologies accordingly= to abstraction required policy. Thanks Sergio From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: marted=EC 21 aprile 2015 15:39 To: Beller, Dieter (Dieter); Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Agree Dieter, and I think this maps to "hierarchy" in Susan' commets. Actually, if my understanding of "wide topology" is correct (I guess it ref= ers to the split of a big topology in smaller "domains") I think that we sh= ould consider both. BR Daniele From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: marted=EC 21 aprile 2015 14:55 To: Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Sue, all, On 20.04.2015 07:47, Susan Hares wrote: Dieter: Do you think the arbitrary number of TE topologies are arbitrary in a hiera= rchy (1-N levels) or a wide topologies (1-N topologies). I am having some difficulties to really understand your question. Let me tr= y to clarify what I meant with my comment: An abstract topology is according to my understanding composed of links and= vertices (nodes) and a vertex could be an abstract node that represents an underlying abstract topology. This underlying abstr= act topology can be decomposed again into links and vertices (nodes) when you zoom into an abstract node. Based on this principle of recursion, you can create a hierarchy that can h= ave arbitrary levels and a further decomposition is possible until you have not reached the physical node level (bottom of the hierarchy= ). I hope this helps. Thanks, Dieter Sue From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Friday, April 17, 2015 3:00 PM To: Lou Berger; TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Lou, all, yes/support - however, other than +1 to comments from Paul, Young, and Xian= , I would like to emphasize again what I commented during the discussion in Dallas: An introduction and a description of the information model (similar to that= in draft-ietf-i2rs-yang-network-topo-00) is needed in the beginning of the document that explains the YANG data model. This section w= ould describe the relationships of the managed entities (objects) and their attributes with references to the YANG model tree struc= ture and the model definition. Moreover, for example in the context of ACTN, the model also needs to descr= ibe how it can support an arbitrary number of TE topology hierarchies. I have seen that the current model already provides = some means for that, but this should be described in more detail and some examples should be provided. Thanks, Dieter On 13.04.2015 20:08, Lou Berger wrote: All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and the intent is for this work to serve as the foundation for the WG's normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product. The DT will be closed once we have a WG document on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75CB99CFR711WXCHMBA05z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Daniele= , but I think Dieter’s comment is in fact linked particularly to &nbs= p;requirement coming e.g. from ACTN, that surely, fall into the first case (hierarchy) not explicitly into the second, that, if understand your = statement is more related to horizontal segmentation e.g. for scalability r= eason than to the possibility to present different level of topologies acco= rdingly  to abstraction required policy.

 = ;

Thanks

Sergio

 = ;

 <= /p>

From:= Teas [mailto:teas-b= ounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: marted=EC 21 aprile 2015 15:39
To: Beller, Dieter (Dieter); Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Agree Diet= er, and I think this maps to “hierarchy” in Susan’ commet= s.

 

Actually, = if my understanding of “wide topology” is correct (I guess it r= efers to the split of a big topology in smaller “domains”) I th= ink that we should consider both.

 

BR
Daniele

 

From:= Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: marted=EC 21 aprile 2015 14:55
To: Susan Hares; 'Lou Berger'; 'TEAS WG'
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Hi Sue, all= ,


On 20.04.2015 07:47, Susan Hare= s wrote:

Dieter:

 

Do you thi= nk the arbitrary number of TE topologies are arbitrary in a hierarchy (1-N = levels) or a wide topologies (1-N topologies).

I am having some difficulties t= o really understand your question. Let me try to clarify what I meant with = my comment:

An abstract topology is according to my understanding composed of links and= vertices (nodes) and a vertex could be an abstract
node that represents an underlying abstract topology. This underlying abstr= act topology can be decomposed again into links and
vertices (nodes) when you zoom into an abstract node.

Based on this principle of recursion, you can create a hierarchy that can h= ave arbitrary levels and a further decomposition is possible
until you have not reached the physical node level (bottom of the hierarchy= ).

I hope this helps.


Thanks,
Dieter
 


 

Sue

 

From:= Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Friday, April 17, 2015 3:00 PM
To: Lou Berger; TEAS WG
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

= Hi Lou, all,

yes/support - however, other than +1 to comments from Paul, Young, and = Xian, I would like to emphasize again what I commented
during the discussion in Dallas:

An introduction and a description of the information model (similar to that= in draft-ietf-i2rs-yang-network-topo-00) is needed in the
beginning of the document that explains the YANG data model. This section w= ould describe the relationships of the managed entities
(objects) and their attributes with references to the YANG model tree struc= ture and the model definition.

Moreover, for example in the context of ACTN, the model also needs to descr= ibe how it can support an arbitrary number of TE
topology hierarchies.  I have seen that the current model already = provides some means for that, but this should be described in
more detail and some examples should be provided.


Thanks,
Dieter



On 13.04.2015 20:08, Lou Berger= wrote:

All,
 
This is start of a two week poll on making
draft-liu-teas-yang-te-topo-01 a TEAS working gro=
up document. Please
send email to the list indicating “yes/supp=
ort” or “no/do not support”.
If indicating no, please state your technical res=
ervations with the
document.  If yes, please also feel free to =
provide comments you'd like
to see addressed once the document is a WG docume=
nt.
 
This document is the product of the TE Topology Y=
ANG Model Design Team
and the intent is for this work to serve as the f=
oundation for the WG's
normal activities in this area, i.e., the documen=
t is the starting point
for the WG -- not a finished product.  The D=
T will be closed once we
have a WG document on this topic.
 
The poll ends Monday April 27th=

Thanks,
Lou (and Pavan, who is a co-author)
 
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas






_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
--_000_B9FEE68CE3A78C41A2B3C67549A96F48B75CB99CFR711WXCHMBA05z_-- From nobody Tue Apr 21 10:32:22 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB201AD33B for ; Tue, 21 Apr 2015 10:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENWMA9EAB8ha for ; Tue, 21 Apr 2015 10:32:16 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971961A8739 for ; Tue, 21 Apr 2015 10:32:15 -0700 (PDT) X-AuditID: c1b4fb30-f79996d000006ebb-62-5536899d18fb Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 02.1E.28347.D9986355; Tue, 21 Apr 2015 19:32:13 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.223]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Tue, 21 Apr 2015 19:32:13 +0200 From: Daniele Ceccarelli To: "BELOTTI, SERGIO (SERGIO)" , "Beller, Dieter (Dieter)" , Susan Hares , 'Lou Berger' , 'TEAS WG' Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQey2EBBbDt7rbx0eSProrm9jvU51XTOMAgAAtQNCAABx+AIAAJN5A Date: Tue, 21 Apr 2015 17:32:12 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48128EA96B@ESESSMB301.ericsson.se> References: <552C0611.70500@labn.net> <55315820.70304@alcatel-lucent.com> <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> <553648A8.5070800@alcatel-lucent.com> <4A1562797D64E44993C5CBF38CF1BE48128EA137@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE48128EA96BESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM+Jvje7cTrNQgy3HzS2eTrjPZNHR/JbF Ytnm3+wWf968YrFo/bGDxYHVo/XZXlaPJUt+Mnl82NTM5jH79XXWAJYoLpuU1JzMstQifbsE rowrZ9ezF9yfw1jROOUWWwPj9w7GLkZODgkBE4nnp9qZIGwxiQv31rN1MXJxCAkcZZTYfvcK M4SzhFFi/9WFQA4HB5uAlcSTQz4gDSIC9xklTv3QBrGFBQIlVrTfYoOIB0lc2PCUCcJ2k9i3 fhsriM0ioCqxblYnM4jNK+ArsfHaS1aI+VuZJH60bwAr4hSIlTh04ybYIEYBWYkJuxeBXcos IC5x68l8qEsFJJbsOc8MYYtKvHz8jxXCVpT4+GofVH2+xKqbn5kglglKnJz5hGUCo8gsJKNm ISmbhaQMIq4ncWPqFDYIW1ti2cLXzBC2rsSMf4dYkMUXMLKvYhQtTi1Oyk03MtJLLcpMLi7O z9PLSy3ZxAiMx4NbfhvsYHz53PEQowAHoxIPr8J601Ah1sSy4srcQ4zSHCxK4rx2xodChATS E0tSs1NTC1KL4otKc1KLDzEycXBKNTC6T9GUUJ9/MeWL+LOdGnv3OpzSbooN0OvT+/hEI+K4 ZXXJnPOCv5TDtslwBCxRWGm1tpX1rF1cVGyZncDDHqu1R3zX/zM9uMUx1nKL2YrdPxZnZvtf 3XC7mX/q0Xm52/fr2D+82bKsWNrFZPOMCXemr85ouPyqO+G00qRwhzsPJzAGvVkW7hysxFKc kWioxVxUnAgAeImeMqgCAAA= Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 17:32:20 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE48128EA96BESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sergio, Exactly, correct! They are 2 orthogonal issues. BR Daniele From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] Sent: marted=EC 21 aprile 2015 19:19 To: Daniele Ceccarelli; Beller, Dieter (Dieter); Susan Hares; 'Lou Berger';= 'TEAS WG' Subject: RE: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Daniele, but I think Dieter's comment is in fact linked particularly to = requirement coming e.g. from ACTN, that surely, fall into the first case (= hierarchy) not explicitly into the second, that, if understand your stateme= nt is more related to horizontal segmentation e.g. for scalability reason t= han to the possibility to present different level of topologies accordingly= to abstraction required policy. Thanks Sergio From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli Sent: marted=EC 21 aprile 2015 15:39 To: Beller, Dieter (Dieter); Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Agree Dieter, and I think this maps to "hierarchy" in Susan' commets. Actually, if my understanding of "wide topology" is correct (I guess it ref= ers to the split of a big topology in smaller "domains") I think that we sh= ould consider both. BR Daniele From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: marted=EC 21 aprile 2015 14:55 To: Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Sue, all, On 20.04.2015 07:47, Susan Hares wrote: Dieter: Do you think the arbitrary number of TE topologies are arbitrary in a hiera= rchy (1-N levels) or a wide topologies (1-N topologies). I am having some difficulties to really understand your question. Let me tr= y to clarify what I meant with my comment: An abstract topology is according to my understanding composed of links and= vertices (nodes) and a vertex could be an abstract node that represents an underlying abstract topology. This underlying abstr= act topology can be decomposed again into links and vertices (nodes) when you zoom into an abstract node. Based on this principle of recursion, you can create a hierarchy that can h= ave arbitrary levels and a further decomposition is possible until you have not reached the physical node level (bottom of the hierarchy= ). I hope this helps. Thanks, Dieter Sue From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Friday, April 17, 2015 3:00 PM To: Lou Berger; TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Lou, all, yes/support - however, other than +1 to comments from Paul, Young, and Xian= , I would like to emphasize again what I commented during the discussion in Dallas: An introduction and a description of the information model (similar to that= in draft-ietf-i2rs-yang-network-topo-00) is needed in the beginning of the document that explains the YANG data model. This section w= ould describe the relationships of the managed entities (objects) and their attributes with references to the YANG model tree struc= ture and the model definition. Moreover, for example in the context of ACTN, the model also needs to descr= ibe how it can support an arbitrary number of TE topology hierarchies. I have seen that the current model already provides = some means for that, but this should be described in more detail and some examples should be provided. Thanks, Dieter On 13.04.2015 20:08, Lou Berger wrote: All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and the intent is for this work to serve as the foundation for the WG's normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product. The DT will be closed once we have a WG document on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_4A1562797D64E44993C5CBF38CF1BE48128EA96BESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Sergio,

 <= /p>

Exactly, correct! They ar= e 2 orthogonal issues.

BR
Daniele

 <= /p>

From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@a= lcatel-lucent.com]
Sent: marted=EC 21 aprile 2015 19:19
To: Daniele Ceccarelli; Beller, Dieter (Dieter); Susan Hares; 'Lou B= erger'; 'TEAS WG'
Subject: RE: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Hi Daniele, but I think D= ieter’s comment is in fact linked particularly to  requirement c= oming e.g. from ACTN, that surely, fall into the first case (hierarchy) not explicitly into the second, that, if understand your statement is more= related to horizontal segmentation e.g. for scalability reason than to the= possibility to present different level of topologies accordingly  to = abstraction required policy.

 <= /p>

Thanks<= /p>

Sergio

 <= /p>

 

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Daniele Ceccarelli
Sent: marted=EC 21 aprile 2015 15:39
To: Beller, Dieter (Dieter); Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Agree Dieter, and I think= this maps to “hierarchy” in Susan’ commets.<= /o:p>

 <= /p>

Actually, if my understan= ding of “wide topology” is correct (I guess it refers to the sp= lit of a big topology in smaller “domains”) I think that we sho= uld consider both.

 <= /p>

BR
Daniele

 <= /p>

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: marted=EC 21 aprile 2015 14:55
To: Susan Hares; 'Lou Berger'; 'TEAS WG'
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Hi Sue, all,

On 20.04.2015 07:47, Susan Hares wrote:

Dieter:

 <= /p>

Do you think the arbitrar= y number of TE topologies are arbitrary in a hierarchy (1-N levels) or a wi= de topologies (1-N topologies).

I am having some diff= iculties to really understand your question. Let me try to clarify what I m= eant with my comment:

An abstract topology is according to my understanding composed of links and= vertices (nodes) and a vertex could be an abstract
node that represents an underlying abstract topology. This underlying abstr= act topology can be decomposed again into links and
vertices (nodes) when you zoom into an abstract node.

Based on this principle of recursion, you can create a hierarchy that can h= ave arbitrary levels and a further decomposition is possible
until you have not reached the physical node level (bottom of the hierarchy= ).

I hope this helps.


Thanks,
Dieter
 

 <= /p>

Sue

 <= /p>

From: Teas [ma= ilto:teas-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Friday, April 17, 2015 3:00 PM
To: Lou Berger; TEAS WG
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Hi Lou, all,

yes/support - however, other than +1 to comments from Paul, Young, and = Xian, I would like to emphasize again what I commented
during the discussion in Dallas:

An introduction and a description of the information model (similar to that= in draft-ietf-i2rs-yang-network-topo-00) is needed in the
beginning of the document that explains the YANG data model. This section w= ould describe the relationships of the managed entities
(objects) and their attributes with references to the YANG model tree struc= ture and the model definition.

Moreover, for example in the context of ACTN, the model also needs to descr= ibe how it can support an arbitrary number of TE
topology hierarchies.  I have seen that the current model already = provides some means for that, but this should be described in
more detail and some examples should be provided.


Thanks,
Dieter


On 13.04.2015 20:08, Lou Berger wrote: 

All,
 
This is start of a two week poll on making
draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please
send email to the list indicating “yes/support” or “=
no/do not support”.
If indicating no, please state your technical reservations with the
document.  If yes, please also feel free to provide comments you'=
d like
to see addressed once the document is a WG document.
 
This document is the product of the TE Topology YANG Model Design Team=

and the intent is for this work to serve as the foundation for the WG'=
s
normal activities in this area, i.e., the document is the starting poi=
nt
for the WG -- not a finished product.  The DT will be closed once=
 we
have a WG document on this topic.
 
The poll ends Monday April 27th
Thanks,
Lou (and Pavan, who is a co-author)
 
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.iet=
f.org/mailman/listinfo/teas




_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.iet=
f.org/mailman/listinfo/teas
--_000_4A1562797D64E44993C5CBF38CF1BE48128EA96BESESSMB301erics_-- From nobody Tue Apr 21 19:12:36 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07CC01B3070 for ; Tue, 21 Apr 2015 19:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydz0POqnn2KZ for ; Tue, 21 Apr 2015 19:12:32 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2231A86EF for ; Tue, 21 Apr 2015 19:12:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: "'Dieter Beller'" , "'Lou Berger'" , "'TEAS WG'" References: <552C0611.70500@labn.net> <55315820.70304@alcatel-lucent.com> <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> <553648A8.5070800@alcatel-lucent.com> In-Reply-To: <553648A8.5070800@alcatel-lucent.com> Date: Tue, 21 Apr 2015 22:12:26 -0400 Message-ID: <00c101d07ca1$c8b3f480$5a1bdd80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_01D07C80.41A6E860" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMTEhcf0WlBqFkj/ZCSupbxwsGBUgHwgZL8Ar6YHAsCmVvBNJqY2uCQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 02:12:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C2_01D07C80.41A6E860 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dieter: Thank you for answer the hierarchy question. Your abstract topologies reates arbitrary number of levels in a hierarchy. The question for the wide-topologies can be restated at Layer 3 as multiple VPNS. In IP, You can create 1-N number of VPNs. This is n-wide topologies. Does this fit into your abstract topologies? Sue From: Dieter Beller [mailto:Dieter.Beller@alcatel-lucent.com] Sent: Tuesday, April 21, 2015 8:55 AM To: Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Hi Sue, all, On 20.04.2015 07:47, Susan Hares wrote: Dieter: Do you think the arbitrary number of TE topologies are arbitrary in a hierarchy (1-N levels) or a wide topologies (1-N topologies). I am having some difficulties to really understand your question. Let me try to clarify what I meant with my comment: An abstract topology is according to my understanding composed of links and vertices (nodes) and a vertex could be an abstract node that represents an underlying abstract topology. This underlying abstract topology can be decomposed again into links and vertices (nodes) when you zoom into an abstract node. Based on this principle of recursion, you can create a hierarchy that can have arbitrary levels and a further decomposition is possible until you have not reached the physical node level (bottom of the hierarchy). I hope this helps. Thanks, Dieter Sue From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Friday, April 17, 2015 3:00 PM To: Lou Berger; TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Hi Lou, all, yes/support - however, other than +1 to comments from Paul, Young, and Xian, I would like to emphasize again what I commented during the discussion in Dallas: An introduction and a description of the information model (similar to that in draft-ietf-i2rs-yang-network-topo-00) is needed in the beginning of the document that explains the YANG data model. This section would describe the relationships of the managed entities (objects) and their attributes with references to the YANG model tree structure and the model definition. Moreover, for example in the context of ACTN, the model also needs to describe how it can support an arbitrary number of TE topology hierarchies. I have seen that the current model already provides some means for that, but this should be described in more detail and some examples should be provided. Thanks, Dieter On 13.04.2015 20:08, Lou Berger wrote: All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and the intent is for this work to serve as the foundation for the WG's normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product. The DT will be closed once we have a WG document on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas ------=_NextPart_000_00C2_01D07C80.41A6E860 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dieter:

 

Thank you for answer the hierarchy question.   Your = abstract topologies reates arbitrary number of levels in a hierarchy. =

 

The question for the wide-topologies can be restated at Layer 3 as = multiple VPNS.   In IP, You can create 1-N number of = VPNs.  This is n-wide topologies. Does this fit into your abstract = topologies?

 

Sue

 

From: Dieter Beller [mailto:Dieter.Beller@alcatel-lucent.com] =
Sent: Tuesday, April 21, 2015 8:55 AM
To: Susan = Hares; 'Lou Berger'; 'TEAS WG'
Subject: Re: [Teas] Poll on = making draft-liu-teas-yang-te-topo-01 a WG = document

 

Hi Sue, = all,

On = 20.04.2015 07:47, Susan Hares wrote:

Dieter:

 

Do you think the arbitrary number of TE topologies are arbitrary in a = hierarchy (1-N levels) or a wide topologies (1-N topologies). =

I am having some = difficulties to really understand your question. Let me try to clarify = what I meant with my comment:

An abstract topology is according = to my understanding composed of links and vertices (nodes) and a vertex = could be an abstract
node that represents an underlying abstract = topology. This underlying abstract topology can be decomposed again into = links and
vertices (nodes) when you zoom into an abstract = node.

Based on this principle of recursion, you can create a = hierarchy that can have arbitrary levels and a further decomposition is = possible
until you have not reached the physical node level (bottom = of the hierarchy).

I hope this = helps.


Thanks,
Dieter
 

 

Sue

 

From: Teas [mailto:teas-bounces@ietf.org] = On Behalf Of Dieter Beller
Sent: Friday, April 17, 2015 = 3:00 PM
To: Lou Berger; TEAS WG
Subject: Re: [Teas] = Poll on making draft-liu-teas-yang-te-topo-01 a WG = document

 

Hi Lou, all,

yes/support - = however, other than +1 to comments from Paul, Young, and Xian, I would = like to emphasize again what I commented
during the discussion in = Dallas:

An introduction and a description of the information = model (similar to that in draft-ietf-i2rs-yang-network-topo-00) is = needed in the
beginning of the document that explains the YANG data = model. This section would describe the relationships of the managed = entities
(objects) and their attributes with references to the YANG = model tree structure and the model definition.

Moreover, for = example in the context of ACTN, the model also needs to describe how it = can support an arbitrary number of TE
topology = hierarchies.  I have seen that the current model already = provides some means for that, but this should be described in
more = detail and some examples should be = provided.


Thanks,
Dieter


On 13.04.2015 20:08, Lou Berger = wrote:

All,
= 
 
This is start of a two week poll on =
making
draft-liu-teas-yang-te-topo-01 a TEAS =
working group document. Please
send email to the =
list indicating “yes/support” or “no/do not =
support”.
If indicating no, please state your =
technical reservations with the
document.  If =
yes, please also feel free to provide comments you'd =
like
to see addressed once the document is a WG =
document.
 
This document =
is the product of the TE Topology YANG Model Design =
Team
and the intent is for this work to serve as =
the foundation for the WG's
normal activities in =
this area, i.e., the document is the starting =
point
for the WG -- not a finished product.  =
The DT will be closed once we
have a WG document on =
this topic.
 
The poll =
ends Monday April =
27th
Thanks,
Lou (and Pavan, =
who is a =
co-author)
 
_____________=
__________________________________
Teas mailing =
list
Teas@ietf.org
https://www.ietf.org/=
mailman/listinfo/teas




_______________________=
________________________
Teas mailing =
list
Teas@ietf.org
https://www.ietf.org/=
mailman/listinfo/teas
------=_NextPart_000_00C2_01D07C80.41A6E860-- From nobody Tue Apr 21 19:14:05 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA291B3070 for ; Tue, 21 Apr 2015 19:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3Cae8G0RFmV for ; Tue, 21 Apr 2015 19:14:00 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 43B811B306C for ; Tue, 21 Apr 2015 19:14:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: "'Daniele Ceccarelli'" , "'Dieter Beller'" , "'Lou Berger'" , "'TEAS WG'" References: <552C0611.70500@labn.net> <55315820.70304@alcatel-lucent.com> <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> <553648A8.5070800@alcatel-lucent.com> <4A1562797D64E44993C5CBF38CF1BE48128EA137@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48128EA137@ESESSMB301.ericsson.se> Date: Tue, 21 Apr 2015 22:13:54 -0400 Message-ID: <00ce01d07ca1$fd9eb540$f8dc1fc0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01D07C80.7691A920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMTEhcf0WlBqFkj/ZCSupbxwsGBUgHwgZL8Ar6YHAsCmVvBNAKv9xN3moNcHHA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 02:14:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CF_01D07C80.7691A920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Daniele:=20 =20 You are correct. Dieter has given the hierarchy. The wide topologies = is the split of the bigger topology into smaller domains (in layer 3 VPNs). = =20 =20 I also think we should consider both.=20 =20 Sue=20 =20 =20 From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]=20 Sent: Tuesday, April 21, 2015 9:39 AM To: Dieter Beller; Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: RE: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document =20 Agree Dieter, and I think this maps to =93hierarchy=94 in Susan=92 = commets. =20 Actually, if my understanding of =93wide topology=94 is correct (I guess = it refers to the split of a big topology in smaller =93domains=94) I think = that we should consider both. =20 BR Daniele =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: marted=EC 21 aprile 2015 14:55 To: Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document =20 Hi Sue, all, On 20.04.2015 07:47, Susan Hares wrote: Dieter:=20 =20 Do you think the arbitrary number of TE topologies are arbitrary in a hierarchy (1-N levels) or a wide topologies (1-N topologies).=20 I am having some difficulties to really understand your question. Let me = try to clarify what I meant with my comment: An abstract topology is according to my understanding composed of links = and vertices (nodes) and a vertex could be an abstract node that represents an underlying abstract topology. This underlying abstract topology can be decomposed again into links and vertices (nodes) when you zoom into an abstract node. Based on this principle of recursion, you can create a hierarchy that = can have arbitrary levels and a further decomposition is possible until you have not reached the physical node level (bottom of the hierarchy). I hope this helps. Thanks, Dieter =20 =20 Sue=20 =20 From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Friday, April 17, 2015 3:00 PM To: Lou Berger; TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document =20 Hi Lou, all, yes/support - however, other than +1 to comments from Paul, Young, and = Xian, I would like to emphasize again what I commented during the discussion in Dallas: An introduction and a description of the information model (similar to = that in draft-ietf-i2rs-yang-network-topo-00) is needed in the beginning of the document that explains the YANG data model. This = section would describe the relationships of the managed entities (objects) and their attributes with references to the YANG model tree structure and the model definition. Moreover, for example in the context of ACTN, the model also needs to describe how it can support an arbitrary number of TE topology hierarchies. I have seen that the current model already = provides some means for that, but this should be described in more detail and some examples should be provided. Thanks, Dieter On 13.04.2015 20:08, Lou Berger wrote: All, =20 This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send email to the list indicating =93yes/support=94 or =93no/do not = support=94. If indicating no, please state your technical reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. =20 This document is the product of the TE Topology YANG Model Design Team and the intent is for this work to serve as the foundation for the WG's normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product. The DT will be closed once we have a WG document on this topic. =20 The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) =20 _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas ------=_NextPart_000_00CF_01D07C80.7691A920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Daniele:

 

You are correct.=A0 Dieter has given the hierarchy.=A0=A0 =A0The wide = topologies is the split of the bigger topology into smaller domains (in = layer 3 VPNs).=A0

 

I also think we should consider both.

 

Sue

 

 

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] =
Sent: Tuesday, April 21, 2015 9:39 AM
To: Dieter = Beller; Susan Hares; 'Lou Berger'; 'TEAS WG'
Subject: RE: = [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG = document

 

Agree Dieter, and I think this maps to “hierarchy” in = Susan’ commets.

 

Actually, if my understanding of “wide topology” is = correct (I guess it refers to the split of a big topology in smaller = “domains”) I think that we should consider = both.

 

BR
Daniele

 

From: Teas [mailto:teas-bounces@ietf.org] = On Behalf Of Dieter Beller
Sent: marted=EC 21 aprile = 2015 14:55
To: Susan Hares; 'Lou Berger'; 'TEAS = WG'
Subject: Re: [Teas] Poll on making = draft-liu-teas-yang-te-topo-01 a WG = document

 

Hi Sue, = all,


On = 20.04.2015 07:47, Susan Hares wrote:

Dieter:

 

Do you think the arbitrary number of TE topologies are arbitrary in a = hierarchy (1-N levels) or a wide topologies (1-N topologies). =

I am having some = difficulties to really understand your question. Let me try to clarify = what I meant with my comment:

An abstract topology is according = to my understanding composed of links and vertices (nodes) and a vertex = could be an abstract
node that represents an underlying abstract = topology. This underlying abstract topology can be decomposed again into = links and
vertices (nodes) when you zoom into an abstract = node.

Based on this principle of recursion, you can create a = hierarchy that can have arbitrary levels and a further decomposition is = possible
until you have not reached the physical node level (bottom = of the hierarchy).

I hope this = helps.


Thanks,
Dieter
  =


 

Sue

 

From: Teas [mailto:teas-bounces@ietf.org] = On Behalf Of Dieter Beller
Sent: Friday, April 17, 2015 = 3:00 PM
To: Lou Berger; TEAS WG
Subject: Re: [Teas] = Poll on making draft-liu-teas-yang-te-topo-01 a WG = document

 

Hi Lou, all,

yes/support - = however, other than +1 to comments from Paul, Young, and Xian, I would = like to emphasize again what I commented
during the discussion in = Dallas:

An introduction and a description of the information = model (similar to that in draft-ietf-i2rs-yang-network-topo-00) is = needed in the
beginning of the document that explains the YANG data = model. This section would describe the relationships of the managed = entities
(objects) and their attributes with references to the YANG = model tree structure and the model definition.

Moreover, for = example in the context of ACTN, the model also needs to describe how it = can support an arbitrary number of TE
topology = hierarchies.  I have seen that the current model already = provides some means for that, but this should be described in
more = detail and some examples should be = provided.


Thanks,
Dieter



On 13.04.2015 20:08, Lou Berger = wrote:

All,
= 
 
This is start of a two week poll on =
making
draft-liu-teas-yang-te-topo-01 a TEAS =
working group document. Please
send email to the =
list indicating “yes/support” or “no/do not =
support”.
If indicating no, please state your =
technical reservations with the
document.  If =
yes, please also feel free to provide comments you'd =
like
to see addressed once the document is a WG =
document.
 
This document =
is the product of the TE Topology YANG Model Design =
Team
and the intent is for this work to serve as =
the foundation for the WG's
normal activities in =
this area, i.e., the document is the starting =
point
for the WG -- not a finished product.  =
The DT will be closed once we
have a WG document on =
this topic.
 
The poll =
ends Monday April =
27th
Thanks,
Lou (and Pavan, =
who is a =
co-author)
 
_____________=
__________________________________
Teas mailing =
list
Teas@ietf.org
https://www.ietf.org/=
mailman/listinfo/teas





___________________=
____________________________
Teas mailing =
list
Teas@ietf.org
https://www.ietf.org/=
mailman/listinfo/teas
------=_NextPart_000_00CF_01D07C80.7691A920-- From nobody Tue Apr 21 19:52:59 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610891A1BC9 for ; Tue, 21 Apr 2015 19:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.355 X-Spam-Level: X-Spam-Status: No, score=-96.355 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFJcTGa3XxJs for ; Tue, 21 Apr 2015 19:52:57 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0041A1BC3 for ; Tue, 21 Apr 2015 19:52:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=125.205.241.158; From: "Susan Hares" To: "'Loa Andersson'" , References: <552C0611.70500@labn.net> <5534FDED.3090906@pi.nu> In-Reply-To: <5534FDED.3090906@pi.nu> Date: Tue, 21 Apr 2015 22:52:51 -0400 Message-ID: <00f501d07ca7$6e1384e0$4a3a8ea0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMTEhcf0WlBqFkj/ZCSupbxwsGBUgIFOU00AXjSJb+atzo/oA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 02:52:58 -0000 +1 to Loa and Xian's comments. Sue -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Monday, April 20, 2015 9:24 AM To: teas@ietf.org Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Lou, et.al., I'm on the same page as Xian, support the adoption but there are comments that need addressed. /Loa On 2015-04-14 03:12, Zhangxian (Xian) wrote: > Yes/support. > > I would like see the changes mentioned and comments raised during > IETF92 to be reflected either within this document or in another form. > Paul already provides a good summary, besides the minutes, I see no > need to repeat. :-) > > Regards, > Xian > > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger > Sent: 2015$BG/(B4$B7n(B14$BF|(B 2:08 > To: TEAS WG > Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG > document > > All, > > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please > send email to the list indicating $B!H(Byes/support$B!I(B or $B!H(Bno/do not support$B!I(B. > If indicating no, please state your technical reservations with the > document. If yes, please also feel free to provide comments you'd > like to see addressed once the document is a WG document. > > This document is the product of the TE Topology YANG Model Design Team > and the intent is for this work to serve as the foundation for the > WG's normal activities in this area, i.e., the document is the > starting point for the WG -- not a finished product. The DT will be > closed once we have a WG document on this topic. > > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Wed Apr 22 02:33:12 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90FC1B3378 for ; Wed, 22 Apr 2015 02:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPVKRmJJzxtZ for ; Wed, 22 Apr 2015 02:33:08 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2641A1AC1 for ; Wed, 22 Apr 2015 02:33:08 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id C1C167321149; Wed, 22 Apr 2015 09:33:02 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3M9X1Mx020126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Apr 2015 11:33:04 +0200 Received: from [149.204.107.61] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 22 Apr 2015 11:33:03 +0200 Message-ID: <55376ACE.4080402@alcatel-lucent.com> Date: Wed, 22 Apr 2015 11:33:02 +0200 From: Dieter Beller Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Susan Hares , "'Daniele Ceccarelli'" , "'Lou Berger'" , "'TEAS WG'" References: <552C0611.70500@labn.net> <55315820.70304@alcatel-lucent.com> <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> <553648A8.5070800@alcatel-lucent.com> <4A1562797D64E44993C5CBF38CF1BE48128EA137@ESESSMB301.ericsson.se> <00ce01d07ca1$fd9eb540$f8dc1fc0$@ndzh.com> In-Reply-To: <00ce01d07ca1$fd9eb540$f8dc1fc0$@ndzh.com> Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.39] Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 09:33:10 -0000 +1 that we should consider both


Thanks,
Dieter


On 22.04.2015 04:13, Susan Hares wrote:

Daniele:

You are correct. Dieter has given the hierarchy. The wide topologies is the split of the bigger topology into smaller domains (in layer 3 VPNs).

I also think we should consider both.

Sue

From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
Sent: Tuesday, April 21, 2015 9:39 AM
To: Dieter Beller; Susan Hares; 'Lou Berger'; 'TEAS WG'
Subject: RE: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document

Agree Dieter, and I think this maps to hierarchy in Susan commets.

Actually, if my understanding of wide topology is correct (I guess it refers to the split of a big topology in smaller domains) I think that we should consider both.

BR
Daniele

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: marted 21 aprile 2015 14:55
To: Susan Hares; 'Lou Berger'; 'TEAS WG'
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document

Hi Sue, all,


On 20.04.2015 07:47, Susan Hares wrote:

Dieter:

Do you think the arbitrary number of TE topologies are arbitrary in a hierarchy (1-N levels) or a wide topologies (1-N topologies).

I am having some difficulties to really understand your question. Let me try to clarify what I meant with my comment:

An abstract topology is according to my understanding composed of links and vertices (nodes) and a vertex could be an abstract
node that represents an underlying abstract topology. This underlying abstract topology can be decomposed again into links and
vertices (nodes) when you zoom into an abstract node.

Based on this principle of recursion, you can create a hierarchy that can have arbitrary levels and a further decomposition is possible
until you have not reached the physical node level (bottom of the hierarchy).

I hope this helps.


Thanks,
Dieter



Sue

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Friday, April 17, 2015 3:00 PM
To: Lou Berger; TEAS WG
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document

Hi Lou, all,

yes/support - however, other than +1 to comments from Paul, Young, and Xian, I would like to emphasize again what I commented
during the discussion in Dallas:

An introduction and a description of the information model (similar to that in draft-ietf-i2rs-yang-network-topo-00) is needed in the
beginning of the document that explains the YANG data model. This section would describe the relationships of the managed entities
(objects) and their attributes with references to the YANG model tree structure and the model definition.

Moreover, for example in the context of ACTN, the model also needs to describe how it can support an arbitrary number of TE
topology hierarchies. I have seen that the current model already provides some means for that, but this should be described in
more detail and some examples should be provided.


Thanks,
Dieter



On 13.04.2015 20:08, Lou Berger wrote:

All,
This is start of a two week poll on making
draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please
send email to the list indicating yes/support or no/do not support.
If indicating no, please state your technical reservations with the
document. If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.
This document is the product of the TE Topology YANG Model Design Team
and the intent is for this work to serve as the foundation for the WG's
normal activities in this area, i.e., the document is the starting point
for the WG -- not a finished product. The DT will be closed once we
have a WG document on this topic.
The poll ends Monday April 27th
Thanks,
Lou (and Pavan, who is a co-author)
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas





_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
From nobody Wed Apr 22 06:09:02 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613DB1A00CF for ; Wed, 22 Apr 2015 06:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q-kEKicf9qn for ; Wed, 22 Apr 2015 06:08:57 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3E01A00FE for ; Wed, 22 Apr 2015 06:08:36 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t3MD8XoJ022047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Apr 2015 09:08:33 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 22 Apr 2015 09:08:33 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 22 Apr 2015 09:08:32 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1076.000; Wed, 22 Apr 2015 09:08:32 -0400 From: Igor Bryskin To: Susan Hares , "'Dieter Beller'" , "'Lou Berger'" , "'TEAS WG'" Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQey2GAB95GuNgEkaG8t87avkht51XsXgAgADeyACAAG5ucA== Date: Wed, 22 Apr 2015 13:08:31 +0000 Message-ID: <9079b663ee6646f0b7b083ba56b236db@ATL-SRV-MBX1.advaoptical.com> References: <552C0611.70500@labn.net> <55315820.70304@alcatel-lucent.com> <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> <553648A8.5070800@alcatel-lucent.com> <00c101d07ca1$c8b3f480$5a1bdd80$@ndzh.com> In-Reply-To: <00c101d07ca1$c8b3f480$5a1bdd80$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: multipart/alternative; boundary="_000_9079b663ee6646f0b7b083ba56b236dbATLSRVMBX1advaopticalco_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-22_03:2015-04-22,2015-04-22,1970-01-01 signatures=0 Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 13:09:01 -0000 --_000_9079b663ee6646f0b7b083ba56b236dbATLSRVMBX1advaopticalco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sue, I think you are exactly right. The model supports arbitrary number of TE to= pologies. Some of them are bound in hierarchies. There could be multiple i= ndependent hierarchies. For example, topologies cooked by provider on per- client or VPN is an exam= ple of independent topologies. Topology overlay/underlay relationships form= topology hierarchies. For example, a topology cooked for a particular clie= nt (overlay) is supported by provider native topology (underlay), and this = is an example of a hierarchy. Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, April 21, 2015 10:12 PM To: 'Dieter Beller'; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Dieter: Thank you for answer the hierarchy question. Your abstract topologies rea= tes arbitrary number of levels in a hierarchy. The question for the wide-topologies can be restated at Layer 3 as multiple= VPNS. In IP, You can create 1-N number of VPNs. This is n-wide topologi= es. Does this fit into your abstract topologies? Sue From: Dieter Beller [mailto:Dieter.Beller@alcatel-lucent.com] Sent: Tuesday, April 21, 2015 8:55 AM To: Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Sue, all, On 20.04.2015 07:47, Susan Hares wrote: Dieter: Do you think the arbitrary number of TE topologies are arbitrary in a hiera= rchy (1-N levels) or a wide topologies (1-N topologies). I am having some difficulties to really understand your question. Let me tr= y to clarify what I meant with my comment: An abstract topology is according to my understanding composed of links and= vertices (nodes) and a vertex could be an abstract node that represents an underlying abstract topology. This underlying abstr= act topology can be decomposed again into links and vertices (nodes) when you zoom into an abstract node. Based on this principle of recursion, you can create a hierarchy that can h= ave arbitrary levels and a further decomposition is possible until you have not reached the physical node level (bottom of the hierarchy= ). I hope this helps. Thanks, Dieter Sue From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Friday, April 17, 2015 3:00 PM To: Lou Berger; TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Lou, all, yes/support - however, other than +1 to comments from Paul, Young, and Xian= , I would like to emphasize again what I commented during the discussion in Dallas: An introduction and a description of the information model (similar to that= in draft-ietf-i2rs-yang-network-topo-00) is needed in the beginning of the document that explains the YANG data model. This section w= ould describe the relationships of the managed entities (objects) and their attributes with references to the YANG model tree struc= ture and the model definition. Moreover, for example in the context of ACTN, the model also needs to descr= ibe how it can support an arbitrary number of TE topology hierarchies. I have seen that the current model already provides = some means for that, but this should be described in more detail and some examples should be provided. Thanks, Dieter On 13.04.2015 20:08, Lou Berger wrote: All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and the intent is for this work to serve as the foundation for the WG's normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product. The DT will be closed once we have a WG document on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_9079b663ee6646f0b7b083ba56b236dbATLSRVMBX1advaopticalco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sue,

 

I think you are exactly right. The model supports arbi= trary number of TE topologies. Some of them are bound  in hierarchies.= There could be multiple independent hierarchies.

For example, topologies cooked by provider on per- cli= ent or VPN is an example of independent topologies. Topology overlay/underl= ay relationships form topology hierarchies. For example, a topology cooked for a particular client (overlay) is supported = by provider native topology (underlay), and this is an example of a hierarc= hy.

 

Cheers,

Igor

 

From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, April 21, 2015 10:12 PM
To: 'Dieter Beller'; 'Lou Berger'; 'TEAS WG'
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Dieter:

 

Thank you for answer the hierarchy qu= estion.   Your abstract topologies reates arbitrary number of lev= els in a hierarchy.

 

The question for the wide-topologies = can be restated at Layer 3 as multiple VPNS.   In IP, You can cre= ate 1-N number of VPNs.  This is n-wide topologies. Does this fit into your abstract topologies?

 

Sue

 

From: Dieter Beller [mailto= :Dieter.Beller@alcatel-lucent.com]
Sent: Tuesday, April 21, 2015 8:55 AM
To: Susan Hares; 'Lou Berger'; 'TEAS WG'
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Hi Sue, all,

On 20.04.2015 07:47, Susan Hares wrote:

Dieter:

 

Do you think the arbitrary number of = TE topologies are arbitrary in a hierarchy (1-N levels) or a wide topologie= s (1-N topologies).

I am having some diff= iculties to really understand your question. Let me try to clarify what I m= eant with my comment:

An abstract topology is according to my understanding composed of links and= vertices (nodes) and a vertex could be an abstract
node that represents an underlying abstract topology. This underlying abstr= act topology can be decomposed again into links and
vertices (nodes) when you zoom into an abstract node.

Based on this principle of recursion, you can create a hierarchy that can h= ave arbitrary levels and a further decomposition is possible
until you have not reached the physical node level (bottom of the hierarchy= ).

I hope this helps.


Thanks,
Dieter
 

 

Sue

 

From: Teas [mailto:teas-bounces@ietf.o= rg] On Behalf Of Dieter Beller
Sent: Friday, April 17, 2015 3:00 PM
To: Lou Berger; TEAS WG
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Hi Lou, all,

yes/support - however, other than +1 to comments from Paul, Young, and = Xian, I would like to emphasize again what I commented
during the discussion in Dallas:

An introduction and a description of the information model (similar to that= in draft-ietf-i2rs-yang-network-topo-00) is needed in the
beginning of the document that explains the YANG data model. This section w= ould describe the relationships of the managed entities
(objects) and their attributes with references to the YANG model tree struc= ture and the model definition.

Moreover, for example in the context of ACTN, the model also needs to descr= ibe how it can support an arbitrary number of TE
topology hierarchies.  I have seen that the current model already = provides some means for that, but this should be described in
more detail and some examples should be provided.


Thanks,
Dieter

On 13.04.2015 20:08, Lou Berger wrote: 

All,
 
This is start of a two week poll on making
draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please
send email to the list indicating “yes/support” or “=
no/do not support”.
If indicating no, please state your technical reservations with the
document.  If yes, please also feel free to provide comments you'=
d like
to see addressed once the document is a WG document.
 
This document is the product of the TE Topology YANG Model Design Team=

and the intent is for this work to serve as the foundation for the WG'=
s
normal activities in this area, i.e., the document is the starting poi=
nt
for the WG -- not a finished product.  The DT will be closed once=
 we
have a WG document on this topic.
 
The poll ends Monday April 27th
Thanks,
Lou (and Pavan, who is a co-author)
 
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.iet=
f.org/mailman/listinfo/teas



_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.iet=
f.org/mailman/listinfo/teas
--_000_9079b663ee6646f0b7b083ba56b236dbATLSRVMBX1advaopticalco_-- From nobody Wed Apr 22 06:51:47 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254711A90FD for ; Wed, 22 Apr 2015 06:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qt8rZvjJvNwk for ; Wed, 22 Apr 2015 06:51:39 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046B91A90F3 for ; Wed, 22 Apr 2015 06:51:39 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 14D9EE591D463; Wed, 22 Apr 2015 13:51:34 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t3MDpZZ4006049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Apr 2015 15:51:35 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 15:51:35 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Igor Bryskin , Susan Hares , "Beller, Dieter (Dieter)" , "'Lou Berger'" , "'TEAS WG'" Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQey2FIBj7yF4xq06Iqba2nJF52J1XTOMAgADeyACAALdPgIAAK6TA Date: Wed, 22 Apr 2015 13:51:35 +0000 Message-ID: References: <552C0611.70500@labn.net> <55315820.70304@alcatel-lucent.com> <002b01d07b2d$7e45c1f0$7ad145d0$@ndzh.com> <553648A8.5070800@alcatel-lucent.com> <00c101d07ca1$c8b3f480$5a1bdd80$@ndzh.com> <9079b663ee6646f0b7b083ba56b236db@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: <9079b663ee6646f0b7b083ba56b236db@ATL-SRV-MBX1.advaoptical.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B75CC0A5FR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 13:51:44 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75CC0A5FR711WXCHMBA05z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Igor, while we all agree in the needs of both type of topology requirements , I w= ould just clarify that the Dieter's comment, that I have shared during my p= ositive vote for "support" of the draft, is addressing "recursion" , and I = do not see recursion is linked to "independent topologies" but only to hier= archies (overlay/underlay relationship in the draft). Thanks Cheers Sergio From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: mercoled=EC 22 aprile 2015 15:09 To: Susan Hares; Beller, Dieter (Dieter); 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Sue, I think you are exactly right. The model supports arbitrary number of TE to= pologies. Some of them are bound in hierarchies. There could be multiple i= ndependent hierarchies. For example, topologies cooked by provider on per- client or VPN is an exam= ple of independent topologies. Topology overlay/underlay relationships form= topology hierarchies. For example, a topology cooked for a particular clie= nt (overlay) is supported by provider native topology (underlay), and this = is an example of a hierarchy. Cheers, Igor From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, April 21, 2015 10:12 PM To: 'Dieter Beller'; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Dieter: Thank you for answer the hierarchy question. Your abstract topologies rea= tes arbitrary number of levels in a hierarchy. The question for the wide-topologies can be restated at Layer 3 as multiple= VPNS. In IP, You can create 1-N number of VPNs. This is n-wide topologi= es. Does this fit into your abstract topologies? Sue From: Dieter Beller [mailto:Dieter.Beller@alcatel-lucent.com] Sent: Tuesday, April 21, 2015 8:55 AM To: Susan Hares; 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Sue, all, On 20.04.2015 07:47, Susan Hares wrote: Dieter: Do you think the arbitrary number of TE topologies are arbitrary in a hiera= rchy (1-N levels) or a wide topologies (1-N topologies). I am having some difficulties to really understand your question. Let me tr= y to clarify what I meant with my comment: An abstract topology is according to my understanding composed of links and= vertices (nodes) and a vertex could be an abstract node that represents an underlying abstract topology. This underlying abstr= act topology can be decomposed again into links and vertices (nodes) when you zoom into an abstract node. Based on this principle of recursion, you can create a hierarchy that can h= ave arbitrary levels and a further decomposition is possible until you have not reached the physical node level (bottom of the hierarchy= ). I hope this helps. Thanks, Dieter Sue From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller Sent: Friday, April 17, 2015 3:00 PM To: Lou Berger; TEAS WG Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG docu= ment Hi Lou, all, yes/support - however, other than +1 to comments from Paul, Young, and Xian= , I would like to emphasize again what I commented during the discussion in Dallas: An introduction and a description of the information model (similar to that= in draft-ietf-i2rs-yang-network-topo-00) is needed in the beginning of the document that explains the YANG data model. This section w= ould describe the relationships of the managed entities (objects) and their attributes with references to the YANG model tree struc= ture and the model definition. Moreover, for example in the context of ACTN, the model also needs to descr= ibe how it can support an arbitrary number of TE topology hierarchies. I have seen that the current model already provides = some means for that, but this should be described in more detail and some examples should be provided. Thanks, Dieter On 13.04.2015 20:08, Lou Berger wrote: All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and the intent is for this work to serve as the foundation for the WG's normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product. The DT will be closed once we have a WG document on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75CC0A5FR711WXCHMBA05z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Igor,

while we a= ll agree in the needs of both type of topology requirements , I would just = clarify that the Dieter’s comment, that I have shared during my positive vote for “support” of the draft, is addressing = 220;recursion” , and I do not see recursion is linked to “independent topologies” but only to hierar= chies (overlay/underlay relationship in the draft).

 

Thanks

Cheers

 

Sergio

 = ;

 <= /p>

 <= /p>

From:= Teas [mailto:teas-b= ounces@ietf.org] On Behalf Of Igor Bryskin
Sent: mercoled=EC 22 aprile 2015 15:09
To: Susan Hares; Beller, Dieter (Dieter); 'Lou Berger'; 'TEAS WG' Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Sue,

 

I think you are exactly rig= ht. The model supports arbitrary number of TE topologies. Some of them are = bound  in hierarchies. There could be multiple independent hierarchies.

For example, topologies coo= ked by provider on per- client or VPN is an example of independent topologi= es. Topology overlay/underlay relationships form topology hierarchies. For example, a topology cooked for a particular client (overl= ay) is supported by provider native topology (underlay), and this is an exa= mple of a hierarchy.

 

Cheers,

Igor

 

From= : Teas [mailto:teas-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, April 21, 2015 10:12 PM
To: 'Dieter Beller'; 'Lou Berger'; 'TEAS WG'
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Dieter:

 = ;

Thank you = for answer the hierarchy question.   Your abstract topologies rea= tes arbitrary number of levels in a hierarchy.

 = ;

The questi= on for the wide-topologies can be restated at Layer 3 as multiple VPNS.&nbs= p;  In IP, You can create 1-N number of VPNs.  This is n-wide top= ologies. Does this fit into your abstract topologies?

 = ;

Sue

 = ;

From:= Dieter Beller [mailto:Dieter.Beller@alcate= l-lucent.com]
Sent: Tuesday, April 21, 2015 8:55 AM
To: Susan Hares; 'Lou Berger'; 'TEAS WG'
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

Hi Sue, all= ,

On 20.04.2015 07:47, Susan Hare= s wrote:

Dieter:

 

Do you thi= nk the arbitrary number of TE topologies are arbitrary in a hierarchy (1-N = levels) or a wide topologies (1-N topologies).

= I am having some difficulties to really understand your question. Let me tr= y to clarify what I meant with my comment:

An abstract topology is according to my understanding composed of links and= vertices (nodes) and a vertex could be an abstract
node that represents an underlying abstract topology. This underlying abstr= act topology can be decomposed again into links and
vertices (nodes) when you zoom into an abstract node.

Based on this principle of recursion, you can create a hierarchy that can h= ave arbitrary levels and a further decomposition is possible
until you have not reached the physical node level (bottom of the hierarchy= ).

I hope this helps.


Thanks,
Dieter
 

 

Sue

 

From:= Teas [mailto:teas-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Friday, April 17, 2015 3:00 PM
To: Lou Berger; TEAS WG
Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a = WG document

 

= Hi Lou, all,

yes/support - however, other than +1 to comments from Paul, Young, and = Xian, I would like to emphasize again what I commented
during the discussion in Dallas:

An introduction and a description of the information model (similar to that= in draft-ietf-i2rs-yang-network-topo-00) is needed in the
beginning of the document that explains the YANG data model. This section w= ould describe the relationships of the managed entities
(objects) and their attributes with references to the YANG model tree struc= ture and the model definition.

Moreover, for example in the context of ACTN, the model also needs to descr= ibe how it can support an arbitrary number of TE
topology hierarchies.  I have seen that the current model already = provides some means for that, but this should be described in
more detail and some examples should be provided.


Thanks,
Dieter

On 13.04.2015 20:08, Lou Berger= wrote:

All,
 
This is start of a two week poll on making
draft-liu-teas-yang-te-topo-01 a TEAS working gro=
up document. Please
send email to the list indicating “yes/supp=
ort” or “no/do not support”.
If indicating no, please state your technical res=
ervations with the
document.  If yes, please also feel free to =
provide comments you'd like
to see addressed once the document is a WG docume=
nt.
 
This document is the product of the TE Topology Y=
ANG Model Design Team
and the intent is for this work to serve as the f=
oundation for the WG's
normal activities in this area, i.e., the documen=
t is the starting point
for the WG -- not a finished product.  The D=
T will be closed once we
have a WG document on this topic.
 
The poll ends Monday April 27th=

Thanks,
Lou (and Pavan, who is a co-author)
 
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas

=  

_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
--_000_B9FEE68CE3A78C41A2B3C67549A96F48B75CC0A5FR711WXCHMBA05z_-- From nobody Thu Apr 23 12:54:16 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704851B31C0 for ; Thu, 23 Apr 2015 12:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sb3grnhYvdn for ; Thu, 23 Apr 2015 12:54:14 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 8D7B51B31F1 for ; Thu, 23 Apr 2015 12:54:04 -0700 (PDT) Received: (qmail 23067 invoked by uid 0); 23 Apr 2015 19:54:04 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy10.mail.unifiedlayer.com with SMTP; 23 Apr 2015 19:54:04 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id KXtz1q00B2SSUrH01Xu2sJ; Thu, 23 Apr 2015 13:54:02 -0600 X-Authority-Analysis: v=2.1 cv=Zox+dbLG c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=SY9aFQKHIdAA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=e9J7MTPGsLIA:10 a=48vgC7mUAAAA:8 a=UtnS-hyFfZd_Vmkr5DgA:9 a=QEXdDO2ut3YA:10 a=Lu4_bd1KnGEA:10 a=ghy5xKS9JiAA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=xFTtJ6UCJCYQugid8HpFN+ThGiaIqZTYLuUvy2MD0z0=; b=RE+3NpZyjOBNMvcYo3Tn5eYunqneeP4P4dfENeBID2fb0CzeOoQye61WB+eBMvEGyaoU7dM9HXNT47OLctXXyEX5iS/sBsgu7suj9JBnM76nBaazcHBLuqfpGBHWsEyy; Received: from box313.bluehost.com ([69.89.31.113]:54385 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YlNCD-0003YC-4J for teas@ietf.org; Thu, 23 Apr 2015 13:54:01 -0600 Message-ID: <55394DD0.1050109@labn.net> Date: Thu, 23 Apr 2015 15:53:52 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: TEAS WG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [Teas] New Wiki: Some informal guidance for standards track protocol specifications X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2015 19:54:15 -0000 All, I thought it might be useful to document some topics that repeatedly get discussed during document reviews. I started an "informal" wiki on the topic. It is located at http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines . Please take a look at, comment/modify as you see fit. As chair, I ask that all WG authors review this guidance in anticipation of comment topics you're likely to see before/during WG LC. Thanks, Lou From nobody Sat Apr 25 02:05:59 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB81C1A00E9 for ; Sat, 25 Apr 2015 02:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESrjd907KGfQ for ; Sat, 25 Apr 2015 02:05:56 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEEE1A0065 for ; Sat, 25 Apr 2015 02:05:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVH93426; Sat, 25 Apr 2015 09:05:53 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 25 Apr 2015 10:05:53 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.205]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Sat, 25 Apr 2015 17:05:46 +0800 From: Fatai Zhang To: Lou Berger , TEAS WG Thread-Topic: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document Thread-Index: AQHQdhTcE3AWw1z7Xkmmf70LU8M77p1dgczA Date: Sat, 25 Apr 2015 09:05:46 +0000 Message-ID: References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 09:05:58 -0000 Yes/Support. Best Regards Fatai -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Tuesday, April 14, 2015 2:08 AM To: TEAS WG Subject: [Teas] Poll on making draft-liu-teas-yang-te-topo-01 a WG document All, This is start of a two week poll on making draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your technical reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. This document is the product of the TE Topology YANG Model Design Team and the intent is for this work to serve as the foundation for the WG's normal activities in this area, i.e., the document is the starting point for the WG -- not a finished product. The DT will be closed once we have a WG document on this topic. The poll ends Monday April 27th Thanks, Lou (and Pavan, who is a co-author) _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Sat Apr 25 02:21:49 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017C21A90E1 for ; Sat, 25 Apr 2015 02:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6kKQnz6PWhA for ; Sat, 25 Apr 2015 02:21:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127911A8939 for ; Sat, 25 Apr 2015 02:21:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVH94187; Sat, 25 Apr 2015 09:21:44 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 25 Apr 2015 10:21:44 +0100 Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.205]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Sat, 25 Apr 2015 17:21:38 +0800 From: Fatai Zhang To: Lou Berger , TEAS WG Thread-Topic: [Teas] New Wiki: Some informal guidance for standards track protocol specifications Thread-Index: AQHQff9L/fSgwUr2X0SxW0rctXf1kZ1ddiIw Date: Sat, 25 Apr 2015 09:21:37 +0000 Message-ID: References: <55394DD0.1050109@labn.net> In-Reply-To: <55394DD0.1050109@labn.net> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Teas] New Wiki: Some informal guidance for standards track protocol specifications X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 09:21:48 -0000 Hi Lou, Thanks for the text, which is quite useful.=20 Best Regards Fatai -----Original Message----- From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger Sent: Friday, April 24, 2015 3:54 AM To: TEAS WG Subject: [Teas] New Wiki: Some informal guidance for standards track protoc= ol specifications All, I thought it might be useful to document some topics that repeatedly get discussed during document reviews. I started an "informal" wiki on the topic. It is located at http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines . Please take a look at, comment/modify as you see fit.=20 As chair, I ask that all WG authors review this guidance in anticipation of comment topics you're likely to see before/during WG LC.=20 Thanks, Lou _______________________________________________ Teas mailing list Teas@ietf.org https://www.ietf.org/mailman/listinfo/teas From nobody Mon Apr 27 06:51:31 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389451A0399 for ; Mon, 27 Apr 2015 06:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_8zYo27RJgx for ; Mon, 27 Apr 2015 06:51:29 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 104921A039B for ; Mon, 27 Apr 2015 06:51:29 -0700 (PDT) Received: (qmail 23500 invoked by uid 0); 27 Apr 2015 13:51:22 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 27 Apr 2015 13:51:22 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id M1rE1q00A2SSUrH011rHXx; Mon, 27 Apr 2015 07:51:20 -0600 X-Authority-Analysis: v=2.1 cv=Zox+dbLG c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=SY9aFQKHIdAA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=e9J7MTPGsLIA:10 a=48vgC7mUAAAA:8 a=w9M7eC-bJZPrXpojXpEA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=eNq2TMbj5zB83huirfUIAOuYIA/faf7G5XheIAsDqEk=; b=HjP1pW/5aDP9HekpQ//SwuryPX90rGya/50nh3uw0KaFTH8mzfw51rRAf/IPaoDaTJJOvgJhcqiZ1lXWwzHxakBOC3DwgSC8bFZDd3z5Kmq0aUc4HTQOZIkP66clcUq4; Received: from box313.bluehost.com ([69.89.31.113]:59271 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YmjRM-00029d-1I; Mon, 27 Apr 2015 07:51:16 -0600 Message-ID: <553E3ECA.8080504@labn.net> Date: Mon, 27 Apr 2015 09:51:06 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: TEAS WG , draft-liu-teas-yang-te-topo@ietf.org References: <552C0611.70500@labn.net> In-Reply-To: <552C0611.70500@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [Teas] Poll on making draft-liu-teas-yang-te-topo a WG document X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 13:51:30 -0000 All, This draft is adopted. Authors, Please republish draft-liu-teas-yang-te-topo-01 as draft-ietf-teas-yang-te-topo-00 with the ONLY change being the name and date. Please publish any changes resulting from points raised during adoption, and other changes per normal WG process, starting with revision -01. Thank you, Lou On 4/13/2015 2:08 PM, Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-liu-teas-yang-te-topo-01 a TEAS working group document. Please > send email to the list indicating yes/support or no/do not support. > If indicating no, please state your technical reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > This document is the product of the TE Topology YANG Model Design Team > and the intent is for this work to serve as the foundation for the WG's > normal activities in this area, i.e., the document is the starting point > for the WG -- not a finished product. The DT will be closed once we > have a WG document on this topic. > > The poll ends Monday April 27th > Thanks, > Lou (and Pavan, who is a co-author) > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > > From nobody Mon Apr 27 06:51:45 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D1D1A039B for ; Mon, 27 Apr 2015 06:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFkA9ZzdWC3Y for ; Mon, 27 Apr 2015 06:51:43 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id DAEAD1A0389 for ; Mon, 27 Apr 2015 06:51:42 -0700 (PDT) Received: (qmail 22877 invoked by uid 0); 27 Apr 2015 13:51:41 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy9.mail.unifiedlayer.com with SMTP; 27 Apr 2015 13:51:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id M1rZ1q00k2SSUrH011rcE5; Mon, 27 Apr 2015 07:51:41 -0600 X-Authority-Analysis: v=2.1 cv=bfL4Do/B c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=SY9aFQKHIdAA:10 a=N659UExz7-8A:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=e9J7MTPGsLIA:10 a=OUXY8nFuAAAA:8 a=pmb6BNNbAAAA:8 a=OTfaxyS_AAAA:8 a=0FD05c-RAAAA:8 a=AUd_NHdVAAAA:8 a=FmoMKUsJAAAA:8 a=48vgC7mUAAAA:8 a=-5Gv9_IVK0KU8tG0fPgA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=f6en7XQWguQLUeVUysn8YVUaepILP6EwYs7CE269vj4=; b=1sOXiKzVDCuI3lnO8YRaiEO972LnxITxLFJ2UWcS6KO9W9cGimY9vHF+7EdH5LKjk4YoZSU0G4hvWz5SL++sYaedCRL8urEQRRAuwzuR5O19q2CI0a9jSlwL2v6oDujc; Received: from box313.bluehost.com ([69.89.31.113]:59285 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1YmjRd-0002D6-MH for teas@ietf.org; Mon, 27 Apr 2015 07:51:33 -0600 Message-ID: <553E3EE1.1070004@labn.net> Date: Mon, 27 Apr 2015 09:51:29 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: TEAS WG References: <5489970B.7070108@labn.net> In-Reply-To: <5489970B.7070108@labn.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: Re: [Teas] TE Topology YANG Model Design Team X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 13:51:44 -0000 All, With the (pending) publication of draft-ietf-teas-yang-te-topo-00, the chartered task of the Design Team has been achieved and the Design Team is closed. Work on draft-ietf-teas-yang-te-topo-00 will no progress per normal WG process. I'd like to thank and recognize the Design Team members (whose names are listed below) who worked very hard to successfully complete their task, and did so in the requested time. Lou On 12/11/2014 8:07 AM, Lou Berger wrote: > All, > We have formed a WG Design Team whose objective is to deliver a TE > Topology YANG Model draft in > time for discussion in Dallas. It is our intent that the document will > become a TEAS WG draft post Dallas. The scope of the design team is > intentionally narrow and the work of the DT will need to be coordinated > with other related YANG work -- and such coordination is the focus of > next week's interim meeting*. The DT will be closed once we have a WG > document adopted on this topic. > > While the DT has limited membership (and a limited lifespan), how the DT > works to produce it's individual draft(s) is up to the DT. For example > they may choose to publicize their calls/progress or not. We do > appreciate that not all who volunteered are include. Those who are > willing to provide input to the DT should contact them directly. Keep > in mind that there will be plenty of opportunity for input, per normal > WG process, once the DT's individual draft(s) are adopted as WG > documents. Again, thank you to all who volunteered. > > * - Next week's interim is of course open to all -- and we have an open > call for those who wish a discussion slot. The focus of the interim is > on the scope of the TE Topology YANG model and how it relates/ties-in > to other work. > > The members of the DT are: > Vishnu Pavan Beeram > Igor Bryskin > Oscar Gonzalez De Dios > Xufeng Liu > Tarek Saad > Himanshu Shah > > Deborah and Lou > > > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > > From nobody Thu Apr 30 06:03:08 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7626B1B29AE; Thu, 30 Apr 2015 06:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FY9xTNTynq6Q; Thu, 30 Apr 2015 06:03:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E69881B29CF; Thu, 30 Apr 2015 06:03:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150430130302.28745.62590.idtracker@ietfa.amsl.com> Date: Thu, 30 Apr 2015 06:03:02 -0700 Archived-At: Cc: teas@ietf.org Subject: [Teas] I-D Action: draft-ietf-teas-rsvp-te-domain-subobjects-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:03:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Traffic Engineering Architecture and Signaling Working Group of the IETF. Title : Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) Authors : Dhruv Dhody Udayasree Palle Venugopal Reddy Kondreddy Ramon Casellas Filename : draft-ietf-teas-rsvp-te-domain-subobjects-01.txt Pages : 16 Date : 2015-04-30 Abstract: The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) specification and the Generalized Multiprotocol Label Switching (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to be explicitly included in a path setup. Further Exclude Routes extensions to RSVP-TE allow abstract nodes and resources to be explicitly excluded in a path setup. This document specifies new subobjects to include or exclude domains during path setup where domain is a collection of network elements within a common sphere of address management or path computational responsibility (such as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS)). Note that the use of AS as an abstract node representing domain is already defined in existing RSVP-TE specefications, albeit with a 2-Byte AS number. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-domain-subobjects/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-domain-subobjects-01 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-domain-subobjects-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 30 06:07:08 2015 Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5321B29E3 for ; Thu, 30 Apr 2015 06:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsB8Zeyd2IFc for ; Thu, 30 Apr 2015 06:07:04 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105C21B29DE for ; Thu, 30 Apr 2015 06:07:04 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so74447561ied.1 for ; Thu, 30 Apr 2015 06:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=mxHu6RgFYG/T0SOhbWIaqyGungZjB5bH4waZOrz80uE=; b=Jlg9E6tFVBAibURMbr7KlcivqO//cWvKxwEM1+NJPRNgdfnIBxudUf7kz+WK+MSGB6 1v/gSt6K/HuP8Uej5ByAVJ/qKqiKmwHheaSHvFGuWC2PyvMqGPuw57eyhJaD105aPVup g+x/89K0sMcy1RvI5n5+MAx4k7NbIQJxPu/cU0nlE07+Y8It0YQJpVFhLw1g5GJOYiAD oHcZhY80ra+9xL+TR+g++vkcFYeHv4bnYMTNAlRbSgNj/fb0byFclBxyijJTcRjKr8lv 9k2l2KtoI/jaIuieK2eWSQngZjIAh6ytEqDcwaTk9AlK5HBhvlXCQYX+uXUq/kUDr55v ttLQ== MIME-Version: 1.0 X-Received: by 10.107.40.132 with SMTP id o126mr4530260ioo.68.1430399223392; Thu, 30 Apr 2015 06:07:03 -0700 (PDT) Sender: dhruvdhody@gmail.com X-Google-Sender-Delegation: dhruvdhody@gmail.com Received: by 10.50.54.229 with HTTP; Thu, 30 Apr 2015 06:07:03 -0700 (PDT) In-Reply-To: <20150430130302.28745.62590.idtracker@ietfa.amsl.com> References: <20150430130302.28745.62590.idtracker@ietfa.amsl.com> Date: Thu, 30 Apr 2015 18:37:03 +0530 X-Google-Sender-Auth: T0YpXkyVi1x3jIF1enrNlDjF8js Message-ID: From: Dhruv Dhody To: "TEAS WG (teas@ietf.org)" Content-Type: multipart/alternative; boundary=001a1141d548990fb10514f0c5da Archived-At: Subject: Re: [Teas] I-D Action: draft-ietf-teas-rsvp-te-domain-subobjects-01.txt X-BeenThere: teas@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Traffic Engineering Architecture and Signaling working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:07:07 -0000 --001a1141d548990fb10514f0c5da Content-Type: text/plain; charset=UTF-8 Hi WG, Based on the comments received during the PCE WG LC of the companion document, the TEAS I-D is also updated. During the update we have tried to also check as per the guidelines in the wiki ( http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines). Summary of the changes - - A section "scope" added to describe the experiment - 2119 language corrections - Correction in the Length field for ISIS subobject - Handling of unknown subobject (as per the existing specifications) - Update in IANA consideration - Changes in the References - Changes in the examples (appendix) Please check the diff at - https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-domain-subobjects-01 Thanks! Dhruv (on behalf of co-authors) On Thu, Apr 30, 2015 at 6:33 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Traffic Engineering Architecture and > Signaling Working Group of the IETF. > > Title : Domain Subobjects for Resource ReserVation > Protocol - Traffic Engineering (RSVP-TE) > Authors : Dhruv Dhody > Udayasree Palle > Venugopal Reddy Kondreddy > Ramon Casellas > Filename : draft-ietf-teas-rsvp-te-domain-subobjects-01.txt > Pages : 16 > Date : 2015-04-30 > > Abstract: > The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) > specification and the Generalized Multiprotocol Label Switching > (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to > be explicitly included in a path setup. Further Exclude Routes > extensions to RSVP-TE allow abstract nodes and resources to be > explicitly excluded in a path setup. > > This document specifies new subobjects to include or exclude domains > during path setup where domain is a collection of network elements > within a common sphere of address management or path computational > responsibility (such as an Interior Gateway Protocol (IGP) area or an > Autonomous System (AS)). Note that the use of AS as an abstract node > representing domain is already defined in existing RSVP-TE > specefications, albeit with a 2-Byte AS number. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-teas-rsvp-te-domain-subobjects/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-teas-rsvp-te-domain-subobjects-01 > > A diff from the previous version is available at: > https: > https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-rsvp-te-domain-subobjects-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > --001a1141d548990fb10514f0c5da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi WG,

Based on the comments received during t= he PCE WG LC of the companion document, the TEAS I-D is also updated. Durin= g the update we have tried to also check as per the guidelines in the wiki = (http= ://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines). =C2=A0

S= ummary of the changes -

- A section "scope" added to descr= ibe the experiment
- 2119 language corrections
- Correction in the Le= ngth field for ISIS subobject
- Handling of unknown subobject (as per th= e existing specifications)
- Update in IANA consideration
- Changes i= n the References
- Changes in the examples (appendix)

Please chec= k the diff at - https://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-teas-rsvp-te-domain-subobjects-01

Thanks!
Dhruv (on beh= alf of co-authors)

On Thu, Apr 30, 2015 at 6:33 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Traffic Engineering Architecture and= Signaling Working Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Domain Subobjects for Resource ReserVation Protocol - Traffic Engineering = (RSVP-TE)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Dhru= v Dhody
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Udayasree Palle
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Venugopal Reddy Kondreddy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ramon Casellas
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-teas-rsvp-te-domain-subobjects-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-04-30

Abstract:
=C2=A0 =C2=A0The Resource ReserVation Protocol - Traffic Engineering (RSVP-= TE)
=C2=A0 =C2=A0specification and the Generalized Multiprotocol Label Switchin= g
=C2=A0 =C2=A0(GMPLS) extensions to RSVP-TE allow abstract nodes and resourc= es to
=C2=A0 =C2=A0be explicitly included in a path setup.=C2=A0 Further Exclude = Routes
=C2=A0 =C2=A0extensions to RSVP-TE allow abstract nodes and resources to be=
=C2=A0 =C2=A0explicitly excluded in a path setup.

=C2=A0 =C2=A0This document specifies new subobjects to include or exclude d= omains
=C2=A0 =C2=A0during path setup where domain is a collection of network elem= ents
=C2=A0 =C2=A0within a common sphere of address management or path computati= onal
=C2=A0 =C2=A0responsibility (such as an Interior Gateway Protocol (IGP) are= a or an
=C2=A0 =C2=A0Autonomous System (AS)).=C2=A0 Note that the use of AS as an a= bstract node
=C2=A0 =C2=A0representing domain is already defined in existing RSVP-TE
=C2=A0 =C2=A0specefications, albeit with a 2-Byte AS number.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-= teas-rsvp-te-domain-subobjects/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-teas-rsv= p-te-domain-subobjects-01

A diff from the previous version is available at:
https:https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-teas-rsvp-te-domain-subobjects-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

_______________________________________________
Teas mailing list
Teas@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/teas

--001a1141d548990fb10514f0c5da--