Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 16:16:09 -0800 Message-ID: <2135200C183FD5119588009027DE572302836D73@webdev-owa.oni.com> From: "Ong, Lyndon" To: ccamp@ops.ietf.org Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 16:14:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Folks, I support the request to stick to constructive comments. Of course that means avoiding statements like "The ITU has stepped out of bounds (again). They deserve to be ignored." (Last I heard, SDH/OTN networks were within bounds of ITU ;o) Or "dogmatic statements of connection-oriented religion" (these are, for gmpls, connection-oriented networks we're talking about ;0) Seriously, though, I do have some comments on the draft: -- the figure shows the only path outside of the IETF process to be a dustbin. Hopefully that's not intentional, although a lot of folks on the list probably believe this ;o) -- there's some text mixed up in 2.2.1 regarding which mailing list should be used. -- we should incorporate Deborah's suggestion for 2.2.2 about having the decision posted to the mailing list within a specified period (the posting of a decision could apply to liaisons, and might have helped avoid the confusion with the ITU liaison) -- in 2.2.4, the paragraph after item (2) seems a little premature - the recommendation by the rewg presumably must be approved by IESG/IAB before a decision is made. -- there is a bit of a loophole in that the problem could be accepted and farmed off to a WG but there's no check to see if anything is ever done, and items could easily fall through a crack given the large numbers of work items usually in CCAMP and MPLS. There could be a procedure to revisit the decision in case no progress is being made within some specified timeframe. -- in general, I hope people keep in mind that the scope of interest and the resources available in IETF are limited, and should not become a bottleneck - if work can be or is already being done in other bodies and there is a process for IETF to review this work and identify potential problems or simpler/more general ways to do the desired function, this should be viewed as a generally positive thing. Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 12:57:40 -0800 Date: Fri, 28 Feb 2003 15:56:59 -0500 (EST) From: Scott Bradner Message-Id: <200302282056.h1SKuxaf029460@newdev.harvard.edu> To: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt yipe - go off-line for a long plane flight and kablooe the world explodes You may rest assured that the intention of the ID (and the one that came out today about change control for RSVP) is positive. The basic concept is the same as RFC 3427 does for SIP - be sure that the IETF is "in the loop" on extensions to IETF protocols. Note that these two IDs are 1st drafts and are meant to be discussed (that part seems to have worked :-) ) We have had recent experience with the OIF UNI and ITU ASON documents that it is easy to get into sort of a mess (and we are not accusing anyone specific here). There were many reasons. Including neglected liaison statements from ITU and documents from ITU folk. Clearly the IETF needs to figure out a better way to deal with such messages (This was a topic at the ITU-T TSAG (their sort of IESG) meeting this past week in geneva.) So in order to try to regularize the change process with RSVP and (G)MPLS the SUB-IP ADs with a few WG chairs prepared this document. The idea is that we define the process so that it is clear how and when various steps need to be taken and by whom. The doc is far from complete we suspect and so comments (certainly ones with recommended wording) will be very welcome. As noted above, these are first drafts and we expect that there will be quite a few changes before these get adopted. We also need to evaluate the issues w.r.t. to liaison statements. We think we have seen quite a set of opinions on the usefulness and function of liaison statements. These opinions need to be evaluated and revised text needs to be put in these documents to deal with them, but maybe this should be done as a comprehensive IETF review of how we deal with liaison statements. It would be good to tone down the "discussion" a bit. We do not think that making accusations etc helps the discussion. The idea was to try and prevent that from happening in the future. So now that you all have been able to blow of some steam, can you please start to post constructive text proposals as how to do things in these documents and relative to how the IETF deals with working with other SDOs that want to use and extend IETF protocols. (BTW - it is not a bad thing that multiple SDOs want to make use of the same protocols, it seems that it should be considered a good thing and we should work out ways that using existing protocols or working together on ways to extend current protocols is encouraged rather than making it more likely that competing protocols doing the same function get developed.) Thanks, Bert and Scott Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 12:20:52 -0800 Message-ID: <3E5FC411.FAF850FF@alcatel.be> Date: Fri, 28 Feb 2003 21:18:25 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) MIME-Version: 1.0 To: velev@panasonic.de Cc: Heiles Juergen , mpls@UU.NET, ccamp@ops.ietf.org Subject: Re: draft-kawakami-mpls-lsp-vlan-00.txt Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 aGksDQoNCnBlciBnbXBscywgTGF5ZXItMiBTd2l0Y2ggQ2FwYWJsZSAoTDJTQykgaW50ZXJmYWNl cyBhcmUNCmRlZmluZWQ6DQoNCiAgIEludGVyZmFjZXMgdGhhdCByZWNvZ25pemUgZnJhbWUvY2Vs bCBib3VuZGFyaWVzIGFuZCBjYW4gZm9yd2FyZCBkYXRhDQogICBiYXNlZCBvbiB0aGUgY29udGVu dCBvZiB0aGUgZnJhbWUvY2VsbCBoZWFkZXIuIEV4YW1wbGVzIGluY2x1ZGUNCiAgIGludGVyZmFj ZXMgb24gRXRoZXJuZXQgYnJpZGdlcyB0aGF0IGZvcndhcmQgZGF0YSBiYXNlZCBvbiB0aGUNCiAg IGNvbnRlbnQgb2YgdGhlIE1BQyBoZWFkZXIgYW5kIGludGVyZmFjZXMgb24gQVRNLUxTUnMgdGhh dCBmb3J3YXJkDQogICBkYXRhIGJhc2VkIG9uIHRoZSBBVE0gVlBJL1ZDSS4NCg0KaSBhZ3JlZSB3 aXRoIGp1ZXJnZW4sIHRoaXMgaS1kIHNob3VsZCBiZSBkaXNjdXNzZWQgYXQNCnRoZSBjY2FtcCB3 b3JraW5nIGdyb3VwDQoNCnRoYW5rcywNCi0gZGltaXRyaS4NCg0KR2VuYWRpIFZlbGV2IHdyb3Rl Og0KPiANCj4gSGkgSnVlcmdlbiwNCj4gDQo+IHRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrISBUaGlz IHdhcyAoYW5kIHNlZW1zIHRvIGJlIHN0aWxsKSBhIGhvdCB0b3BpYy4gVGhlDQo+IGRlY2lzaW9u IHdoZXJlIHRvIHByZXNlbnQgdGhlIGRyYWZ0IGhhcyBiZWVuIGFscmVhZHkgYSBzdWJqZWN0IG9m DQo+IGRpc2N1c3Npb25zIHdpdGggdGhlIGNoYWlybWVuIG9mIE1QTFMsIFBXRTMgYW5kIFBQVlBO IFdHcy4gVGhlIHJlYXNvbiB0byBsZXQNCj4gdGhpcyBkcmFmdCBmb3Igc3VibWlzc2lvbiBpbiB0 aGUgTVBMUyBXRyB3YXMgdGhhdCB0aGUgYmFzaWMgaW50ZW50aW9uIGlzIHRvDQo+IHByb3Bvc2Ug YSBuZXcgTERQIGV4dGVuc2lvbiAoIlZMQU4gbGFiZWwgVExWIikgYW5kIE1QTFMgV0cgaXMgaW4g Y2hhcmdlIG9mDQo+IHRoZSBMRFAgcHJvdG9jb2wuDQo+IA0KPiBJdCdzIHRydWUgdGhhdCB0aGUg dHJhbnNwb3J0IHBsYW5lIGluIG91ciBwcm9wb3NhbCBpcyBiYXNlZCBvbiBWTEFOLWF3YXJlDQo+ IEV0aGVybmV0IHN3aXRjaGVzLiBDb21wYXJlZCB0byB0aGUgR01QTFMgY2xhc3NpZmljYXRpb24g b2YgaW50ZXJmYWNlcw0KPiAoUkZDMzQ3MSksIFZMQU4gdGFnIHN3aXRjaGluZyBiZWxvbmdzIChJ J2Qgc2F5IHNvKSB0byB0aGUgUGFja2V0LVN3aXRjaA0KPiBDYXBhYmxlIChQU0MpIGludGVyZmFj ZXMsIGFuZCB0aHVzLCBleHRlbnNpb25zIHJlZ2FyZGluZyB0aGVzZSBpbnRlcmZhY2VzDQo+IHNo b3VsZCBiZSBhIHN1YmplY3Qgb2YgdGhlIE1QTFMgV0cuDQo+IA0KPiBUaGlzIGlzIG15IHBlcnNv bmFsIG9waW5pb24uIEhvd2V2ZXIsIHNpbmNlIEknbSBub3QgYSBsb25nLWV4cGVyaWVuY2VkDQo+ IHBlcnNvbiBpbiB0aGUgSUVURidzIE1QTFMgcmVsYXRlZCB3b3JrLCBJJ2QgbGlrZSB0byBoZWFy IGFsc28gYW5vdGhlcg0KPiBvcGluaW9ucyBvbiB0aGlzIGlzc3VlLg0KPiANCj4gcmVnYXJkcywN Cj4gR2VuYWRpDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog b3duZXItbXBsc0BVVS5ORVQgW21haWx0bzpvd25lci1tcGxzQFVVLk5FVF1PbiBCZWhhbGYgT2Yg SGVpbGVzDQo+ID4gSnVlcmdlbg0KPiA+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjgsIDIwMDMg MTI6MTcgUE0NCj4gPiBUbzogJ3ZlbGV2QHBhbmFzb25pYy5kZSc7IG1wbHNAVVUuTkVUOyBjY2Ft cEBvcHMuaWV0Zi5vcmcNCj4gPiBDYzogdmxhbi1tcGxzQHBhbmFzb25pYy5kZQ0KPiA+IFN1Ympl Y3Q6IEFXOiBkcmFmdC1rYXdha2FtaS1tcGxzLWxzcC12bGFuLTAwLnR4dA0KPiA+DQo+ID4NCj4g PiBHZW5hZGksDQo+ID4NCj4gPiB0aGUgZHJhZnQgcHJvcG9zZXMgdG8gdXNlIHRoZSBNUExTIGNv bnRyb2wgcGxhbmUgcHJvdG9jb2xzIGZvciBhDQo+ID4gZGlmZmVyZW50IHRyYW5zcG9ydCBwbGFu ZSAoRXRoZXJuZXQgVkxBTikuDQo+ID4gVGhpcyBpcyBleGNhdGx5IHdoYXQgR01QTFMgaXMgYWJv dXQuIFNvIEkgdGhpbmsgaXQgd291bGQgYmUNCj4gPiBiZXR0ZXIgdG8gaGF2ZSB0aGUgSUQgYW5k IGRpY3Vzc2lvbiBpbiBjY2FtcCB1bmRlciB0aGUgR01QTFMgd29yay4NCj4gPg0KPiA+IFJlZ2Fy ZHMNCj4gPg0KPiA+IEp1ZXJnZW4NCj4gPg0KPiA+DQo+ID4gPiAtLS0tLVVyc3By/G5nbGljaGUg TmFjaHJpY2h0LS0tLS0NCj4gPiA+IFZvbjogR2VuYWRpIFZlbGV2IFttYWlsdG86dmVsZXZAcGFu YXNvbmljLmRlXQ0KPiA+ID4gR2VzZW5kZXQ6IERvbm5lcnN0YWcsIDI3LiBGZWJydWFyIDIwMDMg MTc6NTMNCj4gPiA+IEFuOiBtcGxzQFVVLk5FVA0KPiA+ID4gQ2M6IHZsYW4tbXBsc0BwYW5hc29u aWMuZGUNCj4gPiA+IEJldHJlZmY6IGRyYWZ0LWthd2FrYW1pLW1wbHMtbHNwLXZsYW4tMDAudHh0 DQo+ID4gPg0KPiA+ID4NCj4gPiA+IFsgTWFpbCB3YXMgZGVsaXZlcmVkIHRocm91Z2ggVlBOIFBF TC0+TUVJL0FWQ0RDISBdDQo+ID4gPiBbIE1haWwgd2FzIGRlbGl2ZXJlZCB0aHJvdWdoIFZQTiBQ RUwtPk1FSS9BVkNEQyEgXQ0KPiA+ID4gWyBNYWlsIHdhcyBkZWxpdmVyZWQgdGhyb3VnaCBWUE4g UEVMLT5NRUkvQVZDREMhIF0NCj4gPiA+IFsgTWFpbCB3YXMgZGVsaXZlcmVkIHRocm91Z2ggVlBO IFBFTC0+TUVJL0FWQ0RDISBdDQo+ID4gPg0KPiA+ID4gSGkgYWxsLA0KPiA+ID4NCj4gPiA+IEEg bmV3IGRyYWZ0IHdhcyBwdWJsaXNoZWQgdG9kYXkgKHBsZWFzZSBzZWUgYmVsb3cpLg0KPiA+ID4N Cj4gPiA+IEFueSBmZWVkYmFjayBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUsIGVzcGVjaWFsbHkg ZnJvbSB0aG9zZQ0KPiA+ID4gb2YgeW91IHdobyBhcmUNCj4gPiA+IGRlYWxpbmcgd2l0aCBwYWNr ZXQgdHJhbnNwb3J0IG92ZXIgd2lkZSBhcmVhIEV0aGVybmV0IG5ldHdvcmtzLg0KPiA+ID4NCj4g PiA+IHRoYW5rcywNCj4gPiA+IEdlbmFkaQ0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+ID4gRnJvbTogb3duZXItbXBsc0BVVS5ORVQgW21haWx0bzpvd25l ci1tcGxzQFVVLk5FVF1PbiBCZWhhbGYgT2YNCj4gPiA+ID4gSW50ZXJuZXQtRHJhZnRzQGlldGYu b3JnDQo+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNywgMjAwMyAxOjQ0IFBNDQo+ ID4gPiA+IFRvOiBJRVRGLUFubm91bmNlOg0KPiA+ID4gPiBDYzogbXBsc0BVVS5ORVQNCj4gPiA+ ID4gU3ViamVjdDogSS1EIEFDVElPTjpkcmFmdC1rYXdha2FtaS1tcGxzLWxzcC12bGFuLTAwLnR4 dA0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZQ0KPiA+ID4gPiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3Jp ZXMuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ICAgVGl0bGUgICAgICAgICAgIDogTWV0aG9k IHRvIFNldHVwIExTUCB1c2luZyBWTEFOIFRhZyBTd2l0Y2hpbmcNCj4gPiA+ID4gICBBdXRob3Io cykgICAgICAgOiBULiBLYXdha2FtaSBldCBhbC4NCj4gPiA+ID4gICBGaWxlbmFtZSAgICAgICAg OiBkcmFmdC1rYXdha2FtaS1tcGxzLWxzcC12bGFuLTAwLnR4dA0KPiA+ID4gPiAgIFBhZ2VzICAg ICAgICAgICA6IDE1DQo+ID4gPiA+ICAgRGF0ZSAgICAgICAgICAgIDogMjAwMy0yLTI2DQo+ID4g PiA+DQo+ID4gPiA+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvIHNldHVwIGEg TGF5ZXIgMiB0dW5uZWwgb3Zlcg0KPiA+ID4gPiBuZXR3b3JrcyBiYXNlZCBvbiBFdGhlcm5ldCB0 ZWNobm9sb2d5LiBGb3IgdGhpcyBwdXJwb3NlLA0KPiA+ID4gdGhlIHBvcnRzIG9mDQo+ID4gPiA+ IGFuIEV0aGVybmV0IHN3aXRjaCBhcmUgY29uZmlndXJlZCB0byBmb3J3YXJkIFZMQU4NCj4gPiA+ IHRhZy1sYWJlbGVkIHBhY2tldHMNCj4gPiA+ID4gaW5jb21pbmcgZnJvbSBhIGNlcnRhaW4gcG9y dCB0byBhbm90aGVyIHVuYW1iaWd1b3VzIHBvcnQgYnkgdXNpbmcNCj4gPiA+ID4gVkxBTiB0YWcg aW5mb3JtYXRpb24uIFRoZSBFdGhlcm5ldCBzd2l0Y2hlcyB0aGVtc2VsdmVzIGFyZSBhIHBhcnQg b2YNCj4gPiA+ID4gdGhlIExhYmVsIFN3aXRjaGluZyBSb3V0ZXJzIChMU1JzKSwgd2hpY2ggZGlz dHJpYnV0ZSB0aGUgVkxBTiB0YWdzDQo+ID4gPiA+IHVzaW5nIExhYmVsIERpc3RyaWJ1dGlvbiBQ cm90b2NvbCAoTERQKS4gVG8gZW5hYmxlIExEUCB0bw0KPiA+ID4gZnVsZmlsIHRoaXMNCj4gPiA+ ID4gZnVuY3Rpb24sIGFuIExEUCBleHRlbnNpb24gaXMgcHJvcG9zZWQuIFRoZSBpbnRyb2R1Y2Vk IG1ldGhvZA0KPiA+ID4gPiBzaW1wbGlmaWVzIHRoZSB0cmFuc3BvcnQgb2YgRXRoZXJuZXQgZnJh bWVzIG92ZXIgd2lkZSBhcmVhIEV0aGVybmV0DQo+ID4gPiA+IG5ldHdvcmtzLg0KPiA+ID4gPg0K PiA+ID4gPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gPiA+ID4NCj4gPiBo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rYXdha2FtaS1tcGxzLWxz cC12bGFuLTAwLnR4dA0KPiA+ID4NCj4gPiA+IFRvIHJlbW92ZSB5b3Vyc2VsZiBmcm9tIHRoZSBJ RVRGIEFubm91bmNlbWVudCBsaXN0LCBzZW5kIGEgbWVzc2FnZSB0bw0KPiA+ID4gaWV0Zi1hbm5v dW5jZS1yZXF1ZXN0IHdpdGggdGhlIHdvcmQgdW5zdWJzY3JpYmUgaW4gdGhlIGJvZHkgb2YNCj4g PiA+IHRoZSBtZXNzYWdlLg0KPiA+ID4NCj4gPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUC4gTG9naW4gd2l0aA0KPiA+ID4gdGhlIHVzZXJuYW1l DQo+ID4gPiAiYW5vbnltb3VzIiBhbmQgYSBwYXNzd29yZCBvZiB5b3VyIGUtbWFpbCBhZGRyZXNz LiBBZnRlciBsb2dnaW5nIGluLA0KPiA+ID4gdHlwZSAiY2QgaW50ZXJuZXQtZHJhZnRzIiBhbmQg dGhlbg0KPiA+ID4gICAgICJnZXQgZHJhZnQta2F3YWthbWktbXBscy1sc3Atdmxhbi0wMC50eHQi Lg0KPiA+ID4NCj4gPiA+IEEgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMgY2Fu IGJlIGZvdW5kIGluDQo+ID4gPiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQo+ID4g PiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPiA+ID4NCj4g PiA+DQo+ID4gPiBJbnRlcm5ldC1EcmFmdHMgY2FuIGFsc28gYmUgb2J0YWluZWQgYnkgZS1tYWls Lg0KPiA+ID4NCj4gPiA+IFNlbmQgYSBtZXNzYWdlIHRvOg0KPiA+ID4gICAgIG1haWxzZXJ2QGll dGYub3JnLg0KPiA+ID4gSW4gdGhlIGJvZHkgdHlwZToNCj4gPiA+ICAgICAiRklMRSAvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWthd2FrYW1pLW1wbHMtbHNwLXZsYW4tMDAudHh0Ii4NCj4gPiA+DQo+ ID4gPiBOT1RFOiAgICAgICBUaGUgbWFpbCBzZXJ2ZXIgYXQgaWV0Zi5vcmcgY2FuIHJldHVybiB0 aGUgZG9jdW1lbnQgaW4NCj4gPiA+ICAgICBNSU1FLWVuY29kZWQgZm9ybSBieSB1c2luZyB0aGUg Im1wYWNrIiB1dGlsaXR5LiAgVG8gdXNlIHRoaXMNCj4gPiA+ICAgICBmZWF0dXJlLCBpbnNlcnQg dGhlIGNvbW1hbmQgIkVOQ09ESU5HIG1pbWUiIGJlZm9yZSB0aGUgIkZJTEUiDQo+ID4gPiAgICAg Y29tbWFuZC4gIFRvIGRlY29kZSB0aGUgcmVzcG9uc2UocyksIHlvdSB3aWxsIG5lZWQgIm11bnBh Y2siIG9yDQo+ID4gPiAgICAgYSBNSU1FLWNvbXBsaWFudCBtYWlsIHJlYWRlci4gIERpZmZlcmVu dCBNSU1FLWNvbXBsaWFudCBtYWlsIHJlYWRlcnMNCj4gPiA+ICAgICBleGhpYml0IGRpZmZlcmVu dCBiZWhhdmlvciwgZXNwZWNpYWxseSB3aGVuIGRlYWxpbmcgd2l0aA0KPiA+ID4gICAgICJtdWx0 aXBhcnQiIE1JTUUgbWVzc2FnZXMgKGkuZS4gZG9jdW1lbnRzIHdoaWNoIGhhdmUgYmVlbiBzcGxp dA0KPiA+ID4gICAgIHVwIGludG8gbXVsdGlwbGUgbWVzc2FnZXMpLCBzbyBjaGVjayB5b3VyIGxv Y2FsIGRvY3VtZW50YXRpb24gb24NCj4gPiA+ICAgICBob3cgdG8gbWFuaXB1bGF0ZSB0aGVzZSBt ZXNzYWdlcy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2ls bCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KPiA+ID4gaW1wbGVtZW50YXRp b24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUNCj4g PiA+IEludGVybmV0LURyYWZ0Lg0KPiA+ID4NCg0KLS0gDQpQYXBhZGltaXRyaW91IERpbWl0cmkg DQpFLW1haWwgOiBkaW1pdHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZSANClByaXZhdGU6IGh0 dHA6Ly93d3cucmMuYmVsLmFsY2F0ZWwuYmUvfnBhcGFkaW1kL2luZGV4Lmh0bWwNCkUtbWFpbCA6 IGRwYXBhZGltaXRyaW91QHBzZy5jb20NClB1YmxpYyA6IGh0dHA6Ly9wc2cuY29tL35kcGFwYWRp bWl0cmlvdS8NCkFkZHJlc3M6IEZyLiBXZWxsZXNwbGVpbiAxLCBCLTIwMTggQW50d2VycGVuLCBC ZWxnaXVtDQpQaG9uZSAgOiArMzIgMyAyNDAtODQ5MQ0K Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 10:21:06 -0800 Message-Id: <200302281816.NAA07948@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-sonet-sdh-08.txt Date: Fri, 28 Feb 2003 13:16:36 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control Author(s) : E. Mannie, D. Papadimitriou Filename : draft-ietf-ccamp-gmpls-sonet-sdh-08.txt Pages : 21 Date : 2003-2-28 This document is a companion to the Generalized Multiprotocol Label Switching (GMPLS) signaling. It defines the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology specific information needed when using GMPLS signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-sonet-sdh-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-28133607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-sonet-sdh-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-28133607.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 10:08:17 -0800 Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Date: Fri, 28 Feb 2003 14:25:04 +0100 From: Genadi Velev Subject: RE: draft-kawakami-mpls-lsp-vlan-00.txt To: Heiles Juergen Cc: mpls@UU.NET, ccamp@ops.ietf.org [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi Juergen, thanks for the feedback! This was (and seems to be still) a hot topic. The decision where to present the draft has been already a subject of discussions with the chairmen of MPLS, PWE3 and PPVPN WGs. The reason to let this draft for submission in the MPLS WG was that the basic intention is to propose a new LDP extension ("VLAN label TLV") and MPLS WG is in charge of the LDP protocol. It's true that the transport plane in our proposal is based on VLAN-aware Ethernet switches. Compared to the GMPLS classification of interfaces (RFC3471), VLAN tag switching belongs (I'd say so) to the Packet-Switch Capable (PSC) interfaces, and thus, extensions regarding these interfaces should be a subject of the MPLS WG. This is my personal opinion. However, since I'm not a long-experienced person in the IETF's MPLS related work, I'd like to hear also another opinions on this issue. regards, Genadi > -----Original Message----- > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Heiles > Juergen > Sent: Friday, February 28, 2003 12:17 PM > To: 'velev@panasonic.de'; mpls@UU.NET; ccamp@ops.ietf.org > Cc: vlan-mpls@panasonic.de > Subject: AW: draft-kawakami-mpls-lsp-vlan-00.txt > > > Genadi, > > the draft proposes to use the MPLS control plane protocols for a > different transport plane (Ethernet VLAN). > This is excatly what GMPLS is about. So I think it would be > better to have the ID and dicussion in ccamp under the GMPLS work. > > Regards > > Juergen > > > > -----Ursprüngliche Nachricht----- > > Von: Genadi Velev [mailto:velev@panasonic.de] > > Gesendet: Donnerstag, 27. Februar 2003 17:53 > > An: mpls@UU.NET > > Cc: vlan-mpls@panasonic.de > > Betreff: draft-kawakami-mpls-lsp-vlan-00.txt > > > > > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > > > > Hi all, > > > > A new draft was published today (please see below). > > > > Any feedback and comments are welcome, especially from those > > of you who are > > dealing with packet transport over wide area Ethernet networks. > > > > thanks, > > Genadi > > > > > -----Original Message----- > > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > > Internet-Drafts@ietf.org > > > Sent: Thursday, February 27, 2003 1:44 PM > > > To: IETF-Announce: > > > Cc: mpls@UU.NET > > > Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line > > > Internet-Drafts directories. > > > > > > > > > Title : Method to Setup LSP using VLAN Tag Switching > > > Author(s) : T. Kawakami et al. > > > Filename : draft-kawakami-mpls-lsp-vlan-00.txt > > > Pages : 15 > > > Date : 2003-2-26 > > > > > > This document describes a method to setup a Layer 2 tunnel over > > > networks based on Ethernet technology. For this purpose, > > the ports of > > > an Ethernet switch are configured to forward VLAN > > tag-labeled packets > > > incoming from a certain port to another unambiguous port by using > > > VLAN tag information. The Ethernet switches themselves are a part of > > > the Label Switching Routers (LSRs), which distribute the VLAN tags > > > using Label Distribution Protocol (LDP). To enable LDP to > > fulfil this > > > function, an LDP extension is proposed. The introduced method > > > simplifies the transport of Ethernet frames over wide area Ethernet > > > networks. > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of > > the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with > > the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-kawakami-mpls-lsp-vlan-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 09:58:22 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D3028897C1@mail3.tellium.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" From: Bala Rajagopalan To: Loa Andersson Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 22:57:56 -0500 Just ran into this ID. The flow chart, as usual, was too complicated for me to comprehend, to I ran it through the decoder software that IESG provides to unscramble its policy statements (see http://www.ietf.org/iesg/policy_faq/demystify.exe). The flow chart was then rendered human-readable as follows: MPLS and GMPLS Change Process ----------------------------- +-------------------------+ | Receive New ID | +-------------------------+ | | V +-------------------------------------+ | Briefly wonder about the resilience | | of the MPLS/GMPLS bandwagon. | | Start review. | +-------------------------------------+ | | V +-----------------------------------+ | Does the draft contain the term | Yes | "ASON"? |-------> TRASH +-----------------------------------+ | | No V +----------------------------------+ | Does the draft contain the term | Yes | "UNI"? |--------> Incinerate +----------------------------------+ | | No V +-------------------------------+ Yes, I-NNI | How about "NNI?" |-----+----> TRASH +-------------------------------+ | | | E-NNI | No +-----> Shred V +-------------------------------+ | Does the draft mention Call | Yes | vs Connection control? |-------> Send a sample +-------------------------------+ of draft to CDC, | incinerate rest | No V +-------------------------------+ | Does the draft have the term | Yes | "G.xyz." in the title? |---------> TRASH +-------------------------------+ | | No V +-------------------------------+ | Draft has progressed too far. | | Send to Curtis for review. | +-------------------------------+ | | V | | | TRASH | +------------+ Seems a bit draconian and no wonder, people are anxious about the process and expect the worst. Still, I believe this will help in limiting the generation of useless drafts and protocol extensions to WGs within the IETF and prevent outside groups from doing the same. Regards, Bala Rajagopalan Tellium, Inc. 2 Crescent Pl. Ocean Port, NJ 07757 USA Ph: +1-732-923-4237 Email: braja@tellium.com Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 09:47:44 -0800 Date: Fri, 28 Feb 2003 12:46:51 -0500 From: Scott W Brim To: ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-04.txt Message-ID: <20030228174651.GK2224@sbrim-w2k> Mail-Followup-To: Scott W Brim , ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i On Fri, Feb 28, 2003 12:40:10PM -0500, Thomas D. Nadeau allegedly wrote: > > The weblink below does not work. I only see version -03. The web site is currently behind the flow of announcements. Give it a minute. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 09:40:43 -0800 Message-Id: <5.2.0.9.2.20030228123951.087cf808@bucket.cisco.com> Date: Fri, 28 Feb 2003 12:40:10 -0500 To: Internet-Drafts@ietf.org, IETF-Announce:; From: "Thomas D. Nadeau" Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-04.txt Cc: ccamp@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed The weblink below does not work. I only see version -03. --Tom >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Common Control and Measurement Plane >Working Group of the IETF. > > Title : Generalized Multi-Protocol Label Switching > (GMPLS) Architecture > Author(s) : E. Mannie > Filename : draft-ietf-ccamp-gmpls-architecture-04.txt > Pages : 57 > Date : 2003-2-28 > >Future data and transmission networks will consist of elements such >as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), >photonic cross-connects (PXCs), optical cross-connects (OXCs), etc >that will use Generalized MPLS (GMPLS) to dynamically provision >resources and to provide network survivability using protection and >restoration techniques.This document describes the architecture of GMPLS. >GMPLS extends >MPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709), >wavelength (lambdas), and spatial switching (e.g. incoming port or >fiber to outgoing port or fiber). The main focus of GMPLS is on the >control plane of these various layers since each of them can use >physically diverse data or forwarding planes. The intention is to >cover both the signaling and the routing part of that control plane. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ccamp-gmpls-architecture-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-2-28124132.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 09:35:47 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 12:35:25 -0500 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA61B@OCCLUST02EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLfTdwup82ty5vxR8i+lN2NZtwLmgAAc7Zg From: "Brungard, Deborah A, ALABS" To: "Stephen Trowbridge" , Cc: "Loa Andersson" , , Was the concern by saying "external standards bodies", it was = interpreted as liaisons (as this is the only formal way for T1/ITU to = communicate), which implies submission of an "individual draft", review, = etc.? So as not to confuse "standards bodies" with liaison = communication, how about in the draft changing this to "participants of = external standards bodies"? Or perhaps best is to just remove. And let = the liaison process address, with links to this document. Deborah -----Original Message----- From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] Sent: Friday, February 28, 2003 12:16 PM To: curtis@fictitious.org Cc: Loa Andersson; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Curtis, I have no problem to seperate the liaison process from the internal = process. In fact, a good liaison process is needed that would have much broader applicability than (G)MPLS protocols. However, I do disagree that we can go forward on one with out the other. As Bala's flowchart shows, the effect of applying this draft to = internally and externally initated work alike is to give the externally initiated work a fast track to the trash. Without the liaison process, this draft seems to make what is already a bad problem with how we deal with input from other SDOs even worse. Regards, Steve Curtis Villamizar wrote: >=20 > In message <3E5F8A25.8030201@pi.se>, Loa Andersson writes: > > > > - I don't think it is agood idea to describe the two process in the = same > > document. the chnage-process is for our internal use, the liasion = process > > is for our commuinication with other SDOs >=20 > If we can agree on this, then we can move forward with your document. >=20 > Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 09:26:31 -0800 Message-Id: <200302281721.MAA05452@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-architecture-04.txt Date: Fri, 28 Feb 2003 12:21:50 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Architecture Author(s) : E. Mannie Filename : draft-ietf-ccamp-gmpls-architecture-04.txt Pages : 57 Date : 2003-2-28 Future data and transmission networks will consist of elements such as routers, switches, DWDM systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc that will use Generalized MPLS (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g. SDH/SONET, PDH, G.709), wavelength (lambdas), and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). The main focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-architecture-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-28124132.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-architecture-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-architecture-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-28124132.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 09:04:44 -0800 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA838A@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Loa Andersson'" , mpls@UU.NET, "'ccamp@ops.ietf.org'" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 12:03:25 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi, Very helpful email. I concur with points 1-6. Re points (a) and (b), perhaps the best approach would be to first generate the material itself. Discussion of its subsequent subdivision would be far easier, if there were actual content to work with. Eve -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Friday, February 28, 2003 11:11 AM To: mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt All, I might be stupid, but I actually see some commonality forming on this thread, though there is much smoke I think we agree on the following: 1. and most important - we want a productive, trustful and comprehensive co-operatiom between IETF and other SDOs 2. the process that describes how this co-operation is handled needs to be described 3. we need to have a known, reliable and open (g)mpls technology area process for how extend and change the (g)mpls protocols 4. this process also needs to be descirbed 5. that the (g)mpls working groups in the IETF (or maybe the IETF in general) [sometimes, often, regulary, a few times] have mismanaged incoming liasions from other SDOs Note 1: I know that some voices has been raised saying that "the general process for c-operation between IETF and other SDOs" are not a subject matter for for the mpls-list. I tend to agree, however one of our ADs made it appropriate as long as we discuss the coupling between the to processes above. We disagree on: a. whether the two processes needs to go into the same document or not b. whether documents generated in one process could go seemlessly into the other process I hope we agree on this: 6. that the relationship between IETF and other SDOs are by nature a relationship between equal parties 7. that each organization are entitled to define it own processes, methodology and document types Some personal reflections - Kireeti and Bert has recognized that here has been less than satifactory performanse by the IETF in handling liasions in the past, we will not be any wiser if that aregument is repeated - I don't think it is agood idea to describe the two process in the same document. the chnage-process is for our internal use, the liasion process is for our commuinication with other SDOs (I understand that from the other side this might look pretty much the same, but if the only problem is that of how some type of info sent from one organisation is received by another, let us solve that problem) It must be fairly easy for the sending organization say to the IETF "Please, handle the content of this liasion as an Internet Draft!" Based on that we can publish is as an ID, and include it in our work. But if there is written in stone that a liasion is a liasion is a liasion, then we will require that other SDOs send us IDs. - in our internal processes we need documents ofer which we have change control and therefore it is unsatifactory to use non-IETF documents Would be good if we could agree on points 1-6 and on a and b, would be far easier to continue the disucssion. /Loa Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 08:51:11 -0800 Message-ID: <05707214338CD5119BFF0040A5B170D3028897C7@mail3.tellium.com> From: Bala Rajagopalan To: "'curtis@fictitious.org'" Cc: Loa Andersson , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 11:46:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Curtis: First, thanks for your patient response. Needless to say, a bit of exaggeration is necessary for humor (I hope there was some humor in this). I wasn't really following the thread on G.709, so this was not the issue. There are a number of G.xxxx documents related to ASON that use IETF protocols and this is what I was referring to. Now, I don't think that all solutions developed outside of IETF (using IETF protocols) are clean. However, I do think that so far, there has not been an adequate effort in IETF to understand the problem formulations coming from outside. This is the crux of my message. In this regard, yes, I do believe that you have been prominent in rejecting the entire notion of the UNI. I personally don't have an addiction to UNI (or any of the G.xxxx stuff), except that some number of service providers (the potential customers of the technology) wanted this and an effort was made to deliver the features they wanted. Is there a better way of providing the same UNI functionality using GMPLS protocols? This is what one would like to hear from IETF, rather than a dismissal of the whole concept. Correct me if I'm wrong, but the present Andersson draft, IMO, doesn't address this problem. Clearly, I won't place any bets on the success of UNI in the market place (what market?). Neither will I place any bets on GMPLS at this point in time. Thank you. Bala Bala Rajagopalan Tellium, Inc. 2 Crescent Pl. Ocean Port, NJ 07757 USA Ph: +1-732-923-4237 Email: braja@tellium.com > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@fictitious.org] > Sent: Friday, February 28, 2003 11:07 AM > To: Bala Rajagopalan > Cc: Loa Andersson; ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > In message > <05707214338CD5119BFF0040A5B170D3028897C1@mail3.tellium.com>, Bala R > ajagopalan writes: > > Just ran into this ID. The flow chart, as usual, > > was too complicated for me to comprehend, to I > > ran it through the decoder software that IESG > > provides to unscramble its policy statements > > (see http://www.ietf.org/iesg/policy_faq/demystify.exe). > > The flow chart was then rendered human-readable > > as follows: > > > AFAIK - When IESG members run the compiler they don't produce exe > files. :-) > > > > MPLS and GMPLS Change Process > > ----------------------------- > > > > +-------------------------+ > > | Receive New ID | > > +-------------------------+ > > | > > | > > V > > +-------------------------------------+ > > | Briefly wonder about the resilience | > > | of the MPLS/GMPLS bandwagon. | > > > | Start review. | > > +-------------------------------------+ > > | > > | > > V > > +-----------------------------------+ > > | Does the draft contain the term | Yes > > | "ASON"? |-------> TRASH > > +-----------------------------------+ > > | > > | No > > V > > +----------------------------------+ > > | Does the draft contain the term | Yes > > | "UNI"? |--------> Incinerate > > +----------------------------------+ > > | > > | No > > V > > +-------------------------------+ Yes, I-NNI > > | How about "NNI?" |-----+----> TRASH > > +-------------------------------+ | > > | | E-NNI > > | No +-----> Shred > > V > > > Not bad. I think you're OK up to here. > > > > +-------------------------------+ > > | Does the draft mention Call | Yes > > | vs Connection control? |-------> Send a sample > > +-------------------------------+ of draft to CDC, > > | incinerate rest > > | No > > V > > > I think that either "call control" or "connection control" warents a > trip to the dumpster. > > > > +-------------------------------+ > > | Does the draft have the term | Yes > > | "G.xyz." in the title? |---------> TRASH > > +-------------------------------+ > > | > > | No > > V > > > Not true. Examples: > > 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. > H.263 Video > (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, > C. Maciocco, > D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. > October 1998. > (Format: TXT=43166 bytes) (Status: PROPOSED STANDARD) > > 3047 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi. > January 2001. (Format: TXT=16292 bytes) (Status: > PROPOSED STANDARD) > > 3095 RObust Header Compression (ROHC): Framework and four profiles: > RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M. > Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. > Hakenberg, T. > Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. > Svanbro, T. > Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: > TXT=368746 bytes) > (Status: PROPOSED STANDARD) > > 3267 Real-Time Transport Protocol (RTP) Payload Format and File > Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive > Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, > M. Westerlund, > A. Lakaniemi, Q. Xie. June 2002. (Format: TXT=110652 > bytes) (Status: > PROPOSED STANDARD) > > 3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise > (CN). R. Zopf. September 2002. (Format: TXT=17018 > bytes) (Status: > PROPOSED STANDARD) > > These have plenty of G. and H. numbers in them and none of them are > informational. All of them make sense (for example: no severe scaling > issues). > > > +-------------------------------+ > > | Draft has progressed too far. | > > | Send to Curtis for review. | > > +-------------------------------+ > > | > > | > > V > > | | > > | TRASH | > > +------------+ > > > I didn't realize I played such an important role in this process. All > this time I thought I was just making technical comments. > > Sounds like you're still upset that I didn't like the OIF-UNI and/or > you don't like technical comments regarding the feasibility of > proposed encapsulation of G.709. A primary point regarding OIF-UNI is > that ATM-UNI service (ie: SVCs) never took off therefore the last > thing we needed was a UNI for optical. In other words, there is no > credible requirement. > > We'll have to see how the market acceptance of OIF-UNI goes. So far > it looks about as alive as CR-LDP did for a few years. The market > certainly put an end to LANE, NHRP, MPOA, and the whole idea of > modeling ATM as a LIS. Check the IPATM and ION archives if you'd like > to read my comments on those standards which were strongly supported > by SDOs outside the IETF. > > I'm sorry that you don't like technical comments made about the G.709 > compressions. Apparently some people think the IETF should just > rubber stamp everything because it came from the ITU even if there are > scalability issues which make deployment infeasible. > > > > Seems a bit draconian and no wonder, people are anxious > > about the process and expect the worst. Still, I believe > > this will help in limiting the generation of useless drafts > > and protocol extensions to > > WGs within the IETF and prevent outside groups from doing the same. > > > > Regards, > > > > Bala Rajagopalan > > > The IETF can't stop other SDOs from creating useless protocols and > protocol extensions and some have become quite good at it. :-) > > Curtis > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 08:43:37 -0800 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550106324E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Kireeti Kompella (E-mail)" , yakov@juniper.net Cc: "Ccamp-wg (E-mail)" Subject: FW: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Date: Fri, 28 Feb 2003 17:42:45 +0100 MIME-Version: 1.0 Content-Type: text/plain Could the authors please answer to this IETF Last Call Comment? Thanks, Bert -----Original Message----- From: Jonathan Sadler [mailto:jonathan.sadler@tellabs.com] Sent: maandag 24 februari 2003 5:55 To: iesg@ietf.org; ietf@ietf.org; ccamp@ops.ietf.org Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Please consider the following comments on these drafts: draft-ietf-ccamp-gmpls-routing-05.txt draft-ietf-ccamp-ospf-gmpls-extensions-09.txt Many of the comments are based on implementation experience. These comments are marked with a (*). Jonathan Sadler ========== 1. In section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt, the operations for Packet Switch Capable (PSC) are defined. Reference is made to Minimum LSP bandwidth for SDH encoding. None of the examples in section 5 of draft-ietf-ccamp-gmpls-routing-05.txt show how this field should filled. 2. The mechanism for showing relationships between server and client layers is not generalized*. Specifically: - Relationships between SONET/SDH layers (ISC type: TDM) are implicitly stated based on the Min and Max LSP bandwidth advertised*. To quote draft-ietf-ccamp-gmpls-routing-05.txt: "On an interface having Standard SDH multiplexing, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p." This requires node doing the route calculation to understand the G.707 multiplexing hierarchy. Since LSP routing is source routed, it could be the node doing the route calculation doesn't understand G.707. Furthermore, the G.707 multiplexing hierarchy is not a simple tree. For example VC-11 and VC-12 can be supported over VC-3 as well as over VC-4. Consequently, the definition provided does not allow a system to explicitly state which "branch" of the G.707 hierarchy should be followed. - Relationships between PSC-n (for IP switching) and SONET/SDH are explicitly specified on the encoding type specified in the PSC-n announcement*. However, SONET/SDH is not a single layer. It must be possible to identify if the PSC-n layer can be carried by a VC-11 trail, a VC-12 trail, a VC-3 trail, a VC-4 trail, or a VC-4-nc trail. Section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt tries to deal with this in the following paragraph: "On a PSC interface that supports Standard SDH encoding, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p." The problem is this contradicts the following paragraph: "The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum Bandwidth is a single fixed value (usually simply the link capacity), Maximum LSP Bandwidth is carried per priority, and may vary as LSPs are set up and torn down." Specifically, how does a completely available OC-48 interface with VC-11 over VC-3, VC-3, and VC-4 get encoded? Based on the first paragraph, the encoding would be MinLSPBW=1.5M, and MaxLSPBW[p]=155M. Ignoring the issue that VC-11 over VC-4 ends up being shown as supported, the second paragraph states that the MaxLSPBW[p] should be 2.5G. Knowing the OC-48 is completely available is useful information, as multiple VC-4s could be used in an LCAS group to support connections that need data rates over 155M*. - The mechanism does not support describing common muli-layer relationships such as IP over DS1 over VC-11 or IP over DS3 over VC-3*. - Sometimes layer relationships are described in an "inverted" manner*. Section 5.1 of draft-ietf-ccamp-gmpls-routing-05.txt states: "STM-16 POS Interface on a LSR Interface Switching Capability Descriptor: Interface Switching Capability = PSC-1 Encoding = SDH Max LSP Bandwidth[p] = 2.5 Gbps, for all p" Where PSC-1 is the client of an SDH (sic) server. Section 5.5 states: "Interface of an opaque OXC (SDH framed) with support for one lambda per port/interface" " Interface Switching Capability Descriptor: Interface Switching Capability = LSC Encoding = SDH" In this case, SDH is a client of a wavelength server (LSC). However, unlike in section 5.1, the layer relationship is inverted. 3. Layer specific attributes are not supported*. Specifically: - It is not possible to have a link with different costs at different layers (ex. VC-11, VC-4, VC4-4c). The link cost is a tool used by network designers to bias traffic toward or away from specific links. Since different hardware platforms are optimized for different layers, the network designer may wish to bias traffic in a layer to use or avoid a platform that inefficiently supports a particular layer. The announcement of a link in the layer may still be desirable to allow for diverse routing. - Many attributes discussed actually refer to a specific layer*. For example SRLG can be an MS-layer attribute that is inherited by all supported layers (VC-11, VC-12, VC-3, VC-4, VC-4-nc). Likewise Protection mechanisms supported can be specified at the MS-layer and the path layer. Knowing the specific layer the attributes exist at allow for higher quality routes to be developed*. It can also allow for proper provisioning of upper layer functions, such as protection hold off timers*. - Combining layer specific attributes with layer relationships can provide a more efficient encoding mechanism than requiring separate link announcements per layer*. 4. The "TDM" Interface Switching Capability presumably includes layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and G.709. The interaction with these layers needs to be defined. 5. In many cases, 8 levels of priority are not necessary*. A more compact encoding that has a bitfield stating the priority levels being announced would reduce the size of the announcement. The IESG wrote: > The IESG has received a request from the Common Control and Measurement > Plane Working Group to consider publication of the following two > Internet-Drafts as Proposed Standards: > > o Routing Extensions in Support of Generalized MPLS > > o OSPF Extensions in Support of Generalized MPLS > > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-24. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-09.txt ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ _______________________________________________ This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 08:08:44 -0800 Date: Fri, 28 Feb 2003 11:08:03 -0500 From: Scott W Brim To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030228160802.GI2224@sbrim-w2k> Mail-Followup-To: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i On Fri, Feb 28, 2003 04:52:40PM +0100, Mak, L (Leen) allegedly wrote: > Wouldn't it be good to bring this whole discussion to the > ietf-problem-statement mailing list? It appears to be of > a wider scope than ccamp and mpls. > > Leen. Yes, but wrong problem. They're working on truly fundamental processes right now, and won't have room for issues of external relations until they finish with the internals. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 07:54:25 -0800 Message-ID: From: "Mak, L (Leen)" To: "'Stephen Trowbridge'" , Dimitri.Papadimitriou@alcatel.be Cc: John Drake , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 16:52:40 +0100 MIME-Version: 1.0 Content-Type: text/plain Wouldn't it be good to bring this whole discussion to the ietf-problem-statement mailing list? It appears to be of a wider scope than ccamp and mpls. Leen. > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: vrijdag 28 februari 2003 16:18 > To: Dimitri.Papadimitriou@alcatel.be > Cc: John Drake; Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Dimitri, > I have to respond in the same flavor that I responded to John. > > Why is it that when we send the same type of request to ATM > forum, the result is that they spend effort to try to understand > the problem we are trying to solve and provide a great deal > of helpful input directed at solving the problem we have raised? > They have been genuinely interested in trying to figure out how > their protocol can be applied and extended to solve our problem. > > You mention needing a "decoder ring" to decipher G.8080 terminology, > yet this terminology is certainly as foreign to ATM forum as it > would be to ccamp (perhaps even moreso, since I think there is > far more overlap in attendance between ITU-T SG15 and ccamp than > there is between ITU-T SG15 and ATM forum). Yet ATM forum had no > difficulty to understand what we were trying to do and to help us > to develop the solution. > > I do not think that this is because people in the ATM forum are > so much more intelligent than those in ccamp: in fact, many people > I have met in ccamp are absolutely brilliant. So if it is not the > ability of the people that prevents this kind of productive work, > I have to believe it is a shortcoming of the process. > > IETF stands nearly alone in the community of International standards > development organizations in not taking incoming liaisons as a > very serious input. It is only recently that we even had a place > to post incoming liaisons for IETF > (http://www.ietf.org/IESG/liaison.html). > Now it is important to develop a process to make sure that > those liaisons > are considered. > > In addition, IETF needs to be able to generate liaison statements > in order to effectively influence the work of other SDOs. IETF has > historically taken the view that they don't need to send anybody > anything because any information related to IETF can be found > on their web site or seen on the mailing list. But as a practical > matter, for most SDOs, input documents include contributions from > members, documents (like agendas and reports) prepared by those with > official positions, and LIAISON STATEMENTS. Surely you don't expect > that most SDOs will consider as serious input something that somebody > found on a web site or saw on a mailing list. To make IETF output > be an input to another SDO, in most cases IETF will need to formally > send it to the other SDO in the form of a liaison statement. > To date, IETF has been unsuccessful in doing this. > Regards, > Steve > > Dimitri.Papadimitriou@alcatel.be wrote: > > > > stephen > > > > i am resending you the e-mail sent to john because > > i am not sure you have red it "> What we got from > > IETF ccamp was ignored (until we finally did the > > work somewhere else and tried to get code points > > assigned)." > > > > --- > > 1) in order to initiate an action a clear under > > standing of the problem must be achieved by the > > ccamp wg community in order to make this happen > > > > 2) expect that ietf community would understand > > the terminology used in g.8080 (and subsequently > > the issue) by sending a liaison was probably > > a bit too optimistic -> thus the idea was to > > initiate a sort of "decoder ring" (just to be sure > > that when we say a "table" we are all in common > > agreement on what a table is) > > > > 3) instead of request changes to gmpls it would > > have been much more constructive to know really > > what are the architectural aspects covered by > > itu that are the key in enabling signalling for > > optical networks -> from that *clear* perspective > > the ccamp wg was expecting a "functional spec" > > i-d ... since the idea here was to understand > > the functional requirement outside of any specific > > signalling protocol (thus make abstraction of > > what was included in g.7713.x in a first phase) > > > > 4) once terminology + functional aspects would > > have been understood by the ccamp wg deliver the > > right answer using the ccamp community tools and > > protocols > > --- > > > > last it is not the ccamp wg consensus that has > > pushed itu editors to go to the info track ... > > > > thanks, > > - dimiti. > > > > Stephen Trowbridge wrote: > > > > > > John, > > > > > > > JD: Is that a threat or a promise? BTW, call & > connection separation > > > > doesn't exist in PNNI either, at least up to the point > that I stopped > > > > attending the ATM Forum. > > > Interesting that you should mention this. > > > > > > We sent liaisons to the ATM forum, just as we did to IETF ccamp. > > > The reaction we got from the ATM forum was a great deal of help to > > > extend the PNNI protocols to meet our requirements. They provided > > > us numerous, helpful comments all through the process of > development > > > of G.7713.1. > > > > > > What we got from IETF ccamp was ignored (until we finally did the > > > work somewhere else and tried to get code points assigned). > > > > > > We seem to have different understandings of what the > problem is that > > > needs to be solved. My belief is that the problem is that we don't > > > have a good process for dealing with liaisons in IETF, and this > > > inhibits the kinds of productive relationships between > IETF and other > > > SDOs that exist between many other (non-IETF) SDOs. > > > > > > Some others on this thread seem to think that the problem is those > > > other pesky SDOs: after all, how could there possibly be a valid > > > problem statement or requirement that wasn't conceived of > and developed > > > entirely within IETF? Every possible measure should be taken to > > > prevent that any work is done to address such requirements. > > > > > > What is your perception of the problem? > > > Steve > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : +32 3 240-8491 > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 07:18:34 -0800 Message-ID: <3E5F7D95.8120462D@lucent.com> Date: Fri, 28 Feb 2003 08:17:41 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: John Drake , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dimitri, I have to respond in the same flavor that I responded to John. Why is it that when we send the same type of request to ATM forum, the result is that they spend effort to try to understand the problem we are trying to solve and provide a great deal of helpful input directed at solving the problem we have raised? They have been genuinely interested in trying to figure out how their protocol can be applied and extended to solve our problem. You mention needing a "decoder ring" to decipher G.8080 terminology, yet this terminology is certainly as foreign to ATM forum as it would be to ccamp (perhaps even moreso, since I think there is far more overlap in attendance between ITU-T SG15 and ccamp than there is between ITU-T SG15 and ATM forum). Yet ATM forum had no difficulty to understand what we were trying to do and to help us to develop the solution. I do not think that this is because people in the ATM forum are so much more intelligent than those in ccamp: in fact, many people I have met in ccamp are absolutely brilliant. So if it is not the ability of the people that prevents this kind of productive work, I have to believe it is a shortcoming of the process. IETF stands nearly alone in the community of International standards development organizations in not taking incoming liaisons as a very serious input. It is only recently that we even had a place to post incoming liaisons for IETF (http://www.ietf.org/IESG/liaison.html). Now it is important to develop a process to make sure that those liaisons are considered. In addition, IETF needs to be able to generate liaison statements in order to effectively influence the work of other SDOs. IETF has historically taken the view that they don't need to send anybody anything because any information related to IETF can be found on their web site or seen on the mailing list. But as a practical matter, for most SDOs, input documents include contributions from members, documents (like agendas and reports) prepared by those with official positions, and LIAISON STATEMENTS. Surely you don't expect that most SDOs will consider as serious input something that somebody found on a web site or saw on a mailing list. To make IETF output be an input to another SDO, in most cases IETF will need to formally send it to the other SDO in the form of a liaison statement. To date, IETF has been unsuccessful in doing this. Regards, Steve Dimitri.Papadimitriou@alcatel.be wrote: > > stephen > > i am resending you the e-mail sent to john because > i am not sure you have red it "> What we got from > IETF ccamp was ignored (until we finally did the > work somewhere else and tried to get code points > assigned)." > > --- > 1) in order to initiate an action a clear under > standing of the problem must be achieved by the > ccamp wg community in order to make this happen > > 2) expect that ietf community would understand > the terminology used in g.8080 (and subsequently > the issue) by sending a liaison was probably > a bit too optimistic -> thus the idea was to > initiate a sort of "decoder ring" (just to be sure > that when we say a "table" we are all in common > agreement on what a table is) > > 3) instead of request changes to gmpls it would > have been much more constructive to know really > what are the architectural aspects covered by > itu that are the key in enabling signalling for > optical networks -> from that *clear* perspective > the ccamp wg was expecting a "functional spec" > i-d ... since the idea here was to understand > the functional requirement outside of any specific > signalling protocol (thus make abstraction of > what was included in g.7713.x in a first phase) > > 4) once terminology + functional aspects would > have been understood by the ccamp wg deliver the > right answer using the ccamp community tools and > protocols > --- > > last it is not the ccamp wg consensus that has > pushed itu editors to go to the info track ... > > thanks, > - dimiti. > > Stephen Trowbridge wrote: > > > > John, > > > > > JD: Is that a threat or a promise? BTW, call & connection separation > > > doesn't exist in PNNI either, at least up to the point that I stopped > > > attending the ATM Forum. > > Interesting that you should mention this. > > > > We sent liaisons to the ATM forum, just as we did to IETF ccamp. > > The reaction we got from the ATM forum was a great deal of help to > > extend the PNNI protocols to meet our requirements. They provided > > us numerous, helpful comments all through the process of development > > of G.7713.1. > > > > What we got from IETF ccamp was ignored (until we finally did the > > work somewhere else and tried to get code points assigned). > > > > We seem to have different understandings of what the problem is that > > needs to be solved. My belief is that the problem is that we don't > > have a good process for dealing with liaisons in IETF, and this > > inhibits the kinds of productive relationships between IETF and other > > SDOs that exist between many other (non-IETF) SDOs. > > > > Some others on this thread seem to think that the problem is those > > other pesky SDOs: after all, how could there possibly be a valid > > problem statement or requirement that wasn't conceived of and developed > > entirely within IETF? Every possible measure should be taken to > > prevent that any work is done to address such requirements. > > > > What is your perception of the problem? > > Steve > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 07:04:42 -0800 Message-ID: <3E5F7A2B.1EA172F8@alcatel.be> Date: Fri, 28 Feb 2003 16:03:07 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) MIME-Version: 1.0 To: John Drake Cc: "'Stephen Trowbridge'" , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii john, i worry about the fundamental reasons behind "I'm assuming that in your worldview that the Yokohama CCAMP meeting never happened?" which is for me a very sensible and relevant point because it means imho that independently of the real quality and level of details of the (future) liaison process, clearly there are some "centrifuge" forces that tends to discourage a good collaboration (meaning is there somewhere reasons and interest in not making this happening - why ?), consensus made during this yokohama meeting was unformal and had been overridden thus why the formal one would work better and preclude such situations to happen once again ? since at the end of the day people behind the process make the decision (and since we speak about the same group of people...) in a sense the yokohama meeting is not just about it went to an info track ... it is to know *which* were the technical and non-technical reasons for the i-d editors in deciding to go the info track and not working in the scope of the working group ? as long as this question is not solved i really worry about the real intent behind the current thread. thanks, - dimitri. John Drake wrote: > > Snipped... > > > If SONET/SDH did not have what was required for this application, > > I assume that IETF should first come to T1X1/ITU-T for the needed > > extensions (much as ITU-T first came to IETF for the needed > > extensions-remember?) > > JD: I'm assuming that in your worldview that the Yokohama CCAMP meeting > never happened? > > > In contrast to the IP network, you have demarcation points User/Network > and > > between network operators for billing purposes, etc. This > > leads to some new requirements (e.g., call & connection separation) > > not met by the base protocol. Is it reasonable that we want to > > use the (G)MPLS protocols as a base and (inside or outside of > > IETF) define the minimum set of extensions to meet the requirements, > > or should we just have stuck with PNNI? > > JD: Is that a threat or a promise? BTW, call & connection separation > doesn't exist in PNNI either, at least up to the point that I stopped > attending the ATM Forum. > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 07:01:23 -0800 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA837E@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'Brungard, Deborah A, ALABS'" , Loa Andersson Cc: "Wijnen, Bert (Bert)" , Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 10:00:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" One of the reasons I believe it to be critical to address the liaison aspects up front is that the issue actually goes well beyond specification of an administrative process. I.e., as can be seen from the email threads, it brings up the whole discussion of how requirements for non-IP applications originating from other SDOs are addressed. One train of thought expressed on the email list appears to take the view that such requirements should have no extra weight than an individual than that of an individual; there is no concept of a peer SDO. Eve -----Original Message----- From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com] Sent: Thursday, February 27, 2003 5:20 PM To: Loa Andersson Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt agree... I suggest the liaison process should be a separate document. And update this if it needs updating. For people outside of IETF or new to IETF, it is useful to have these process descriptions. And they are two different subjects (with common links). For Steve, Eve, etc, I think there are two (at least) discussions on-going (1) the liaison process (which will have the "hooks" to this document and vice versa), and (2) the "what if scenario" (for non-USA, this is our new shuttle terminology): how this document relates to if an sdo (or individual) works outside this process (info rfcs). It would be good (considering the discussion level) to add some clarification text to the chng proc draft. One option suggested by Kireeti "this is where the SDO can decide, as you point out, that it can do it on its own, but changes the name of the protocol so that innocent bystanders can tell the difference." The SDO protocol is not IETF (as this chng proc draft states) and not (G)MPLS. And as Kireeti suggested the assignments by IANA should distinguish. Another option, suggested by Steve, is that IETF should be a clearinghouse. And discussion is on-going on the interpretation of clearinghouse. Steve, your email may be mis-interpreted, e.g.: "A better approach would be for the IETF to PROMOTE the use of its protocols for new applications, and, when another Standards Development Organization wishes to apply (G)MPLS protocols to an application domain outside of the scope of IETF, that IETF will (1) assist with the development of any necessary extensions; and (2) to facilitate documentation of such new applications and extensions in a central place (e.g., by informational RFC, even for extensions that are developed outside of IETF) and to insure that code points are assigned in a coherent manner through IANA to avoid collisions where different extensions may use the same code points to indicate different things." I don't think you are requesting IETF to simply endorse another sdo's work without review (unless the interpretation of assist=review), and I am not so sure about the promotion either. In T1X1/ITU, just at this last meeting, many have voiced concern with new applications (suggested within the group) for GFP: PON, switched layer. The concern is on extending GFP beyond what it was designed. What if another forum decided to do switched GFP? And they liaisoned to ITU to incorporate the necessary extensions? Remember the difficulties we have with IEEE 10G WAN. It calls itself SDH, but it is not SDH (as we know SDH is more than just G.707). And it is already causing confusion among the innocent. And remember "SONET Lite". Here, in IETF, they have the same concern if the name GMPLS is used. GMPLS is more than just extensions. Some possibilities: at minimum, if IANA assignment is requested by a sdo, the name should at least distinguish it as non-IETF. And in the scope clarify it is outside of the IETF process. Or change the rfc name "informational" as it can be mis-interpreted. In ITU rec'ds, we have appendices which are informational, but they are part of the "ITU process" i.e. reviewed/agreed. Deborah -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, February 27, 2003 11:59 AM To: Brungard, Deborah A, ALABS Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Deborah, I suggested earlier that we describe (short) in the draft how we will handle liasions comeing into the IETF with request for changes or requirments related to the (g)mpls protocols. It needs to be understood that the internal IETF process is specified for IDs, and in some way we need bridge that gap. IETF and its working groups modifies IDs, and I don't think it is good idea to start modifying liasions from other SDOs. That we define the liasion process so it becoes crips and clear, and if when we are doing find that it has an impact on the change process, we updte or re-organize the the documents at that time. Would that work? I guess that the answer is - yes, but only as much (little) as needed. /Loa Brungard, Deborah A, ALABS wrote: >Maybe lets go back to my hopefully simple question, will the liaison process be included in this draft or not? I (thought) the answer was no. Maybe best to clarify. And not that it is not important, all the mail agrees it is important. Then we can work from this draft with comments, recognizing the liaison process will be separate, e.g. where the draft discusses other sdos, we can add text to clarify. > >One comment on all of this from an ITU/T1X1 history, it is difficult to say apriori how a liaison will be processed. We do not have such a process either. Several ways exist to respond: >1. simple thank you for the information >2. here's the answer/clarification based on current work >3. for a quick answer, at the meeting, have a breakout group to address a proposal >4. for new work, send a response saying we invite contributions to our future meetings to progress > - if no contributions, not anything is done (yes we have done this too) > - at the next meeting, send several proposals to the other group for their review > >I had understood this draft as including option 4. Other mails are raising the concern, as in the past, if no response to the other sdo, the other sdo can not determine the status of the work. That can be part of the liaison process. > >Let's first clarify, do we want this draft to include the liaison process or should we do it separate (in parallel?)? > >Deborah > > > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Thursday, February 27, 2003 10:47 AM >To: Kireeti Kompella; Wijnen, Bert (Bert) >Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > >Inline > > > >>-----Original Message----- >>From: Kireeti Kompella [mailto:kireeti@juniper.net] >>Sent: donderdag 27 februari 2003 10:09 >>To: Wijnen, Bert (Bert) >>Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt >> >> >>Hi Bert, >> >>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: >> >> >> >>>No of course NOT. Many Liasons will want an answer. >>>So we need a process to follow up and to track if a timely >>>response has been (or will be) send. >>> >>> >>Is the IETF process for replying to liaison statements (and of >>generating them) written down, say in some RFC? If so, could you >>send me a pointer? >> >> >> >Unfortunately, I don't think the process for that has been defined. >That is why I said that "we need a process..." >We do not have it yet (I think... at least I do not know it either). >I think we were all just hoping people would take responsibility and >do the right things... but as we know that is how things fall through >the cracks. > > > >>>But the Liasons communication between ITU and CCAMP/MPLS has not >>>been going smoothly so far (even though we had good intentions). >>>Responses have not gone out in time (or in some cases at all). >>> >>> >>I'll take full responsibility for that. >> >> >> >W.r.t. CCAMP I will share some of the responsibility too. I should >also have kept a better eye on it. > >Bert > > >>Thanks, >>Kireeti. >> >> >> > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 06:53:31 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972276@nimbus> From: John Drake To: 'Stephen Trowbridge' Cc: Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 06:52:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Stephen, This is the note I sent yesterday, which I thought was fairly clear. Thanks, John ============================================================================ ==================================== Kireeti, Extremely well reasoned and thoughtful. As I understand it, this document is intended to prevent the situation that just occured, in which the IETF published an RFC which detailed some changes to RSVP-TE (which had technical issues) without any review by the CCAMP or MPLS working groups, thereby explicitly appearing to endorse these changes. The minutes of the Yokohama CCAMP meeting (see below) seem to indicate that the CCAMP working group wanted to work on the ASON extensions, so I am still puzzled as to why the authors of the ASON draft decided, after the Yokohama meeting, to progress the draft as an informational RFC rather than as a normal working group draft. Thanks, John > -----Original Message----- > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com] > Sent: Friday, February 28, 2003 6:22 AM > To: John Drake > Cc: Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > John, > > > JD: Is that a threat or a promise? BTW, call & connection > separation > > doesn't exist in PNNI either, at least up to the point that > I stopped > > attending the ATM Forum. > Interesting that you should mention this. > > We sent liaisons to the ATM forum, just as we did to IETF ccamp. > The reaction we got from the ATM forum was a great deal of help to > extend the PNNI protocols to meet our requirements. They provided > us numerous, helpful comments all through the process of development > of G.7713.1. > > What we got from IETF ccamp was ignored (until we finally did the > work somewhere else and tried to get code points assigned). > > We seem to have different understandings of what the problem is that > needs to be solved. My belief is that the problem is that we don't > have a good process for dealing with liaisons in IETF, and this > inhibits the kinds of productive relationships between IETF and other > SDOs that exist between many other (non-IETF) SDOs. > > Some others on this thread seem to think that the problem is those > other pesky SDOs: after all, how could there possibly be a valid > problem statement or requirement that wasn't conceived of and > developed > entirely within IETF? Every possible measure should be taken to > prevent that any work is done to address such requirements. > > What is your perception of the problem? > Steve > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 06:47:41 -0800 Message-ID: <3E5F75FC.C87FE659@alcatel.be> Date: Fri, 28 Feb 2003 15:45:16 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) MIME-Version: 1.0 To: Stephen Trowbridge Cc: John Drake , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii stephen i am resending you the e-mail sent to john because i am not sure you have red it "> What we got from IETF ccamp was ignored (until we finally did the work somewhere else and tried to get code points assigned)." --- 1) in order to initiate an action a clear under standing of the problem must be achieved by the ccamp wg community in order to make this happen 2) expect that ietf community would understand the terminology used in g.8080 (and subsequently the issue) by sending a liaison was probably a bit too optimistic -> thus the idea was to initiate a sort of "decoder ring" (just to be sure that when we say a "table" we are all in common agreement on what a table is) 3) instead of request changes to gmpls it would have been much more constructive to know really what are the architectural aspects covered by itu that are the key in enabling signalling for optical networks -> from that *clear* perspective the ccamp wg was expecting a "functional spec" i-d ... since the idea here was to understand the functional requirement outside of any specific signalling protocol (thus make abstraction of what was included in g.7713.x in a first phase) 4) once terminology + functional aspects would have been understood by the ccamp wg deliver the right answer using the ccamp community tools and protocols --- last it is not the ccamp wg consensus that has pushed itu editors to go to the info track ... thanks, - dimiti. Stephen Trowbridge wrote: > > John, > > > JD: Is that a threat or a promise? BTW, call & connection separation > > doesn't exist in PNNI either, at least up to the point that I stopped > > attending the ATM Forum. > Interesting that you should mention this. > > We sent liaisons to the ATM forum, just as we did to IETF ccamp. > The reaction we got from the ATM forum was a great deal of help to > extend the PNNI protocols to meet our requirements. They provided > us numerous, helpful comments all through the process of development > of G.7713.1. > > What we got from IETF ccamp was ignored (until we finally did the > work somewhere else and tried to get code points assigned). > > We seem to have different understandings of what the problem is that > needs to be solved. My belief is that the problem is that we don't > have a good process for dealing with liaisons in IETF, and this > inhibits the kinds of productive relationships between IETF and other > SDOs that exist between many other (non-IETF) SDOs. > > Some others on this thread seem to think that the problem is those > other pesky SDOs: after all, how could there possibly be a valid > problem statement or requirement that wasn't conceived of and developed > entirely within IETF? Every possible measure should be taken to > prevent that any work is done to address such requirements. > > What is your perception of the problem? > Steve -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 06:41:48 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972275@nimbus> From: John Drake To: 'Gert Grammel' Cc: 'Kireeti Kompella' , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Fri, 28 Feb 2003 06:40:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Gert, I'm sorry, I was teasing. I was saying that if the IETF didn't like certain features of the G.709 transport plane, following Stephen's argument, it shouldn't feel constrained about changing them. I wasn't talking about your draft, which I think is a very good piece of work. Thanks, John > -----Original Message----- > From: Gert Grammel [mailto:Gert.Grammel@alcatel.de] > Sent: Friday, February 28, 2003 4:10 AM > To: John Drake > Cc: 'Kireeti Kompella'; Stephen Trowbridge; ccamp@ops.ietf.org; > mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Hi John, > > I am not sure if I've got your point here about G.709 and the > way it is linked > to the liason stuff. ITU-T defined G.709 as another circuit > technology to > transport bits from A to B. It is similar to SDH/SONET and > falls into the ASON > scope. Applying GMPLS on G.709 is straight forward and I am > not aware of any > specific open issues here. > In SDH/SONET some of the involved guys were trying to include > non-standard > SDH/SONET features in the ietf-draft, meaning those not > explicitly mentioned in > G.707. This caused of course a lot of friction. In contrast > to that, the G.709 > authors team is committed to remove everything from > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g70 > 9-03.txt which is > not covered by G.709. In this sense it has the potential to > become a boiler > plate for tight collaboration. > So why do you think this work should be depreciated in CCAMP? > > Regards > > Gert > > > > > > > John Drake wrote: > > > Kireeti, > > > > There's always been a few things that I didn't like about > G.709, so maybe we > > can just go ahead and deprecate them in CCAMP. Then we can > figure this > > liason stuff and tell the ITU about it. > > > > Thanks, > > > > John > > > > > -----Original Message----- > > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > > Sent: Thursday, February 27, 2003 3:04 PM > > > To: Stephen Trowbridge > > > Cc: ccamp@ops.ietf.org; mpls@UU.NET > > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > > > > > > Hi Steve, > > > > > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > > > > > If they decide not to be involved and the other SDO > goes ahead with > > > > developing their own solution, they don't need to bless the > > > extension, > > > > or even like it, but they do need to accept it. > > > > > > Going back to the examples that Deborah brought up: what > if other SDOs > > > produced variants of SDH -- would you say that the ITU "do need to > > > accept it"? > > > > > > Kireeti. > > > > > -- > Alcatel Optical Network Division Gert Grammel > Network Strategy phone: +49 711 821 47368 > Lorenzstrasse 10 fax: +49 711 821 43169 > D-70435 Stuttgart mailto:Gert.Grammel@alcatel.de > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 06:22:37 -0800 Message-ID: <3E5F706D.C7879FA3@lucent.com> Date: Fri, 28 Feb 2003 07:21:33 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: John Drake CC: Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John, > JD: Is that a threat or a promise? BTW, call & connection separation > doesn't exist in PNNI either, at least up to the point that I stopped > attending the ATM Forum. Interesting that you should mention this. We sent liaisons to the ATM forum, just as we did to IETF ccamp. The reaction we got from the ATM forum was a great deal of help to extend the PNNI protocols to meet our requirements. They provided us numerous, helpful comments all through the process of development of G.7713.1. What we got from IETF ccamp was ignored (until we finally did the work somewhere else and tried to get code points assigned). We seem to have different understandings of what the problem is that needs to be solved. My belief is that the problem is that we don't have a good process for dealing with liaisons in IETF, and this inhibits the kinds of productive relationships between IETF and other SDOs that exist between many other (non-IETF) SDOs. Some others on this thread seem to think that the problem is those other pesky SDOs: after all, how could there possibly be a valid problem statement or requirement that wasn't conceived of and developed entirely within IETF? Every possible measure should be taken to prevent that any work is done to address such requirements. What is your perception of the problem? Steve Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 05:42:08 -0800 Message-ID: <3E5F66D7.D8FB0C2A@lucent.com> Date: Fri, 28 Feb 2003 08:40:39 -0500 From: Yangguang Xu Organization: Lucent Technologies, Inc. MIME-Version: 1.0 To: curtis@fictitious.org CC: Stephen Trowbridge , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Curtis, > > Go right a head and use PNNI. Don't forget to run it over CLNP on a > cell based infrastructure. :-) > Just a minor correction, it's PNNI over SSCOPMCE over anything (include IP). Yet, I am not saying that I like it :-) Yangguang Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 04:11:18 -0800 Message-ID: <3E5F519F.68510CBC@alcatel.de> Date: Fri, 28 Feb 2003 13:10:08 +0100 From: Gert Grammel Organization: Alcatel TND Product Strategy MIME-Version: 1.0 To: John Drake CC: "'Kireeti Kompella'" , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John, I am not sure if I've got your point here about G.709 and the way it is linked to the liason stuff. ITU-T defined G.709 as another circuit technology to transport bits from A to B. It is similar to SDH/SONET and falls into the ASON scope. Applying GMPLS on G.709 is straight forward and I am not aware of any specific open issues here. In SDH/SONET some of the involved guys were trying to include non-standard SDH/SONET features in the ietf-draft, meaning those not explicitly mentioned in G.707. This caused of course a lot of friction. In contrast to that, the G.709 authors team is committed to remove everything from http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-03.txt which is not covered by G.709. In this sense it has the potential to become a boiler plate for tight collaboration. So why do you think this work should be depreciated in CCAMP? Regards Gert John Drake wrote: > Kireeti, > > There's always been a few things that I didn't like about G.709, so maybe we > can just go ahead and deprecate them in CCAMP. Then we can figure this > liason stuff and tell the ITU about it. > > Thanks, > > John > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: Thursday, February 27, 2003 3:04 PM > > To: Stephen Trowbridge > > Cc: ccamp@ops.ietf.org; mpls@UU.NET > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > > > Hi Steve, > > > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > > > If they decide not to be involved and the other SDO goes ahead with > > > developing their own solution, they don't need to bless the > > extension, > > > or even like it, but they do need to accept it. > > > > Going back to the examples that Deborah brought up: what if other SDOs > > produced variants of SDH -- would you say that the ITU "do need to > > accept it"? > > > > Kireeti. > > -- Alcatel Optical Network Division Gert Grammel Network Strategy phone: +49 711 821 47368 Lorenzstrasse 10 fax: +49 711 821 43169 D-70435 Stuttgart mailto:Gert.Grammel@alcatel.de Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Feb 2003 03:24:10 -0800 Message-ID: From: Heiles Juergen To: "'velev@panasonic.de'" , mpls@UU.NET, ccamp@ops.ietf.org Cc: vlan-mpls@panasonic.de Subject: AW: draft-kawakami-mpls-lsp-vlan-00.txt Date: Fri, 28 Feb 2003 12:16:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Genadi, the draft proposes to use the MPLS control plane protocols for a = different transport plane (Ethernet VLAN). This is excatly what GMPLS is about. So I think it would be better to = have the ID and dicussion in ccamp under the GMPLS work. Regards Juergen > -----Urspr=FCngliche Nachricht----- > Von: Genadi Velev [mailto:velev@panasonic.de] > Gesendet: Donnerstag, 27. Februar 2003 17:53 > An: mpls@UU.NET > Cc: vlan-mpls@panasonic.de > Betreff: draft-kawakami-mpls-lsp-vlan-00.txt >=20 >=20 > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] > [ Mail was delivered through VPN PEL->MEI/AVCDC! ] >=20 > Hi all, >=20 > A new draft was published today (please see below). >=20 > Any feedback and comments are welcome, especially from those=20 > of you who are > dealing with packet transport over wide area Ethernet networks. >=20 > thanks, > Genadi >=20 > > -----Original Message----- > > From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of > > Internet-Drafts@ietf.org > > Sent: Thursday, February 27, 2003 1:44 PM > > To: IETF-Announce: > > Cc: mpls@UU.NET > > Subject: I-D ACTION:draft-kawakami-mpls-lsp-vlan-00.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > Title : Method to Setup LSP using VLAN Tag Switching > > Author(s) : T. Kawakami et al. > > Filename : draft-kawakami-mpls-lsp-vlan-00.txt > > Pages : 15 > > Date : 2003-2-26 > > > > This document describes a method to setup a Layer 2 tunnel over > > networks based on Ethernet technology. For this purpose,=20 > the ports of > > an Ethernet switch are configured to forward VLAN=20 > tag-labeled packets > > incoming from a certain port to another unambiguous port by using > > VLAN tag information. The Ethernet switches themselves are a part = of > > the Label Switching Routers (LSRs), which distribute the VLAN tags > > using Label Distribution Protocol (LDP). To enable LDP to=20 > fulfil this > > function, an LDP extension is proposed. The introduced method > > simplifies the transport of Ethernet frames over wide area Ethernet > > networks. > > > > A URL for this Internet-Draft is: > >=20 http://www.ietf.org/internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of > the message. > > Internet-Drafts are also available by anonymous FTP. Login with > the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-kawakami-mpls-lsp-vlan-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-kawakami-mpls-lsp-vlan-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 18:48:59 -0800 Date: Thu, 27 Feb 2003 18:47:35 -0800 (PST) From: Kireeti Kompella To: Curtis Villamizar cc: ccamp@ops.ietf.org, "" Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030227182933.M32865@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Curtis, On Thu, 27 Feb 2003, Curtis Villamizar wrote: > The emphasis on running code and rough consensus rather than study > groups and voting has worked quite well. There is not reason to > change it or to consider a liason comment or contribution and > different from any other contribution. I'm glad to hear this! It is important, especially as this argument goes downhill fast (starting with veiled threats and "I'm calling your bluff" responses), to keep the big picture in mind: a) There is a half-written, half-implicit and half-in-the-hallways process *for the IETF* to change IETF protocols. It would be good to have more of the process written down, at least in the context of (G)MPLS. The primary goal of the (G)MPLS change document is that this process is made known to all SDOs (including the IETF!). b) There are often requirements from other SDOs for changes in IETF protocols. *If* they choose to bring these to the IETF and have the IETF do the changes, it is good for them to know the process. If, as Steve points out, the SDO chooses to make the changes on its own, for whatever reason, that is beyond the scope of the (G)MPLS change document. c) A liaison statement may declare the intent to follow up with the requirements or requests for changes in IETF protocols, but should not (IMO) be used to effect those changes. A process for replying to (and generating) liaisons statements is needed. d) The fundamental IETF mechanisms (though some may view them as broken) such as rough consensus and running code are *not* in question here. Those may be brought up on the general IETF list, or with the IESG or IAB. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 17:52:49 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972273@nimbus> From: John Drake To: 'Stephen Trowbridge' , Kireeti Kompella Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 17:50:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Snipped... > If SONET/SDH did not have what was required for this application, > I assume that IETF should first come to T1X1/ITU-T for the needed > extensions (much as ITU-T first came to IETF for the needed > extensions-remember?) JD: I'm assuming that in your worldview that the Yokohama CCAMP meeting never happened? > In contrast to the IP network, you have demarcation points User/Network and > between network operators for billing purposes, etc. This > leads to some new requirements (e.g., call & connection separation) > not met by the base protocol. Is it reasonable that we want to > use the (G)MPLS protocols as a base and (inside or outside of > IETF) define the minimum set of extensions to meet the requirements, > or should we just have stuck with PNNI? JD: Is that a threat or a promise? BTW, call & connection separation doesn't exist in PNNI either, at least up to the point that I stopped attending the ATM Forum. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 17:52:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200302272356.SAA38712@workhorse.fictitious.org> To: Kireeti Kompella cc: Stephen Trowbridge , ccamp@ops.ietf.org, "" Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 18:56:41 -0500 From: Curtis Villamizar [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] In message <20030227150131.N32160@kummer.juniper.net>, Kireeti Kompella writes: > Hi Steve, > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > If they decide not to be involved and the other SDO goes ahead with > > developing their own solution, they don't need to bless the extension, > > or even like it, but they do need to accept it. > > Going back to the examples that Deborah brought up: what if other SDOs > produced variants of SDH -- would you say that the ITU "do need to > accept it"? > > Kireeti. It really becomes a practical matter. For example, SONET scrambling was changed because the original was too short and too easy to send an IP packet containing the entire reverse scramble sequence leading to all same bit after scrambling, causing a SONET framing error. The ease of doing this was demostrated by a BBN engineer in network operations. Although the push came from the IETF to change this and there was resistance it was changed when it was obvious that customers were going to insist on the change in products, whether or not any SDO blessed the change. The opposite is true in the case of ITU requirements for QoS published in the mid 1990s. IETF didn't like it. No one implemented. No customers asked for it. End of story. An example where the SDO didn't accept changes and the SDO became irrelevant wrt those specs is ISIS, where nearly 100% of implemented and deployed ISIS is according to the IETF defined extensions to ISIS which began with rfc1195. ISO has never quite recognized the IETF extensions, but no one really cares much what ISO thinks about this. A few things have been jammed through the IETF that never went any where. For example, guarenteed services in RSVP, NHRP (and everything the ROLC and ION WGs did, and most of what IPATM did), QoS routing extensions for OSPF. The requirements documet first is a means of insuring better quality control over what emerges from the IETF. (Not in terms of "to the letter perfect" documents, but useful protocols). The emphasis on running code and rough consensus rather than study groups and voting has worked quite well. There is not reason to change it or to consider a liason comment or contribution and different from any other contribution. Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 15:22:42 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972272@nimbus> From: John Drake To: 'Kireeti Kompella' , Stephen Trowbridge Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 15:22:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Kireeti, There's always been a few things that I didn't like about G.709, so maybe we can just go ahead and deprecate them in CCAMP. Then we can figure this liason stuff and tell the ITU about it. Thanks, John > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Thursday, February 27, 2003 3:04 PM > To: Stephen Trowbridge > Cc: ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Hi Steve, > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > If they decide not to be involved and the other SDO goes ahead with > > developing their own solution, they don't need to bless the > extension, > > or even like it, but they do need to accept it. > > Going back to the examples that Deborah brought up: what if other SDOs > produced variants of SDH -- would you say that the ITU "do need to > accept it"? > > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 15:19:41 -0800 Message-ID: <3E5E9CDE.A86FB1BF@lucent.com> Date: Thu, 27 Feb 2003 16:18:54 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kireeti, I'm not sure that this is the same. IETF develops control plane technology that can control SONET/SDH equipment used to carry physical layer connections supporting an IP network. Presumably SONET/SDH doesn't need to change for this application as long as virtual concatenation, etc. support the necessary pipe sizes. If SONET/SDH did not have what was required for this application, I assume that IETF should first come to T1X1/ITU-T for the needed extensions (much as ITU-T first came to IETF for the needed extensions- remember?). If ITU-T then was not interested to help and if standardized SONET/SDH did not meet the requirements, I suppose that IETF would have the right to do what it needed for its application and inform ITU-T what it had done. ITU-T wants to apply the control plane technology to a general purpose (not necessarily IP) transport network. In contrast to the IP network, you have demarcation points User/Network and between network operators for billing purposes, etc. This leads to some new requirements (e.g., call & connection separation) not met by the base protocol. Is it reasonable that we want to use the (G)MPLS protocols as a base and (inside or outside of IETF) define the minimum set of extensions to meet the requirements, or should we just have stuck with PNNI? Regards, Steve Kireeti Kompella wrote: > > Hi Steve, > > On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > > > If they decide not to be involved and the other SDO goes ahead with > > developing their own solution, they don't need to bless the extension, > > or even like it, but they do need to accept it. > > Going back to the examples that Deborah brought up: what if other SDOs > produced variants of SDH -- would you say that the ITU "do need to > accept it"? > > Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 15:06:07 -0800 Message-ID: <3E5E996D.E98F6BA5@alcatel.be> Date: Fri, 28 Feb 2003 00:04:13 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: optical network architecture (nta - antwerpen) MIME-Version: 1.0 To: John Drake Cc: "'George Newsome'" , "'Kireeti Kompella'" , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii john, here it is ... ... and if i well remember.. trying to summarize here the issue: 1) in order to initiate an action a clear under standing of the problem must be achieved by the ccamp wg community in order to make this happen 2) expect that ietf community would understand the terminology used in g.8080 (and subsequently the issue) by sending a liaison was probably a bit too optimistic -> thus the idea was to initiate a sort of "decoder ring" (just to be sure that when we say a "table" we are all in common agreement on what a table is) 3) instead of request changes to gmpls it would have been much more constructive to know really what are the architectural aspects covered by itu that are the key in enabling signalling for optical networks -> from that *clear* perspective the ccamp wg was expecting a "functional spec" i-d ... since the idea here was to understand the functional requirement outside of any specific signalling protocol (thus make abstraction of what was included in g.7713.x in a first phase) 4) once terminology + functional aspects would have been understood by the ccamp wg deliver the right answer using the ccamp community tools and protocols in brief, the idea developed in yokohama was "please put the g.8080 architecture on the table, and let's have a signalling functional i-d to clearly understand the issue and then the ccamp wg community will deliver the adequate gmpls profile" instead of that the two editors of the document decided to go the "info track" ... i never understood the real argumentation behind this ... clearly as we say in french "la sauce n'a pas prise" but i consider this as a turning- point in the ccamp/sg15 collaboration then, as already pointed out, we couldn't avoid "that the SDO can decide to do it on its own, but then changes the name of the protocol so that innocent bystanders can tell the difference." and this is what happened for signalling. note: kireeti please correct me if you think there is something missing or wrong here hope this clarifies, - dimitri. John Drake wrote: > > George, > > I didn't attend. > > Thanks, > > John > > > -----Original Message----- > > From: George Newsome [mailto:gnewsome@ieee.org] > > Sent: Thursday, February 27, 2003 10:17 AM > > To: John Drake > > Cc: 'Kireeti Kompella'; Stephen Trowbridge; ccamp@ops.ietf.org; > > mpls@UU.NET > > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > > > John Drake wrote: > > > > > > > Snipped... > > > > > > Stephen Trowbridge asked what further information the IETF > > requires. > > > > > > Dimitri and Kireeti answered the question in detail." > > > > > > > > > And the answer was ???? > > > > A pity that the detailed answer is apparently not minuted. > > > > George > > -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 15:04:28 -0800 Date: Thu, 27 Feb 2003 15:04:03 -0800 (PST) From: Kireeti Kompella To: Stephen Trowbridge cc: ccamp@ops.ietf.org, "" Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030227150131.N32160@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Steve, On Thu, 27 Feb 2003, Stephen Trowbridge wrote: > If they decide not to be involved and the other SDO goes ahead with > developing their own solution, they don't need to bless the extension, > or even like it, but they do need to accept it. Going back to the examples that Deborah brought up: what if other SDOs produced variants of SDH -- would you say that the ITU "do need to accept it"? Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 14:59:55 -0800 Message-ID: <3E5E97E8.FCBD80C0@lucent.com> Date: Thu, 27 Feb 2003 15:57:44 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: Loa Andersson , "Wijnen, Bert (Bert)" , Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Deborah, > I don't think you are requesting IETF to simply endorse another > sdo's work without review (unless the interpretation of assist=review), > and I am not so sure about the promotion either. This is not quite what I am trying to say - Presumably the other SDO starts communication at the problem statement phase (e.g., the Oct 2001 liaisons SG15 to ccamp). IETF is free to decide if it makes sense for IETF to be involved in development of the solution. If they decide not to be involved and the other SDO goes ahead with developing their own solution, they don't need to bless the extension, or even like it, but they do need to accept it. At this point we may as well document it in an info RFC (not standards track for IETF) and make sure the codepoint assignments are done in a way that avoids conflict or overlap with other extensions. There is another subtlety that perhaps I failed to capture in enough detail. If the IETF does decide to be involved, their involvement is in applying their protocol expertise in determining HOW to solve the problem that the other SDO has raised. I am uncomfortable with a process that leaves the IETF as the sole arbiter of WHETHER the problem will be solved or whether the requirements developed by the other SDO are valid. The application domain being addressed by the other SDO may very well be different than the one being addressed by IETF, and the validity of what the other SDO sees as their requirements for their application domain is not for IETF to decide. I am also a concerned with the following: > One option suggested by Kireeti "this is where the SDO can decide, > as you point out, that it can do it on its own, but > changes the name of the protocol so that innocent bystanders can tell > the difference." This seems like a road to chaos. You end up with a proliferation of (G)MPLS-like protocols which are all slightly different whenever there is a requirement of another SDO that IETF doesn't accept or understand. I think if we can come up with something more of the "clearinghouse" flavor, we can at least keep a common umbrella over the family of IETF and non-IETF developed extensions (based on whether IETF had the interest or expertise to be involved in any particular extension), to understand (as Stephen Shew pointed out) which extensions can co-exist, to avoid conflicts, etc. Regards, Steve Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 14:21:48 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 17:19:46 -0500 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC62406845A2D@OCCLUST02EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLeghuyx5kIjzOjQRWJi1Sg+b9jmQAF4v+Q From: "Brungard, Deborah A, ALABS" To: "Loa Andersson" Cc: "Wijnen, Bert (Bert)" , "Kireeti Kompella" , "Scott W Brim" , , agree... I suggest the liaison process should be a separate document. And update = this if it needs updating. For people outside of IETF or new to IETF, it = is useful to have these process descriptions. And they are two different = subjects (with common links). For Steve, Eve, etc, I think there are two (at least) discussions = on-going (1) the liaison process (which will have the "hooks" to this = document and vice versa), and (2) the "what if scenario" (for non-USA, = this is our new shuttle terminology): how this document relates to if an = sdo (or individual) works outside this process (info rfcs). It would be = good (considering the discussion level) to add some clarification text = to the chng proc draft. One option suggested by Kireeti "this is where the SDO can decide, as = you point out, that it can do it on its own, but changes the name of the = protocol so that innocent bystanders can tell the difference." The SDO = protocol is not IETF (as this chng proc draft states) and not (G)MPLS. = And as Kireeti suggested the assignments by IANA should distinguish. = Another option, suggested by Steve, is that IETF should be a = clearinghouse. And discussion is on-going on the interpretation of = clearinghouse.=20 Steve, your email may be mis-interpreted, e.g.: "A better approach would be for the IETF to PROMOTE the use of its protocols for new applications, and, when another Standards Development Organization wishes to apply (G)MPLS protocols to an application domain outside of the scope of IETF, that IETF will (1) assist with the = development of any necessary extensions; and (2) to facilitate documentation of such new applications and extensions in a central place (e.g., by informational RFC, even for extensions that are developed outside of IETF) and to insure that code points are assigned in a coherent manner through IANA to avoid collisions where different extensions may use the same code points to indicate different things." I don't think you are requesting IETF to simply endorse another sdo's = work without review (unless the interpretation of assist=3Dreview), and = I am not so sure about the promotion either. In T1X1/ITU, just at this = last meeting, many have voiced concern with new applications (suggested = within the group) for GFP: PON, switched layer. The concern is on = extending GFP beyond what it was designed. What if another forum decided = to do switched GFP? And they liaisoned to ITU to incorporate the = necessary extensions? Remember the difficulties we have with IEEE 10G = WAN. It calls itself SDH, but it is not SDH (as we know SDH is more than = just G.707). And it is already causing confusion among the innocent. And = remember "SONET Lite". Here, in IETF, they have the same concern if the = name GMPLS is used. GMPLS is more than just extensions. Some possibilities: at minimum, if IANA assignment is requested by a = sdo, the name should at least distinguish it as non-IETF. And in the = scope clarify it is outside of the IETF process. Or change the rfc name = "informational" as it can be mis-interpreted. In ITU rec'ds, we have = appendices which are informational, but they are part of the "ITU = process" i.e. reviewed/agreed. Deborah -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, February 27, 2003 11:59 AM To: Brungard, Deborah A, ALABS Cc: Wijnen, Bert (Bert); Kireeti Kompella; Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Deborah, I suggested earlier that we describe (short) in the draft how we will=20 handle liasions comeing into the IETF with request for changes or requirments related to = the (g)mpls protocols. It needs to be understood that the internal IETF process is=20 specified for IDs, and in some way we need bridge that gap. IETF and its working=20 groups modifies IDs, and I don't think it is good idea to start modifying liasions from other = SDOs. That we define the liasion process so it becoes crips and clear, and if=20 when we are doing find that it has an impact on the change process, we updte or=20 re-organize the the documents at that time. Would that work? I guess that the answer is - yes, but only as much=20 (little) as needed. /Loa Brungard, Deborah A, ALABS wrote: >Maybe lets go back to my hopefully simple question, will the liaison = process be included in this draft or not? I (thought) the answer was no. = Maybe best to clarify. And not that it is not important, all the mail = agrees it is important. Then we can work from this draft with comments, = recognizing the liaison process will be separate, e.g. where the draft = discusses other sdos, we can add text to clarify. > >One comment on all of this from an ITU/T1X1 history, it is difficult to = say apriori how a liaison will be processed. We do not have such a = process either. Several ways exist to respond: >1. simple thank you for the information >2. here's the answer/clarification based on current work >3. for a quick answer, at the meeting, have a breakout group to address = a proposal >4. for new work, send a response saying we invite contributions to our = future meetings to progress > - if no contributions, not anything is done (yes we have done this = too) > - at the next meeting, send several proposals to the other group for = their review > >I had understood this draft as including option 4. Other mails are = raising the concern, as in the past, if no response to the other sdo, = the other sdo can not determine the status of the work. That can be part = of the liaison process. > >Let's first clarify, do we want this draft to include the liaison = process or should we do it separate (in parallel?)? > >Deborah > > > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Thursday, February 27, 2003 10:47 AM >To: Kireeti Kompella; Wijnen, Bert (Bert) >Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > >Inline > > =20 > >>-----Original Message----- >>From: Kireeti Kompella [mailto:kireeti@juniper.net] >>Sent: donderdag 27 februari 2003 10:09 >>To: Wijnen, Bert (Bert) >>Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt >> >> >>Hi Bert, >> >>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: >> >> =20 >> >>>No of course NOT. Many Liasons will want an answer. >>>So we need a process to follow up and to track if a timely >>>response has been (or will be) send. >>> =20 >>> >>Is the IETF process for replying to liaison statements (and of >>generating them) written down, say in some RFC? If so, could you >>send me a pointer? >> >> =20 >> >Unfortunately, I don't think the process for that has been defined. >That is why I said that "we need a process..." >We do not have it yet (I think... at least I do not know it either). >I think we were all just hoping people would take responsibility and >do the right things... but as we know that is how things fall through >the cracks. > > =20 > >>>But the Liasons communication between ITU and CCAMP/MPLS has not >>>been going smoothly so far (even though we had good intentions). >>>Responses have not gone out in time (or in some cases at all). >>> =20 >>> >>I'll take full responsibility for that. >> >> =20 >> >W.r.t. CCAMP I will share some of the responsibility too. I should=20 >also have kept a better eye on it. > >Bert > =20 > >>Thanks, >>Kireeti. >> >> =20 >> > > > > > =20 > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 13:29:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200302271914.OAA35772@workhorse.fictitious.org> To: erosen@cisco.com cc: Loa Andersson , Kireeti Kompella , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 14:14:22 -0500 From: Curtis Villamizar [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] In message <200302271822.h1RIMn56013326@sj-msg-core-1.cisco.com>, Eric Rosen wr ites: > > It seems to me that Loa's document simply describes how the IETF works. As > such, I'm not sure it is even necessary. > > True, many people have noticed that the IETF is free to ignore the work of > other standard organizations. True, the fact that a particular proposal is > made by another standards organization does not even give the proposal any > special weight in the IETF. > > I think these are good things, and the IETF should not make any changes in > this respect. Hence I don't think Loa's draft (if it needs to exist) needs > to change. > > Certainly the fact that some position is articulated in a "liaison > statement" should not give it any special weight. The fact that some > position is supported by "a threshold number of vendors and SPs" shouldn't > give it any special weight either. Eric, I completely agree with you but would like to make one clarification. The "number of vendors and SPs" should not be given any weight at all in toward the rough consensus criteria. However, implementation by vendors and deployment by SPs should be given strong consideration regarding whether there exists any "running code" and "independent interoperable implementations". The IETF shouldn't care who you think you are or who you work for if you don't show up with running code. This eliminates committee contributions such as study groups with a spec and no code or deployment (and sometimes no valid requirement). The number of internet-drafts that were not advanced due to not having concensus on a requirements statement is quite large. Few rejected on that grounds resurfaced later when a need became evident and extremely few resurfaced and were later implemented. Diffserv-TE is about the only set of drafts to get pushed back, resurface, and get implemented and this was not a liason work. Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 13:29:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200302271820.NAA35035@workhorse.fictitious.org> To: "Ong, Lyndon" cc: "'Loa Andersson'" , "Brungard, Deborah A, ALABS" , "Wijnen, Bert (Bert)" , Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 13:20:24 -0500 From: Curtis Villamizar [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] In message <2135200C183FD5119588009027DE572302836D53@webdev-owa.oni.com>, "Ong, Lyndon" writes: > Hi, > > Can I ask a clarifying question regarding liaisons? The > issue revolves around making extensions to GMPLS. Is > it the view that such extensions must be generated > through Internet Drafts, and cannot be through > liaisons? > > It sounds like people may be assuming that liaisons are > always providing background information or requesting > information, when on occasion a liaison may be requesting > a change or action. > > BTW, regarding responses to liaisons, the A-D may or may > not be the proper source for a response, but the knowledge > for putting together the response would typically reside > within a particular WG, I believe. One problem is that > you don't have the time within an IETF meeting to assign > a "stuckie" (to use the new term) to write a response ;o) > > Cheers, > > Lyndon The way you initiate action within the IETF is to submit an internet draft. The liason response from the IETF should simply be to send a copy of rfc2026 and invite participants of the other forum to participate in the IETF process. Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 13:29:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <200302271739.MAA34672@workhorse.fictitious.org> To: "Wijnen, Bert (Bert)" cc: Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 12:39:08 -0500 From: Curtis Villamizar [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] In message <7D5D48D2CAA3D84C813F5B154F43B15501062F74@nl0006exch001u.nl.lucent.c om>, "Wijnen, Bert (Bert)" writes: > Inline > > > -----Original Message----- > > From: Kireeti Kompella [mailto:kireeti@juniper.net] > > Sent: donderdag 27 februari 2003 10:09 > > To: Wijnen, Bert (Bert) > > Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET > > Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > > > > Hi Bert, > > > > On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: > > > > > No of course NOT. Many Liasons will want an answer. > > > So we need a process to follow up and to track if a timely > > > response has been (or will be) send. > > > > Is the IETF process for replying to liaison statements (and of > > generating them) written down, say in some RFC? If so, could you > > send me a pointer? > > > Unfortunately, I don't think the process for that has been defined. > That is why I said that "we need a process..." > We do not have it yet (I think... at least I do not know it either). > I think we were all just hoping people would take responsibility and > do the right things... but as we know that is how things fall through > the cracks. > > > > But the Liasons communication between ITU and CCAMP/MPLS has not > > > been going smoothly so far (even though we had good intentions). > > > Responses have not gone out in time (or in some cases at all). > > > > I'll take full responsibility for that. > > > W.r.t. CCAMP I will share some of the responsibility too. I should > also have kept a better eye on it. > > Bert > > Thanks, > > Kireeti. To be honest, I think there is a process. IETF recognizes individuals, not organizations. A liason may present a liason statement in an IETF meeting or send it to a WG (or other) mailing list but like any other type of organization the individual is recognized, not the organization. That same person is free to take impressions back to their organization. The IETF believes in running code and rough consensus. Too much standardization occurs without running code (and preferably also at least trial deployment) and too much gets standardized committee style and ends up not working (quite often protocols can't be deployed because they don't scale, often predicted but the standards body marched forward despite technical objections related to scaling). If the ITU wants to work that way fine. At least the IETF wants to make sure there are clear requirements before pursuing much effort toward standardization in advance of running and deployed code. The chng-proc draft clarifies this and puts procedure in place toward that end. It is also worth noting that if you have deployed code you have good evidence that there was a requirement and there should be empirical evicence related to the solution's ability to meet the requirement. Curtis Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 10:45:12 -0800 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA8370@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "'erosen@cisco.com'" , Loa Andersson Cc: Kireeti Kompella , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 13:44:35 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi, The conversation that's being stimulated from the draft gets to the crux of the issue I see with its current wording. The draft is being interpreted as simply describing the present IETF mode of operation. I didn't think that was supposed to be the intent. Eve -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com] Sent: Thursday, February 27, 2003 1:23 PM To: Loa Andersson Cc: Kireeti Kompella; Stephen Trowbridge; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt It seems to me that Loa's document simply describes how the IETF works. As such, I'm not sure it is even necessary. True, many people have noticed that the IETF is free to ignore the work of other standard organizations. True, the fact that a particular proposal is made by another standards organization does not even give the proposal any special weight in the IETF. I think these are good things, and the IETF should not make any changes in this respect. Hence I don't think Loa's draft (if it needs to exist) needs to change. Certainly the fact that some position is articulated in a "liaison statement" should not give it any special weight. The fact that some position is supported by "a threshold number of vendors and SPs" shouldn't give it any special weight either. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 10:42:21 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC97226B@nimbus> From: John Drake To: 'George Newsome' Cc: 'Kireeti Kompella' , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 10:41:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" George, I didn't attend. Thanks, John > -----Original Message----- > From: George Newsome [mailto:gnewsome@ieee.org] > Sent: Thursday, February 27, 2003 10:17 AM > To: John Drake > Cc: 'Kireeti Kompella'; Stephen Trowbridge; ccamp@ops.ietf.org; > mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > John Drake wrote: > > > > Snipped... > > > > Stephen Trowbridge asked what further information the IETF > requires. > > > > Dimitri and Kireeti answered the question in detail." > > > > > And the answer was ???? > > A pity that the detailed answer is apparently not minuted. > > George > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 10:35:04 -0800 Message-Id: <200302271822.h1RIMn56013326@sj-msg-core-1.cisco.com> To: Loa Andersson cc: Kireeti Kompella , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.2 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 27 Feb 2003 13:22:48 -0500 From: Eric Rosen It seems to me that Loa's document simply describes how the IETF works. As such, I'm not sure it is even necessary. True, many people have noticed that the IETF is free to ignore the work of other standard organizations. True, the fact that a particular proposal is made by another standards organization does not even give the proposal any special weight in the IETF. I think these are good things, and the IETF should not make any changes in this respect. Hence I don't think Loa's draft (if it needs to exist) needs to change. Certainly the fact that some position is articulated in a "liaison statement" should not give it any special weight. The fact that some position is supported by "a threshold number of vendors and SPs" shouldn't give it any special weight either. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 10:18:14 -0800 Message-ID: <3E5E55FF.4030809@ieee.org> Date: Thu, 27 Feb 2003 13:16:31 -0500 From: George Newsome User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: John Drake CC: 'Kireeti Kompella' , Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit John Drake wrote: > Snipped... > > Stephen Trowbridge asked what further information the IETF requires. > > Dimitri and Kireeti answered the question in detail." > And the answer was ???? A pity that the detailed answer is apparently not minuted. George Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 10:02:36 -0800 Message-ID: <9D42C6E086250248810DCADA39CE7EFC972269@nimbus> From: John Drake To: 'Kireeti Kompella' , Stephen Trowbridge Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 10:01:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Kireeti, Extremely well reasoned and thoughtful. As I understand it, this document is intended to prevent the situation that just occured, in which the IETF published an RFC which detailed some changes to RSVP-TE (which had technical issues) without any review by the CCAMP or MPLS working groups, thereby explicitly appearing to endorse these changes. The minutes of the Yokohama CCAMP meeting (see below) seem to indicate that the CCAMP working group wanted to work on the ASON extensions, so I am still puzzled as to why the authors of the ASON draft decided, after the Yokohama meeting, to progress the draft as an informational RFC rather than as a normal working group draft. Thanks, John ============================================================================ ==================================== "Minute takers were volunteered (Josh Broch and Eric Gray) Snipped... Osama Aboul-Magd presented status on his draft on ASON extensions to CR-LDP. He asked if the WG would accept this as a WG draft. Kireeti pointed out that there is a meta discussion on the issue of progressing both CR-LDP and RSVP-TE in the MPLS working group tomorrow and suggested that the discussion should be taken to the mailing list after that has been addressed. Snipped... Dimitri Papadimitriou discussed work on ASON extensions to RSVP-TE. He asked if the WG believes this to be valuable work and should eventually be put forward to the ITU. Kireeti talked about the need to work out the relationship with the ITU on these issues. Choy asked why the work does nt include call/connection information. Kireeti said that the functional specification should first capture the solution independent requirements. Stephen Trowbridge asked what further information the IETF requires. Dimitri and Kireeti answered the question in detail." ============================================================================ ==================================== > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Thursday, February 27, 2003 12:57 AM > To: Stephen Trowbridge > Cc: ccamp@ops.ietf.org; mpls@UU.NET > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Hi Steve, > > On Wed, 26 Feb 2003, Stephen Trowbridge wrote: > > > However, as Deborah, Kireeti, and Scott > > have observed, the way it is written it seems to hinder rather than > > help the process of collaborating with other Standards Developement > > Organizations(SDOs) > > If this is the impression that my comments gave, I must have used the > wrong words. The GMPLS change document is intended to help other SDOs > understand the change process, and as such *help* collaboration. > > > and doesn't provide a good way to deal with and respond > > to liaison statements, which is the avenue by which many of these > > requests will arrive from other SDOs. > > This I agree with. But as Loa pointed out, it was not the intent of > the gmpls change doc to address this issue -- that is the domain of > a different document; and as several people have pointed out by now, > the change document is very specific (a small set of WGs), whereas > a liaison document should probably be much broader (IETF-wide). > > > The document as > > written creates impediments to the ability to apply, and extend as > > necessary, these protocols to new problem spaces. > > I don't see this at all. The IETF does have processes, for example, > RFC 2026. So (I assume) does the ITU. Most would consider writing > down a process for change, especially with the intent of maintaining > architectural soundness, a Good Thing, not an impediment. Process > does on occasion slow things down. Sometimes that is laudable -- > deliberation vs haste; sometimes that is a price one pays in return > for avoiding chaos. It takes longer for me to hang up my > clothes rather > than throw them on the floor -- but I opt to hang them up. > > > As noted, biggest flaw seems to be the way in which the > document deals > > with new applications or requirements identified by > external standards > > organizations. In addition to not recognizing that this > information may > > come to IETF via liaison statements, > > Let's take these one at a time. A liaison statement (LS) has not been > heretofore a replacement for an ID. A LS of the form "we invite you > to take part in such-and-such meeting" or "we would like to bring to > your attention such-and-such work" are fine uses (in my opinion) for > LSs. However, if an SDO thinks that x, y and z are requirements for > protocol foo, communicating this solely via a liaison statement is not > (again, IMO) the right approach. Requirements need to be discussed, > possibly modified, and captured in some permanent form. There is a > well established process in the IETF for that; introducing a new > vehicle for that process is neither necessary nor appropriate, at > least without a revision of 2026 that states this. It is not the > intent of the gmpls change process to at the same time change the > IETF's process and to update 2026. > > > the document seems not to consider > > the fact that there may be a valid application that is > outside of the > > scope of IETF (and in the scope of another standards development > > organization) to which the (G)MPLS protocols may be applied, and for > > which the (G)MPLS protocols may require extension. > > Not at all true. > > > By insisting that > > every possible extension be done internally in IETF, the IETF either > > (1) Extends the scope of its work without bound; or (2) Needlessly > > restricts the application of its protocols. Neither one of these is > > good for IETF or for the Standards Development community at large. > > The reason for insisting that extensions be done in the IETF is: > (a) the IETF developed the protocols, knows them best, and knows the > bigger architectural picture in which they fit. A good example > is the (unnecessary) deprecation of RSVP messages in a recent RFC. > (b) when all is said and done, the IETF does own the protocols. > > It is instructive to harken back to how CCAMP took extraordinary pains > *not* to change the SDH spec, nor even to give the impression > of such a > change. There was a clear recognition that SDH "belonged" to the ITU, > and when representatives felt that there was "intrusion", even if > unintended, CCAMP stepped back. There were two reasons for this: we > recognized that we (as an SDO, not as individuals) didn't have the > expertise; and we wanted to maintain cordial relations. > > > One reality that this draft fails to recognize is that, > while IETF may > > be able to say "no" to standardizing something proposed by > an individual, > > it does not have the ability (or the right) to say "no" to something > > proposed by another Standards Development Organization. As > a practical > > matter, the IETF is not the only place where something can > be standardized. > > I agree that the IETF cannot stop other SDOs from extending its > protocols; it can (I believe) insist that such modified > protocols use a > new name to call out the differences. > > However, the problem that the change document addresses is not what > other SDOs are doing, but what the IETF should be doing. As far as > other SDOs are concerned, they can decide on their own to abide by > the IETF's rules if they want, or to forge ahead on their own, at > the risk (which they may consider worthwhile) of marring > their relations > with the IETF. > > > If the IETF creates impediments to applying IETF protocols to > > the application space of another standards development organization, > > there is really nothing that the IETF can do to prevent > that the other > > organization standardizes something themselves. The result > would tend > > to be a proliferation of (G)MPLS "like" protocols instead > of a coherent > > suite of protocols with broad applicability. This result > would not be > > good for the IETF or the industry in general. > > There is already a proliferation of GMPLS like protocols. The OIF > has its own; the ITU is developing its own. It is not the intention > of the change document to stop this, nor to create impediments. But > there is the (fond!) hope that with such a change document in place, > other SDOs will say -- "hey, instead of changing the > protocols ourselves, > there is this process whereby we can take our requirements to the IETF > and get the experts who really know that protocol to change it to meet > our needs." > > > A better approach would be for the IETF to PROMOTE the use of its > > protocols for new applications > > Far be it for me to say what the IETF should or should not > do. However, > I personally don't think the IETF should promote its > protocols. In the > final analysis, the IETF is concerned with running (and promoting) the > Internet. Any protocols it designs should have that as the end goal. > > > and, when another Standards Development > > Organization wishes to apply (G)MPLS protocols to an > application domain > > outside of the scope of IETF, that IETF will (1) assist > with the development > > of any necessary extensions; and (2) to facilitate documentation of > > such new applications and extensions in a central place (e.g., by > > informational RFC, even for extensions that are developed outside of > > IETF) and to insure that code points are assigned in a > coherent manner > > through IANA to avoid collisions where different extensions may use > > the same code points to indicate different things. > > If the IETF is convinced that such extensions will in some way help > to achieve its own goals AND will not hurt the protocol, the IETF can > and should undertake the activity. If the extensions do not match > the IETF's goals, but they don't hurt the protocol, there should be > a way (such as Bob Braden's SPIFFY_ITU_... idea) for the IETF to > yield the floor to some other SDO. > > > The difference in flavor for what I am proposing is that IETF should > > try to position itself as a Clearinghouse for (G)MPLS > protocol extensions > > rather than as a Gatekeeper for (G)MPLS protcol extensions. > > The Gatekeeper function is for the case where the said extensions do > hurt the protocol (in the eyes of the IETF). This is where the SDO > can decide, as you point out, that it can do it on its own, but > changes the name of the protocol so that innocent bystanders can tell > the difference. > > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 09:33:19 -0800 Message-ID: <3E5E4BA9.8080301@ieee.org> Date: Thu, 27 Feb 2003 12:32:25 -0500 From: George Newsome User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 MIME-Version: 1.0 To: Malcolm Betts , Stephen Trowbridge CC: 'Loa Andersson' , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Malcolm Betts wrote: > Loa, the from the outside looking in the liaison process and the change > process are closely coupled. The liaison process is described in ITU-T > Recommendation A.4 and A.5 and in RFC 3356. > ......... It seems to me that Malcolm and Monica's remarks, and Steve's suggestions to improve the usefulness of the document are all heading in the right direction. I would have thought that the IETF understands very well how to make changes to its documents, so a new document discussing that aspect seems to have little use. On the other hand, Loa suggested earlier that the liaison process is not well understood, so a document describing how the interaction between SDO's can work seems very relevant. It is difficult or impossible to separate out the fact that other SDO's are not individuals, and that formal communications (liaison's) are how other SDO's communicate with each other. Steve's suggested changes address both of these facts, and are thus helpful. George Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 09:32:23 -0800 Message-ID: <2135200C183FD5119588009027DE572302836D53@webdev-owa.oni.com> From: "Ong, Lyndon" To: 'Loa Andersson' , "Brungard, Deborah A, ALABS" Cc: "Wijnen, Bert (Bert)" , Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 09:31:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi, Can I ask a clarifying question regarding liaisons? The issue revolves around making extensions to GMPLS. Is it the view that such extensions must be generated through Internet Drafts, and cannot be through liaisons? It sounds like people may be assuming that liaisons are always providing background information or requesting information, when on occasion a liaison may be requesting a change or action. BTW, regarding responses to liaisons, the A-D may or may not be the proper source for a response, but the knowledge for putting together the response would typically reside within a particular WG, I believe. One problem is that you don't have the time within an IETF meeting to assign a "stuckie" (to use the new term) to write a response ;o) Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 09:25:58 -0800 Date: Thu, 27 Feb 2003 12:25:16 -0500 From: Scott W Brim To: Loa Andersson Cc: "Brungard, Deborah A, ALABS" , "Wijnen, Bert (Bert)" , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030227172516.GJ2120@sbrim-w2k> Mail-Followup-To: Scott W Brim , Loa Andersson , "Brungard, Deborah A, ALABS" , "Wijnen, Bert (Bert)" , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Loa, On Thu, Feb 27, 2003 05:58:40PM +0100, Loa Andersson allegedly wrote: > It needs to be understood that the internal IETF process is specified > for IDs, and in some way we need bridge that gap. IETF and its working > groups modifies IDs, and I don't think it is good idea to start > modifying liasions from other SDOs. But > Brungard, Deborah A, ALABS wrote: > >One comment on all of this from an ITU/T1X1 history, it is difficult > >to say apriori how a liaison will be processed. We do not have such a > >process either. Several ways exist to respond: > >1. simple thank you for the information > >2. here's the answer/clarification based on current work > >3. for a quick answer, at the meeting, have a breakout group to > > address a proposal > >4. for new work, send a response saying we invite contributions to > > our future meetings to progress > > - if no contributions, not anything is done (yes we have done this > > too) > > - at the next meeting, send several proposals to the other group > > for their review There is no incompatibility. Among a rich set of possible responses, bullet 4 covers what you were looking for above. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 09:22:55 -0800 Message-ID: <61B49BC6DA0DDE40957FB499E1835E3705FA8366@nj7460exch010u.ho.lucent.com> From: "Varma, Eve L (Eve)" To: "Betts, Malcolm [SKY:Q870:EXCH]" , Loa Andersson Cc: Stephen Trowbridge , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 12:21:57 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE84.BB433B30" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DE84.BB433B30 Content-Type: text/plain; charset="iso-8859-1" Just putting in my two cents. I'd like to support aspects of the liaison process being included in the draft. Given the close coupling between the change and liaison processes, and the issues that triggered generation of the draft, I believe we should bite the bullet and work to establish a cohesive process now. It will be well worth the effort. In my view, not expending the time now will result in far more time spent later. I'd also like to express support for the proposed revisions provided by Steve Trowbridge, as I believe they increase the value of the draft by adding necessary clarifications and promoting a cooperative spirit to the entire endeavor. Eve Varma -----Original Message----- From: Malcolm Betts [mailto:betts01@nortelnetworks.com] Sent: Thursday, February 27, 2003 8:11 AM To: 'Loa Andersson' Cc: Stephen Trowbridge; Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Loa, the from the outside looking in the liaison process and the change process are closely coupled. The liaison process is described in ITU-T Recommendation A.4 and A.5 and in RFC 3356. The coupling occurs because the ITU uses the agreed liaison process to communicate requests to modify IETF protocols based on requirements agreed by the members of the Study Group (that originated the liaison). The change process being proposed requires that this official request from a SDO is converted into an individuals ID. The level of agreement in the SDO is therefore obscured, this process appears to be in conflict with RFC 3356. The problem is particularly acute when the requirements are to enable (or enhance) the management of a non IP network to support a non IP client. If my understanding of the draft is correct such requests would be rejected by the IETF. It is clearly beneficial to the industry if the basic IETF protocols can be extended to address such applications. The IETF plays a key role in ensuring that the integrity of the base protocols is not compromised. Malcolm Betts Phone: +1 613 763 7860 (ESN 393) FAX: +1 613 763 6608 (ESN 393) email: betts01@nortelnetworks.com -----Original Message----- From: Loa Andersson [ mailto:loa@pi.se ] Sent: Thursday, February 27, 2003 7:33 AM To: Kireeti Kompella Cc: Stephen Trowbridge; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt I think I've clearly pointed out the limited scope of the change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation with other SDOs. /Loa ------_=_NextPart_001_01C2DE84.BB433B30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Just=20 putting in my two cents.  I'd like to support aspects of the = liaison=20 process being included in the draft.  Given the close coupling = between=20 the
change=20 and liaison processes, and the issues that triggered = generation of=20 the draft, I believe we should bite the bullet and work to establish a = cohesive=20 process now.
It=20 will be well worth the effort.  In my view, not = expending=20 the time now will result in far more time spent=20 later.
 
I'd=20 also like to express support for the proposed = revisions provided by=20 Steve Trowbridge,  as I believe they increase the value = of the=20 draft by adding necessary clarifications and promoting a = cooperative spirit=20 to the entire endeavor.
 
Eve=20 Varma
 
=  

-----Original=20 Message-----
From: = Malcolm=20 Betts [mailto:betts01@nortelnetworks.com]
Sent: Thursday, February 27, = 2003 8:11=20 AM
To: 'Loa=20 Andersson'
Cc: = Stephen=20 Trowbridge; Kireeti Kompella; ccamp@ops.ietf.org; = mpls@UU.NET
Subject: RE: I-D=20 ACTION:draft-andersson-mpls-g-chng-proc-00.txt

 

Loa, the from the outside = looking in the=20 liaison process and the change process are closely coupled.  The = liaison=20 process is described in ITU-T Recommendation A.4 and A.5 and in RFC=20 3356. 

The coupling occurs because = the ITU uses=20 the agreed liaison process to communicate requests to modify IETF = protocols=20 based on requirements agreed by the members of the Study Group (that=20 originated the liaison).  The change process being proposed = requires that=20 this official request from a SDO is converted into an individuals = ID. =20 The level of agreement in the SDO is therefore obscured, this process = appears=20 to be in conflict with RFC 3356.  The problem is particularly = acute when=20 the requirements are to enable (or enhance) the management of a non = IP network=20 to support a non IP client.  If my understanding of the draft is = correct=20 such requests would be rejected by the IETF.

It is clearly beneficial to = the industry=20 if the basic IETF protocols can be extended to address such=20 applications.  The IETF plays a key role in ensuring that the = integrity=20 of the base protocols is not compromised.

Malcolm = Betts

Phone: +1 613 763 7860 (ESN=20 393)=20
FAX:   +1 613 763 = 6608 (ESN=20 393)=20
email:=20 betts01@nortelnetworks.com

 

-----Original=20 Message-----=20
From: Loa Andersson [mailto:loa@pi.se]
Sent: = Thursday, February=20 27, 2003 7:33 AM=20
To: Kireeti = Kompella
Cc: Stephen = Trowbridge;=20 ccamp@ops.ietf.org; mpls@UU.NET
Subject: Re: I-D=20 ACTION:draft-andersson-mpls-g-chng-proc-00.txt
<snip>

I think I've clearly pointed = out the=20 limited scope of the change process, recognized that there is a = orthogonal=20 problem on how we treats liasions coming into the ietf, that the = liasion=20 process needs to be documented, and that we will add text to address = the=20 limited intersection of the change-process and liasion process in = order to=20 promote the cooperation with other SDOs.

/Loa

<snip>

------_=_NextPart_001_01C2DE84.BB433B30-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 09:05:29 -0800 Message-ID: <3E5E43C0.1040406@pi.se> Date: Thu, 27 Feb 2003 17:58:40 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 MIME-Version: 1.0 To: "Brungard, Deborah A, ALABS" CC: "Wijnen, Bert (Bert)" , Kireeti Kompella , Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Deborah, I suggested earlier that we describe (short) in the draft how we will handle liasions comeing into the IETF with request for changes or requirments related to the (g)mpls protocols. It needs to be understood that the internal IETF process is specified for IDs, and in some way we need bridge that gap. IETF and its working groups modifies IDs, and I don't think it is good idea to start modifying liasions from other SDOs. That we define the liasion process so it becoes crips and clear, and if when we are doing find that it has an impact on the change process, we updte or re-organize the the documents at that time. Would that work? I guess that the answer is - yes, but only as much (little) as needed. /Loa Brungard, Deborah A, ALABS wrote: >Maybe lets go back to my hopefully simple question, will the liaison process be included in this draft or not? I (thought) the answer was no. Maybe best to clarify. And not that it is not important, all the mail agrees it is important. Then we can work from this draft with comments, recognizing the liaison process will be separate, e.g. where the draft discusses other sdos, we can add text to clarify. > >One comment on all of this from an ITU/T1X1 history, it is difficult to say apriori how a liaison will be processed. We do not have such a process either. Several ways exist to respond: >1. simple thank you for the information >2. here's the answer/clarification based on current work >3. for a quick answer, at the meeting, have a breakout group to address a proposal >4. for new work, send a response saying we invite contributions to our future meetings to progress > - if no contributions, not anything is done (yes we have done this too) > - at the next meeting, send several proposals to the other group for their review > >I had understood this draft as including option 4. Other mails are raising the concern, as in the past, if no response to the other sdo, the other sdo can not determine the status of the work. That can be part of the liaison process. > >Let's first clarify, do we want this draft to include the liaison process or should we do it separate (in parallel?)? > >Deborah > > > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Thursday, February 27, 2003 10:47 AM >To: Kireeti Kompella; Wijnen, Bert (Bert) >Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > >Inline > > > >>-----Original Message----- >>From: Kireeti Kompella [mailto:kireeti@juniper.net] >>Sent: donderdag 27 februari 2003 10:09 >>To: Wijnen, Bert (Bert) >>Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET >>Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt >> >> >>Hi Bert, >> >>On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: >> >> >> >>>No of course NOT. Many Liasons will want an answer. >>>So we need a process to follow up and to track if a timely >>>response has been (or will be) send. >>> >>> >>Is the IETF process for replying to liaison statements (and of >>generating them) written down, say in some RFC? If so, could you >>send me a pointer? >> >> >> >Unfortunately, I don't think the process for that has been defined. >That is why I said that "we need a process..." >We do not have it yet (I think... at least I do not know it either). >I think we were all just hoping people would take responsibility and >do the right things... but as we know that is how things fall through >the cracks. > > > >>>But the Liasons communication between ITU and CCAMP/MPLS has not >>>been going smoothly so far (even though we had good intentions). >>>Responses have not gone out in time (or in some cases at all). >>> >>> >>I'll take full responsibility for that. >> >> >> >W.r.t. CCAMP I will share some of the responsibility too. I should >also have kept a better eye on it. > >Bert > > >>Thanks, >>Kireeti. >> >> >> > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 08:17:35 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 11:14:28 -0500 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA616@OCCLUST02EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLeeAn82m7VqakWTYGHUmbZbkGt6wAACQAw From: "Brungard, Deborah A, ALABS" To: "Wijnen, Bert (Bert)" , "Kireeti Kompella" Cc: "Scott W Brim" , , Maybe lets go back to my hopefully simple question, will the liaison = process be included in this draft or not? I (thought) the answer was no. = Maybe best to clarify. And not that it is not important, all the mail = agrees it is important. Then we can work from this draft with comments, = recognizing the liaison process will be separate, e.g. where the draft = discusses other sdos, we can add text to clarify. One comment on all of this from an ITU/T1X1 history, it is difficult to = say apriori how a liaison will be processed. We do not have such a = process either. Several ways exist to respond: 1. simple thank you for the information 2. here's the answer/clarification based on current work 3. for a quick answer, at the meeting, have a breakout group to address = a proposal 4. for new work, send a response saying we invite contributions to our = future meetings to progress - if no contributions, not anything is done (yes we have done this = too) - at the next meeting, send several proposals to the other group for = their review I had understood this draft as including option 4. Other mails are = raising the concern, as in the past, if no response to the other sdo, = the other sdo can not determine the status of the work. That can be part = of the liaison process. Let's first clarify, do we want this draft to include the liaison = process or should we do it separate (in parallel?)? Deborah -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, February 27, 2003 10:47 AM To: Kireeti Kompella; Wijnen, Bert (Bert) Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Inline > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: donderdag 27 februari 2003 10:09 > To: Wijnen, Bert (Bert) > Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET > Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt >=20 >=20 > Hi Bert, >=20 > On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: >=20 > > No of course NOT. Many Liasons will want an answer. > > So we need a process to follow up and to track if a timely > > response has been (or will be) send. >=20 > Is the IETF process for replying to liaison statements (and of > generating them) written down, say in some RFC? If so, could you > send me a pointer? >=20 Unfortunately, I don't think the process for that has been defined. That is why I said that "we need a process..." We do not have it yet (I think... at least I do not know it either). I think we were all just hoping people would take responsibility and do the right things... but as we know that is how things fall through the cracks. > > But the Liasons communication between ITU and CCAMP/MPLS has not > > been going smoothly so far (even though we had good intentions). > > Responses have not gone out in time (or in some cases at all). >=20 > I'll take full responsibility for that. >=20 W.r.t. CCAMP I will share some of the responsibility too. I should=20 also have kept a better eye on it. Bert > Thanks, > Kireeti. >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 07:48:44 -0800 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501062F74@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kireeti Kompella , "Wijnen, Bert (Bert)" Cc: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 16:46:56 +0100 MIME-Version: 1.0 Content-Type: text/plain Inline > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: donderdag 27 februari 2003 10:09 > To: Wijnen, Bert (Bert) > Cc: Scott W Brim; ccamp@ops.ietf.org; mpls@UU.NET > Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt > > > Hi Bert, > > On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: > > > No of course NOT. Many Liasons will want an answer. > > So we need a process to follow up and to track if a timely > > response has been (or will be) send. > > Is the IETF process for replying to liaison statements (and of > generating them) written down, say in some RFC? If so, could you > send me a pointer? > Unfortunately, I don't think the process for that has been defined. That is why I said that "we need a process..." We do not have it yet (I think... at least I do not know it either). I think we were all just hoping people would take responsibility and do the right things... but as we know that is how things fall through the cracks. > > But the Liasons communication between ITU and CCAMP/MPLS has not > > been going smoothly so far (even though we had good intentions). > > Responses have not gone out in time (or in some cases at all). > > I'll take full responsibility for that. > W.r.t. CCAMP I will share some of the responsibility too. I should also have kept a better eye on it. Bert > Thanks, > Kireeti. > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 05:23:23 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE63.4810FA95" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 08:22:31 -0500 Message-ID: <35BD167AAD17F34F84B265D79518556704072EC0@OCCLUST03EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLeYgoQS2XagnBvREmiUN3RLzR0/wAALulw From: "Lazer, Monica A, ALABS" To: "Malcolm Betts" , "Loa Andersson" Cc: "Stephen Trowbridge" , "Kireeti Kompella" , , This is a multi-part message in MIME format. ------_=_NextPart_001_01C2DE63.4810FA95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Loa, Kireeti, I agree with Malcolm.=20 Since this draft proposes a process change specifically dealing with requirements and problem statements, and since ITU uses the liaison process for this reason, the liaison process is very relevant to the changes proposed in this draft, and it is not an orthogonal problem. =20 =20 Monica A. Lazer Network Architecture and Reliability =20 908 234 8462 mlazer@att.com =20 -----Original Message----- From: Malcolm Betts [mailto:betts01@nortelnetworks.com] Sent: Thursday, February 27, 2003 8:11 AM To: 'Loa Andersson' Cc: Stephen Trowbridge; Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt =20 Loa, the from the outside looking in the liaison process and the change process are closely coupled. The liaison process is described in ITU-T Recommendation A.4 and A.5 and in RFC 3356. =20 The coupling occurs because the ITU uses the agreed liaison process to communicate requests to modify IETF protocols based on requirements agreed by the members of the Study Group (that originated the liaison). The change process being proposed requires that this official request from a SDO is converted into an individuals ID. The level of agreement in the SDO is therefore obscured, this process appears to be in conflict with RFC 3356. The problem is particularly acute when the requirements are to enable (or enhance) the management of a non IP network to support a non IP client. If my understanding of the draft is correct such requests would be rejected by the IETF. It is clearly beneficial to the industry if the basic IETF protocols can be extended to address such applications. The IETF plays a key role in ensuring that the integrity of the base protocols is not compromised. Malcolm Betts=20 Phone: +1 613 763 7860 (ESN 393)=20 FAX: +1 613 763 6608 (ESN 393)=20 email: betts01@nortelnetworks.com=20 =20 -----Original Message-----=20 From: Loa Andersson [ mailto:loa@pi.se]=20 Sent: Thursday, February 27, 2003 7:33 AM=20 To: Kireeti Kompella=20 Cc: Stephen Trowbridge; ccamp@ops.ietf.org; mpls@UU.NET=20 Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt=20 =20 I think I've clearly pointed out the limited scope of the change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation with other SDOs. /Loa=20 =20 ------_=_NextPart_001_01C2DE63.4810FA95 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Lo= a, Kireeti,

I = agree with Malcolm.

Si= nce this draft proposes a process change specifically dealing with requirements = and problem statements, and since ITU uses the liaison process for this = reason, the liaison process is very relevant to the changes proposed in this draft, = and it is not an orthogonal problem.

 

 

Monica A. = Lazer

Network Architecture and = Reliability

 

908 234 8462

mlazer@att.com

<= span class=3DEmailStyle16> 

-----Original Message-----
From: Malcolm Betts [mailto:betts01@nortelnetworks.com]
Sent: Thursday, February = 27, 2003 8:11 AM
To: 'Loa Andersson'
Cc: Stephen Trowbridge; = Kireeti Kompella; ccamp@ops.ietf.org; mpls@UU.NET
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

 

Loa, the from the outside looking in the liaison process = and the change process are closely coupled.  The liaison process is = described in ITU-T Recommendation A.4 and A.5 and in RFC 3356.  <= /p>

The coupling occurs because the ITU uses the agreed liaison process to communicate requests to modify IETF protocols based on = requirements agreed by the members of the Study Group (that originated the = liaison).  The change process being proposed requires that this official request = from a SDO is converted into an individuals ID.  The level of agreement in = the SDO is therefore obscured, this process appears to be in conflict with = RFC 3356.  The problem is particularly acute when the requirements are = to enable (or enhance) the management of a non IP network to support a non = IP client.  If my understanding of the draft is correct such requests = would be rejected by the IETF.

It is clearly beneficial to the industry if the basic IETF protocols can be extended to address such applications.  The IETF = plays a key role in ensuring that the integrity of the base protocols is not compromised.

Malcolm Betts

Phone: +1 613 763 7860 (ESN 393)
FAX:   +1 613 763 6608 (ESN = 393)
email: betts01@nortelnetworks.com

 <= /p>

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Thursday, February 27, 2003 7:33 = AM
To: Kireeti Kompella
Cc: Stephen Trowbridge; ccamp@ops.ietf.org; = mpls@UU.NET
Subject: Re: I-D = ACTION:draft-andersson-mpls-g-chng-proc-00.txt
<snip>

I think I've clearly pointed out the limited scope of the = change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be = documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation = with other SDOs.

/Loa <= /p>

<snip>

------_=_NextPart_001_01C2DE63.4810FA95-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 05:13:55 -0800 Date: Thu, 27 Feb 2003 08:13:36 -0500 From: Scott W Brim To: "Wijnen, Bert (Bert)" Cc: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030227131336.GK2572@sbrim-w2k> Mail-Followup-To: Scott W Brim , "Wijnen, Bert (Bert)" , ccamp@ops.ietf.org, mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i On Thu, Feb 27, 2003 01:22:01AM +0100, Bert allegedly wrote: > > Liaisons are an IETF-wide issue. > > > YES. > > > I think if we want to send a liaison to another group, the AD just sends > > e-mail, and archives it on ietf.org. That's just an administrative > > matter, nothing we even need a draft for. > > > It is not always the AD who sends. It could be a WG. Or whole IETF. Liaisons can be *generated* anywhere, but should be *sent* through a predictable agent. Having the IETF Chair, or "the whole IETF", send a liaison is too general -- liaisons need to be more focused than that to be useful. Individual WGs could send individual liaisons but I believe the AD level would be better for the usual reasons, coordination, an integrative view, etc. > > Incoming liaisons take a little more policy but not much. We want them > > archived, so just saying "submit a draft" isn't good enough. I'm afraid > > we need to provide mailto:ietf-liaisons@ietf.org, and yet another folder > > on the web pages. All ADs get to hear about all incoming liaisons, and > > if they think it's appropriate for one of their WGs they forward it. > > Done? > > > No of course NOT. Many Liasons will want an answer. > So we need a process to follow up and to track if a timely > response has been (or will be) send. I do not believe any organization is obligated to reply to everything that requests a reply (just think about the spam you get). If the AD and/or one or more WGs find the liaison (and the idea of replying to it) interesting and useful, then they will reply. The process for keeping track of this is at the AD level. ..swb Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 05:11:57 -0800 Message-ID: <710197BD5AF9D4119E4400508BCFA13604381507@zcard04u.ca.nortel.com> From: "Malcolm Betts" To: "'Loa Andersson'" Cc: Stephen Trowbridge , Kireeti Kompella , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 08:10:41 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE61.A0E63C74" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DE61.A0E63C74 Content-Type: text/plain Loa, the from the outside looking in the liaison process and the change process are closely coupled. The liaison process is described in ITU-T Recommendation A.4 and A.5 and in RFC 3356. The coupling occurs because the ITU uses the agreed liaison process to communicate requests to modify IETF protocols based on requirements agreed by the members of the Study Group (that originated the liaison). The change process being proposed requires that this official request from a SDO is converted into an individuals ID. The level of agreement in the SDO is therefore obscured, this process appears to be in conflict with RFC 3356. The problem is particularly acute when the requirements are to enable (or enhance) the management of a non IP network to support a non IP client. If my understanding of the draft is correct such requests would be rejected by the IETF. It is clearly beneficial to the industry if the basic IETF protocols can be extended to address such applications. The IETF plays a key role in ensuring that the integrity of the base protocols is not compromised. Malcolm Betts Phone: +1 613 763 7860 (ESN 393) FAX: +1 613 763 6608 (ESN 393) email: betts01@nortelnetworks.com -----Original Message----- From: Loa Andersson [mailto:loa@pi.se] Sent: Thursday, February 27, 2003 7:33 AM To: Kireeti Kompella Cc: Stephen Trowbridge; ccamp@ops.ietf.org; mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt I think I've clearly pointed out the limited scope of the change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation with other SDOs. /Loa ------_=_NextPart_001_01C2DE61.A0E63C74 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

Loa, the from the outside looking in the liaison = process and the change process are closely coupled.  The liaison = process is described in ITU-T Recommendation A.4 and A.5 and in RFC = 3356. 

The coupling occurs because the ITU uses the agreed = liaison process to communicate requests to modify IETF protocols based = on requirements agreed by the members of the Study Group (that = originated the liaison).  The change process being proposed = requires that this official request from a SDO is converted into an = individuals ID.  The level of agreement in the SDO is therefore = obscured, this process appears to be in conflict with RFC 3356.  = The problem is particularly acute when the requirements are to enable = (or enhance) the management of a non IP network to support a non IP = client.  If my understanding of the draft is correct such requests = would be rejected by the IETF.

It is clearly beneficial to the industry if the basic = IETF protocols can be extended to address such applications.  The = IETF plays a key role in ensuring that the integrity of the base = protocols is not compromised.

Malcolm Betts

Phone: +1 613 763 7860 (ESN 393)
FAX:   +1 613 763 6608 (ESN 393)
email: betts01@nortelnetworks.com


-----Original Message-----
From: Loa Andersson [mailto:loa@pi.se]
Sent: Thursday, February 27, 2003 7:33 AM
To: Kireeti Kompella
Cc: Stephen Trowbridge; ccamp@ops.ietf.org; = mpls@UU.NET
Subject: Re: I-D = ACTION:draft-andersson-mpls-g-chng-proc-00.txt
<snip>

I think I've clearly pointed out the limited scope of = the change process, recognized that there is a orthogonal problem on = how we treats liasions coming into the ietf, that the liasion process = needs to be documented, and that we will add text to address the = limited intersection of the change-process and liasion process in order = to promote the cooperation with other SDOs.

/Loa

<snip>

------_=_NextPart_001_01C2DE61.A0E63C74-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 04:39:40 -0800 Message-ID: <3E5E0563.9060303@pi.se> Date: Thu, 27 Feb 2003 13:32:35 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 MIME-Version: 1.0 To: Kireeti Kompella CC: Stephen Trowbridge , ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kireeti, thanks you captured most of my points and said it possibly more clearly and more polite than I would have. I just want to strengthen one of the points a bit. Chapter 2 bullet 4 says clearly > 4 that the problem is real and that they would be solved with exten- > sions to the (G)MPLS protocols, but that this for some reason is > not best done within the IETF, but some other organization. The > IETF might in such a case come to an agreement with this organiza- > tion to specify the protocol extensions and that these will be > described in a ID sent to the IETF for review and eventually be > published as an RFC. > > > > How this could be contrued as trying to stop other organizations from extending and improving the IETF protocols escapes my imagination, we even offer to put our expertise in for eview and makes it possible to use the IETF as a vehicle for publication- Further in testing Stephen logic on "you are not alone" - if I came to the absurd conclusion that I wanted to use Q.931 for label distribution and I failed to convince ITU that this was a good idea, would then ITU accept that the IETF or any other SDO published an extension to Q.931? Those arguments cuts both ways! Last, the IETF standards process works with IDs and RFCs, that one working group (or a coupel of them) should start working with another type of document (liasions) in that process is ... It would also take us to the point where we need to do the same thing with the prefered document from other SDOs. "You are not alone!" How would ITU react if I started sending IDs to them? I think I've clearly pointed out the limited scope of the change process, recognized that there is a orthogonal problem on how we treats liasions coming into the ietf, that the liasion process needs to be documented, and that we will add text to address the limited intersection of the change-process and liasion process in order to promote the cooperation with other SDOs. /Loa Kireeti Kompella wrote: >Hi Steve, > >On Wed, 26 Feb 2003, Stephen Trowbridge wrote: > > > >>However, as Deborah, Kireeti, and Scott >>have observed, the way it is written it seems to hinder rather than >>help the process of collaborating with other Standards Developement >>Organizations(SDOs) >> >> > >If this is the impression that my comments gave, I must have used the >wrong words. The GMPLS change document is intended to help other SDOs >understand the change process, and as such *help* collaboration. > > > >>and doesn't provide a good way to deal with and respond >>to liaison statements, which is the avenue by which many of these >>requests will arrive from other SDOs. >> >> > >This I agree with. But as Loa pointed out, it was not the intent of >the gmpls change doc to address this issue -- that is the domain of >a different document; and as several people have pointed out by now, >the change document is very specific (a small set of WGs), whereas >a liaison document should probably be much broader (IETF-wide). > > > >>The document as >>written creates impediments to the ability to apply, and extend as >>necessary, these protocols to new problem spaces. >> >> > >I don't see this at all. The IETF does have processes, for example, >RFC 2026. So (I assume) does the ITU. Most would consider writing >down a process for change, especially with the intent of maintaining >architectural soundness, a Good Thing, not an impediment. Process >does on occasion slow things down. Sometimes that is laudable -- >deliberation vs haste; sometimes that is a price one pays in return >for avoiding chaos. It takes longer for me to hang up my clothes rather >than throw them on the floor -- but I opt to hang them up. > > > >>As noted, biggest flaw seems to be the way in which the document deals >>with new applications or requirements identified by external standards >>organizations. In addition to not recognizing that this information may >>come to IETF via liaison statements, >> >> > >Let's take these one at a time. A liaison statement (LS) has not been >heretofore a replacement for an ID. A LS of the form "we invite you >to take part in such-and-such meeting" or "we would like to bring to >your attention such-and-such work" are fine uses (in my opinion) for >LSs. However, if an SDO thinks that x, y and z are requirements for >protocol foo, communicating this solely via a liaison statement is not >(again, IMO) the right approach. Requirements need to be discussed, >possibly modified, and captured in some permanent form. There is a >well established process in the IETF for that; introducing a new >vehicle for that process is neither necessary nor appropriate, at >least without a revision of 2026 that states this. It is not the >intent of the gmpls change process to at the same time change the >IETF's process and to update 2026. > > > >>the document seems not to consider >>the fact that there may be a valid application that is outside of the >>scope of IETF (and in the scope of another standards development >>organization) to which the (G)MPLS protocols may be applied, and for >>which the (G)MPLS protocols may require extension. >> >> > >Not at all true. > > > >>By insisting that >>every possible extension be done internally in IETF, the IETF either >>(1) Extends the scope of its work without bound; or (2) Needlessly >>restricts the application of its protocols. Neither one of these is >>good for IETF or for the Standards Development community at large. >> >> > >The reason for insisting that extensions be done in the IETF is: >(a) the IETF developed the protocols, knows them best, and knows the > bigger architectural picture in which they fit. A good example > is the (unnecessary) deprecation of RSVP messages in a recent RFC. >(b) when all is said and done, the IETF does own the protocols. > >It is instructive to harken back to how CCAMP took extraordinary pains >*not* to change the SDH spec, nor even to give the impression of such a >change. There was a clear recognition that SDH "belonged" to the ITU, >and when representatives felt that there was "intrusion", even if >unintended, CCAMP stepped back. There were two reasons for this: we >recognized that we (as an SDO, not as individuals) didn't have the >expertise; and we wanted to maintain cordial relations. > > > >>One reality that this draft fails to recognize is that, while IETF may >>be able to say "no" to standardizing something proposed by an individual, >>it does not have the ability (or the right) to say "no" to something >>proposed by another Standards Development Organization. As a practical >>matter, the IETF is not the only place where something can be standardized. >> >> > >I agree that the IETF cannot stop other SDOs from extending its >protocols; it can (I believe) insist that such modified protocols use a >new name to call out the differences. > >However, the problem that the change document addresses is not what >other SDOs are doing, but what the IETF should be doing. As far as >other SDOs are concerned, they can decide on their own to abide by >the IETF's rules if they want, or to forge ahead on their own, at >the risk (which they may consider worthwhile) of marring their relations >with the IETF. > > > >>If the IETF creates impediments to applying IETF protocols to >>the application space of another standards development organization, >>there is really nothing that the IETF can do to prevent that the other >>organization standardizes something themselves. The result would tend >>to be a proliferation of (G)MPLS "like" protocols instead of a coherent >>suite of protocols with broad applicability. This result would not be >>good for the IETF or the industry in general. >> >> > >There is already a proliferation of GMPLS like protocols. The OIF >has its own; the ITU is developing its own. It is not the intention >of the change document to stop this, nor to create impediments. But >there is the (fond!) hope that with such a change document in place, >other SDOs will say -- "hey, instead of changing the protocols ourselves, >there is this process whereby we can take our requirements to the IETF >and get the experts who really know that protocol to change it to meet >our needs." > > > >>A better approach would be for the IETF to PROMOTE the use of its >>protocols for new applications >> >> > >Far be it for me to say what the IETF should or should not do. However, >I personally don't think the IETF should promote its protocols. In the >final analysis, the IETF is concerned with running (and promoting) the >Internet. Any protocols it designs should have that as the end goal. > > > >>and, when another Standards Development >>Organization wishes to apply (G)MPLS protocols to an application domain >>outside of the scope of IETF, that IETF will (1) assist with the development >>of any necessary extensions; and (2) to facilitate documentation of >>such new applications and extensions in a central place (e.g., by >>informational RFC, even for extensions that are developed outside of >>IETF) and to insure that code points are assigned in a coherent manner >>through IANA to avoid collisions where different extensions may use >>the same code points to indicate different things. >> >> > >If the IETF is convinced that such extensions will in some way help >to achieve its own goals AND will not hurt the protocol, the IETF can >and should undertake the activity. If the extensions do not match >the IETF's goals, but they don't hurt the protocol, there should be >a way (such as Bob Braden's SPIFFY_ITU_... idea) for the IETF to >yield the floor to some other SDO. > > > >>The difference in flavor for what I am proposing is that IETF should >>try to position itself as a Clearinghouse for (G)MPLS protocol extensions >>rather than as a Gatekeeper for (G)MPLS protcol extensions. >> >> > >The Gatekeeper function is for the case where the said extensions do >hurt the protocol (in the eyes of the IETF). This is where the SDO >can decide, as you point out, that it can do it on its own, but >changes the name of the protocol so that innocent bystanders can tell >the difference. > >Kireeti. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 01:10:11 -0800 Date: Thu, 27 Feb 2003 01:09:07 -0800 (PST) From: Kireeti Kompella To: "Wijnen, Bert (Bert)" cc: Scott W Brim , "" , "" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030227005743.X28581@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Bert, On Thu, 27 Feb 2003, Wijnen, Bert (Bert) wrote: > No of course NOT. Many Liasons will want an answer. > So we need a process to follow up and to track if a timely > response has been (or will be) send. Is the IETF process for replying to liaison statements (and of generating them) written down, say in some RFC? If so, could you send me a pointer? > But the Liasons communication between ITU and CCAMP/MPLS has not > been going smoothly so far (even though we had good intentions). > Responses have not gone out in time (or in some cases at all). I'll take full responsibility for that. Thanks, Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Feb 2003 01:02:07 -0800 Date: Thu, 27 Feb 2003 00:57:18 -0800 (PST) From: Kireeti Kompella To: Stephen Trowbridge cc: ccamp@ops.ietf.org, "" Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030226235603.Y28581@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Steve, On Wed, 26 Feb 2003, Stephen Trowbridge wrote: > However, as Deborah, Kireeti, and Scott > have observed, the way it is written it seems to hinder rather than > help the process of collaborating with other Standards Developement > Organizations(SDOs) If this is the impression that my comments gave, I must have used the wrong words. The GMPLS change document is intended to help other SDOs understand the change process, and as such *help* collaboration. > and doesn't provide a good way to deal with and respond > to liaison statements, which is the avenue by which many of these > requests will arrive from other SDOs. This I agree with. But as Loa pointed out, it was not the intent of the gmpls change doc to address this issue -- that is the domain of a different document; and as several people have pointed out by now, the change document is very specific (a small set of WGs), whereas a liaison document should probably be much broader (IETF-wide). > The document as > written creates impediments to the ability to apply, and extend as > necessary, these protocols to new problem spaces. I don't see this at all. The IETF does have processes, for example, RFC 2026. So (I assume) does the ITU. Most would consider writing down a process for change, especially with the intent of maintaining architectural soundness, a Good Thing, not an impediment. Process does on occasion slow things down. Sometimes that is laudable -- deliberation vs haste; sometimes that is a price one pays in return for avoiding chaos. It takes longer for me to hang up my clothes rather than throw them on the floor -- but I opt to hang them up. > As noted, biggest flaw seems to be the way in which the document deals > with new applications or requirements identified by external standards > organizations. In addition to not recognizing that this information may > come to IETF via liaison statements, Let's take these one at a time. A liaison statement (LS) has not been heretofore a replacement for an ID. A LS of the form "we invite you to take part in such-and-such meeting" or "we would like to bring to your attention such-and-such work" are fine uses (in my opinion) for LSs. However, if an SDO thinks that x, y and z are requirements for protocol foo, communicating this solely via a liaison statement is not (again, IMO) the right approach. Requirements need to be discussed, possibly modified, and captured in some permanent form. There is a well established process in the IETF for that; introducing a new vehicle for that process is neither necessary nor appropriate, at least without a revision of 2026 that states this. It is not the intent of the gmpls change process to at the same time change the IETF's process and to update 2026. > the document seems not to consider > the fact that there may be a valid application that is outside of the > scope of IETF (and in the scope of another standards development > organization) to which the (G)MPLS protocols may be applied, and for > which the (G)MPLS protocols may require extension. Not at all true. > By insisting that > every possible extension be done internally in IETF, the IETF either > (1) Extends the scope of its work without bound; or (2) Needlessly > restricts the application of its protocols. Neither one of these is > good for IETF or for the Standards Development community at large. The reason for insisting that extensions be done in the IETF is: (a) the IETF developed the protocols, knows them best, and knows the bigger architectural picture in which they fit. A good example is the (unnecessary) deprecation of RSVP messages in a recent RFC. (b) when all is said and done, the IETF does own the protocols. It is instructive to harken back to how CCAMP took extraordinary pains *not* to change the SDH spec, nor even to give the impression of such a change. There was a clear recognition that SDH "belonged" to the ITU, and when representatives felt that there was "intrusion", even if unintended, CCAMP stepped back. There were two reasons for this: we recognized that we (as an SDO, not as individuals) didn't have the expertise; and we wanted to maintain cordial relations. > One reality that this draft fails to recognize is that, while IETF may > be able to say "no" to standardizing something proposed by an individual, > it does not have the ability (or the right) to say "no" to something > proposed by another Standards Development Organization. As a practical > matter, the IETF is not the only place where something can be standardized. I agree that the IETF cannot stop other SDOs from extending its protocols; it can (I believe) insist that such modified protocols use a new name to call out the differences. However, the problem that the change document addresses is not what other SDOs are doing, but what the IETF should be doing. As far as other SDOs are concerned, they can decide on their own to abide by the IETF's rules if they want, or to forge ahead on their own, at the risk (which they may consider worthwhile) of marring their relations with the IETF. > If the IETF creates impediments to applying IETF protocols to > the application space of another standards development organization, > there is really nothing that the IETF can do to prevent that the other > organization standardizes something themselves. The result would tend > to be a proliferation of (G)MPLS "like" protocols instead of a coherent > suite of protocols with broad applicability. This result would not be > good for the IETF or the industry in general. There is already a proliferation of GMPLS like protocols. The OIF has its own; the ITU is developing its own. It is not the intention of the change document to stop this, nor to create impediments. But there is the (fond!) hope that with such a change document in place, other SDOs will say -- "hey, instead of changing the protocols ourselves, there is this process whereby we can take our requirements to the IETF and get the experts who really know that protocol to change it to meet our needs." > A better approach would be for the IETF to PROMOTE the use of its > protocols for new applications Far be it for me to say what the IETF should or should not do. However, I personally don't think the IETF should promote its protocols. In the final analysis, the IETF is concerned with running (and promoting) the Internet. Any protocols it designs should have that as the end goal. > and, when another Standards Development > Organization wishes to apply (G)MPLS protocols to an application domain > outside of the scope of IETF, that IETF will (1) assist with the development > of any necessary extensions; and (2) to facilitate documentation of > such new applications and extensions in a central place (e.g., by > informational RFC, even for extensions that are developed outside of > IETF) and to insure that code points are assigned in a coherent manner > through IANA to avoid collisions where different extensions may use > the same code points to indicate different things. If the IETF is convinced that such extensions will in some way help to achieve its own goals AND will not hurt the protocol, the IETF can and should undertake the activity. If the extensions do not match the IETF's goals, but they don't hurt the protocol, there should be a way (such as Bob Braden's SPIFFY_ITU_... idea) for the IETF to yield the floor to some other SDO. > The difference in flavor for what I am proposing is that IETF should > try to position itself as a Clearinghouse for (G)MPLS protocol extensions > rather than as a Gatekeeper for (G)MPLS protcol extensions. The Gatekeeper function is for the case where the said extensions do hurt the protocol (in the eyes of the IETF). This is where the SDO can decide, as you point out, that it can do it on its own, but changes the name of the protocol so that innocent bystanders can tell the difference. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Feb 2003 16:24:21 -0800 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501062D7E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Thu, 27 Feb 2003 01:22:01 +0100 MIME-Version: 1.0 Content-Type: text/plain > Liaisons are an IETF-wide issue. > YES. > I think if we want to send a liaison to another group, the AD just sends > e-mail, and archives it on ietf.org. That's just an administrative > matter, nothing we even need a draft for. > It is not always the AD who sends. It could be a WG. Or whole IETF. > Incoming liaisons take a little more policy but not much. We want them > archived, so just saying "submit a draft" isn't good enough. I'm afraid > we need to provide mailto:ietf-liaisons@ietf.org, and yet another folder > on the web pages. All ADs get to hear about all incoming liaisons, and > if they think it's appropriate for one of their WGs they forward it. > Done? > No of course NOT. Many Liasons will want an answer. So we need a process to follow up and to track if a timely response has been (or will be) send. > But this shouldn't be discussed on these lists anyway :-) > The general issue should not.... But the Liasons communication between ITU and CCAMP/MPLS has not been going smoothly so far (even though we had good intentions). Responses have not gone out in time (or in some cases at all). So in that respect some of it is relevant here. But possibly not to this specific document. Depends on how you look at things I guess. Bert Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Feb 2003 14:22:53 -0800 Message-ID: <3E5D3DE6.FB77D6B8@lucent.com> Date: Wed, 26 Feb 2003 15:21:26 -0700 From: Stephen Trowbridge Organization: Lucent Technologies MIME-Version: 1.0 To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, draft-andersson-mpls-g-chng-proc-00.txt seems to be addressed at a noble goal of bringing some order to new applications and extensions of the (G)MPLS protocols. However, as Deborah, Kireeti, and Scott have observed, the way it is written it seems to hinder rather than help the process of collaborating with other Standards Developement Organizations(SDOs) and doesn't provide a good way to deal with and respond to liaison statements, which is the avenue by which many of these requests will arrive from other SDOs. It speaks well for the protocols that others will find applications of them beyond the scope for which they were originally designed, and even outside the scope of areas addressed by the IETF. The document as written creates impediments to the ability to apply, and extend as necessary, these protocols to new problem spaces. I think it would be a far better goal to promote the reuse and widest application of these protocols, and to try to enable these new applications through a process that keeps some order to the applications and extensions of the protocols. As noted, biggest flaw seems to be the way in which the document deals with new applications or requirements identified by external standards organizations. In addition to not recognizing that this information may come to IETF via liaison statements, the document seems not to consider the fact that there may be a valid application that is outside of the scope of IETF (and in the scope of another standards development organization) to which the (G)MPLS protocols may be applied, and for which the (G)MPLS protocols may require extension. By insisting that every possible extension be done internally in IETF, the IETF either (1) Extends the scope of its work without bound; or (2) Needlessly restricts the application of its protocols. Neither one of these is good for IETF or for the Standards Development community at large. One reality that this draft fails to recognize is that, while IETF may be able to say "no" to standardizing something proposed by an individual, it does not have the ability (or the right) to say "no" to something proposed by another Standards Development Organization. As a practical matter, the IETF is not the only place where something can be standardized. If the IETF creates impediments to applying IETF protocols to the application space of another standards development organization, there is really nothing that the IETF can do to prevent that the other organization standardizes something themselves. The result would tend to be a proliferation of (G)MPLS "like" protocols instead of a coherent suite of protocols with broad applicability. This result would not be good for the IETF or the industry in general. A better approach would be for the IETF to PROMOTE the use of its protocols for new applications, and, when another Standards Development Organization wishes to apply (G)MPLS protocols to an application domain outside of the scope of IETF, that IETF will (1) assist with the development of any necessary extensions; and (2) to facilitate documentation of such new applications and extensions in a central place (e.g., by informational RFC, even for extensions that are developed outside of IETF) and to insure that code points are assigned in a coherent manner through IANA to avoid collisions where different extensions may use the same code points to indicate different things. I think that this could lay the groundwork for a much more constructive collaborative relationship between the IETF and other Standards Development Organizations than the draft as it stands. The difference in flavor for what I am proposing is that IETF should try to position itself as a Clearinghouse for (G)MPLS protocol extensions rather than as a Gatekeeper for (G)MPLS protcol extensions. What I have included below are some specific proposed text changes to try to change the flavor of the current draft to try to accomplish this. One final question regarding the applicability of this draft: The sub-IP area is still classified as a temporary area, and it seems that this particular procedure that will not be valid as written if remaining sub-IP work is returned to the "native" IETF areas. I don't have any specific suggestion as to how to solve this problem. My specific text proposals follow below. Regards, Steve Specific text proposals are as follows: ======================================================================= Abstract Original Text: This memo describes the process through which individuals, working groups and external standards bodies can influence the development of MPLS and GMPLS standards. With respect to standardization, this process means that (G)MPLS extensions and changes can be done through the IETF only, the body that created the (G)MPLS technology. The IETF will not publish a (G)MPLS technology extension RFC outside of the processes described here. _______________________________________________________________________ Proposed New Text: This memo describes the process through which individuals, working groups and external standards bodies can influence the development of MPLS and GMPLS standards. MPLS and GMPLS technology has attracted the interest of individuals and other Standards Development Organizations (SDOs) to apply and, where necessary, extend the protocols to cover problems and application spaces beyond those for which the protocols were originally designed. This speaks well for the architecture of the protocols that they can find such widespread application, and it is highly desirable to find ways to reuse and extend existing protocols rather than inventing new protocols to address these other problem areas. The challange going forward is to find ways to maximize the opportunities for reuse of these protocols, while trying to maintain architectural integrity of the protocols themselves. This draft outlines a proposal for such a process. ========================================================================== Terminology: Add: problem statement liaison a formal liaison statement from another Standards Development Organization (SDO) that initiates the discussion on extending the (G)MPLS protocols. This liaison will generally include a detailed problem description and a set of requirements that the (G)MPLS protocols need to meet to solve the problem. Such a liaison statement may contain a draft or approved document from the originating standards organization that characterizes the problem, indicating the level of agreement or approval that such a document has acheived in the originating organization. Supplement existing definition: requirement evaluating working group (rewg) - in the process descreibed below, the Working Group charged with the task of evaluating a certain problem statement and a certain set of requirements is termed the rewg. The focus of this group is somewhat different for the cases described here based on whether the problem statement and requirements came from an individual or another Standards Development Organization (SDO): in the individual case, the group may focus on assessing the validity of the requirements. In the case of a problem statement or requirements coming from an SDO, the other SDO may already have decided that the problem statement and requirements are valid for their application space, so the focus is directed more toward evaluation of whether IETF should be involved in developing the solution to that problem. ========================================================================== Section 2.1 Overview The existing diagram should be labeled "Procedure for initiation of New Applications and/or Extensions to (G)MPLS Protocols by Individuals". Even for individuals, there seems to be a missing "shortcut" from the document procedure. It seems to be assumed that we have already developed complete, perfect solutions to everything within the current charter, and not allow for the possibility that there is some missing element or overlooked requirement that may require a (G)MPLS extension that is within the current charter. This may require a line directly from the "review by wg chairs and ad's" box to the "IETF WG process" box to indicate the path taken where the problem statement is considered to fall entirely within the current charter. An additional diagram should be included labeled "Procedure for initiation of New Applications and/or Extensions to (G)MPLS protocols by other Standards Development Organizations (SDOs)" +---------+ |problem | |statement|<--------------------------------------------- Originating |liaison | SDO | +---------+ ^ | |discusson | | |on mailing | | Vlist | | +---------+ | | |review by| NACK | | +-|WG chairs|--------------+ | | | | and ADs | | | | | +---------+ | | | | |request IESG/IAB | | | | |to appoint rewg | | | | |and charter | | | | Vreq eval | +-------------------+ | | | +---------+ +-------->|liaison indicating | | | | |IESG/IAB | +-------->|out of scope or |----->| | | |decision | | +---->|interest for IETF | | | | +---------+ | | +-------------------+ | | | |rewg chartered | | | | | |to work on | | | | | Vproblem statement | | +-------------------+ | | | +---------+ NACK | | |liaison explaining | | | +>|rewg req |--------------+ | |how problem can be |----->| | +-| eval |----------------------->|solved with | | | | +---------+ no change reqd | |existing protocol | | | | | | | +-------------------+ | | | | | ACK | | | | | +------------------------------+ | | | V | | | | | +---------+ | v | | | |AD review| | +-------------------+ | | | +---------+ | |liaison accepting |------+ | | |request to IESG/ | |new work item | | | |IAB to approve | +-------------------+ | | Vcharter changes | ^ | | +---------+ NACK | | +------------+ | | |IESG/IAB |------------------+ | | Externally | | | |decision |----------------------------+ | Developed |<---+ | +---------+ ACK | Solution | | |wg chartered to +------------+ | |work solution | | V v | +---------+ +------------+ +-|IETF WG |----/ /----> stds track RFC | IANA code | |process | | points | +---------+ +------------+ ^ | | v solutions info RFC ID ========================================================================= Section 2.2 - Change title to: 2.2. Changes or Extensions to (G)MPLS Protocols Initiated by Individuals could also consider deleting item 4 of 2.2.4 since new section 2.3 is proposed to handle proposals from other SDOs. item 4 of 2.2.4 would only be valid in the case of an individual proposing a new problem to be solved by extending (G)MPLS protocols that IETF decides would be better addressed in another standards group. IETF could send a liaison to the other group with the suggested problem. This case may not be important enough to spell out explicitly in the document. ========================================================================= Add new section 2.3: 2.3. Changes or Extensions to (G)MPLS Protocols Initated at the request of another Standards Development Organization (SDO) 2.3.1. Initiating changes or extensions to (G)MPLS Protocols If a Standards Development Organization (SDO) wishes to apply the (G)MPLS protocols to a new application problem space, or sees a need to extend the (G)MPLS protocols to support the requirements for that new application, they may inform the IETF in one of the following manners: - An internet draft may be produced explaining the problem they are trying to solve and, if applicable, why the existing (G)MPLS protocols must be extended to address this problem. A note from the authors should be sent to the relevant mailing lists to initiate discussion. - An SDO (particularly those SDOs with whom ISOC/IETF have a formal relationship, e.g, see RFC 3356 or ITU-T A.sup3, and ITU-T Rec. A.4 regarding the relationship and communication method with ITU-T) may also be communicated via a formal liaison or communication statement. Such a statement is posted via a link from http://www.ietf.org/IESG/liaison.html and advertised by the iesg secretariat (who posts the incoming liaison) via the mailing list to initiate discussion. The mailing list to use should be Area mailing list and, if known, the WG mailing list for the WG that will likely be the requirement evaluation working group. In the case of discussion initiated from an incoming liaison statement, the liaison may be addressed to a specific Area or Working Group and notification should me made to the indicated mailing lists accordingly. Note concerning work initiated as a result of a liaison statement: Often a liaison statement that indicates that it is for action will indicated a deadline. The ADs and WG chairs should be diligent to make sure that a reply liaison is generated by the requested date, even if all that can be reported by that date is current status or a positive acknowledgement of receipt of the information. When the IETF chooses to undertake work as a result of an incoming liaison, regular reports of progress should be made via reply liaisons including anticipated time frames for completion of the work. In this way, the originating SDO can assess whether they can wait for an IETF solution or should pursue other avenues. 2.3.2. Problem statement review The MPLS and CCAMP working group chairs in conjunction with the Area Directors will determine if the particular problems raised in the Internet Draft or Incoming Liaison should be evaluated by a working group. This decision will be based on mailing list discussion. If the decision is that a requirement evaluation is warranted a decision is taken on which working group should act as requirement evaluation working group (rewg). In the case where the decision is that the IETF will proceed with further examination of these requirements, the originating SDO should be informed of this decision in a reply liaison. In the case where the decision is that the IETF will not proceed with further requirements evaluation, the "dustbin" which would have been the result for an individual submission is not an option for the case where the problem satement and requirements have already been accepted by another SDO. Since the other SDO has already accepted the problem statement and requirements, the likelihood is that this will lead to a standardized solution whether or not IETF chooses to be involved. At the same time, IETF has an interest in the long term integrity of the protocol, and can choose one of two options: - Even though the particular problem may be out of scope for IETF, participants may have insight which would assist in the solution to that problem. For the integrity of the protocol, it is certainly best if similar problems are solved in similar ways, and since the IETF should have the broadest view of all applications of the protocol, they are in a position to offer helpful advice to the other SDO about how to solve it. This information should be collected from the aforementioned email discussion and sent to the other SDO in a reply liaison. - The IETF is not in a position to offer any advice or insight as to how the problem can be solved. In this case, the IETF should indicate to the other SDO via a reply liaison that the IETF cannot help them with the problem, and it is up to the other SDO to define any solution. In either of case, the reply liaison to the originating SDO should encourage them to document their additional application or protocol extension via an informational RFC, (to keep the most complete possible library of extensions in one place), and to have any protocol code points assigned via IANA to insure that there are no cases where the same protocol code points might mean different things in the context of different extensions developed by different SDOs. This documentation would also enable the IETF to have a repository of extensions that would enable it and others to assess relationships between extensions. Any two extensions might: - be complementary and be usable at the same time - co-exist at the same time but it would make sense to only use one or the other at a time - not co-exist in an implementation but share a common base 2.3.3. Charter update If the chairs and the ADs both feel that the particular problems should be added to the MPLS or the CCAMP Working Group charter the ADs will propose specific charter modificiations for the Working Group to the IESG and the IAB. If the IESG and IAB approve of the charter changes the Working Group can then update its charter and start the work to study the requirements and the problems described in the Liaison statement. 2.3.4. Problem statement study The rewg will study the problem statement liaison statement and based on the evaluation, generate a response to the originating SDO and, if further work is to be undertaken within IETF, make such a recommendation to the IESG/IAB. The recommendation may be: 1 that no extensions to the (G)MPLS protocols are needed since the problem can be solved by the protocols as they exist. In this case, the WG chairs shall coordinate generating a liaison statement back to the originating SDO explaining how their problem can be solved with the current protocols. 2 that there is no interest in extending this protocol in IETF. Note that in the individual submission case (section 2.2.4) IETF is in the position to decide not to continue the work. However, in the case of work initiated due to a liaison from another SDO, the other SDO has already decided that there is a problem for which a standardized solution should be pursued. If IETF decides at this point not to pursue a standardized solution to the problem proposed by the incoming liaisons, a reply liaison is needed at this point with the same information content as discussed in section 2.3.2 if the ADs and WG chairs had decided not to pursue a standardized solution within IETF. In cases 1 and 2, IETF will not publish a standards track RFC to address the problem. However, should the originating SDO standardize its own solution, IETF will facilitate documenting that extension via an informational RFC and assignment of code points via IANA so that there is no conflict between this extension and those that may arise from other sources. 3 that the problem is of interest to IETF and the IETF is interested in developing extensions to the (G)MPLS protocols to address the problem. If the problem falls within the current charter, the normal WG process can be followed at this point. A reply liaison should be generated to the originating SDO indicating IETFs intent to accept the work and pursue a solution. If the problem requires extensions to the charter of the appropriate working group and the ADs agree, the proposal will be brought before the IESG and the IAB. If the IESG (with IAB advice) agrees that the task should be added to that particular charter then the rewg can work on it with the aim of adopting a final set of requirements to be forwarded to the working group that will handle the specification of the protocol changes. If the ADs or IESG/IAB do not agree to the charter extensions, a reply liaison should be sent to the originating SDO as in item 2 above. If a charter revision is agreed, a liaison should be sent to the originating SDO informing them of the revised charter and the intent to pursue the work. The rewg will study and clarify the requirements, merging them with others if warranted. The resulting requirements should be verified with the originating SDO via liaison, or other method is appropriate for that SDO. With concurrence from the originating SDO, the result is published as a requirements RFC. When the IESG approves publication of the requirements RFC it will add it as a new task to the protocol specifying Working Group charter. The protocol specifying working group will then develop the modifications or extensions to the (G)MPLS protocols needed to fulfil the requirements. In the case that the originating liaison has indicated any work or progress in the originating SDO to develop a protocol solution, that work shall be taken into account by the protocol specifying working group. To the extent that sound decisions have been made by the originating SDO, this should be used as the basis for the work in IETF. If errors are found, these shall be brought to the attention of the originating SDO via a liaison statement. Every effort shall be made to make sure that either the protocol is developed in one place, or the results are aligned if two specifications cannot be avoided. ======================================================================== Section 4 (obviously): Add: RFC 3471 RFC 3472 RFC 3473 RFC 3477 RFC 3478 RFC 3479 RFC 3480 ======================================================================== References Add: [RFC3356] Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines. G. Fishman, S. Bradner. August 2002. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Feb 2003 12:54:32 -0800 Date: Wed, 26 Feb 2003 15:53:13 -0500 From: Scott W Brim To: ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030226205313.GS2604@sbrim-w2k> Mail-Followup-To: Scott W Brim , ccamp@ops.ietf.org, mpls@UU.NET Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i On Wed, Feb 26, 2003 08:05:35PM +0100, Loa Andersson allegedly wrote: > We need to document the (g)mpls-change process, most of this is in the > current draft. The concerns I've seen so far is on how and what could > be accepted as input to the process, that should be easily solvable. > > We need to doucment the ietf way of responding to liasions. > > It is my immediate reaction that this do not really belong in the same > document, if for no other reasons, at least for practical reasons. If > there is a strong motive to put them in the same document, I can live > with that. They don't. The change process is specific to a particular protocol group. Liaisons are an IETF-wide issue. I think if we want to send a liaison to another group, the AD just sends e-mail, and archives it on ietf.org. That's just an administrative matter, nothing we even need a draft for. Incoming liaisons take a little more policy but not much. We want them archived, so just saying "submit a draft" isn't good enough. I'm afraid we need to provide mailto:ietf-liaisons@ietf.org, and yet another folder on the web pages. All ADs get to hear about all incoming liaisons, and if they think it's appropriate for one of their WGs they forward it. Done? But this shouldn't be discussed on these lists anyway :-) Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Feb 2003 11:12:24 -0800 Message-ID: <3E5D0FFF.6040407@pi.se> Date: Wed, 26 Feb 2003 20:05:35 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 MIME-Version: 1.0 To: Scott Bradner CC: dbrungard@att.com, kireeti@juniper.net, ccamp@ops.ietf.org, mpls@UU.NET Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit this might be a candidate for the understatement of the month :) Scott Bradner wrote: >>.Good point. CCAMP has received liaison statements in the past and >>we haven't really responded to them - >> >> > >this was pointed out to me (again) this week :-) > >we (the IETF) need to work out a reliable way to respond to liaison >statements > >Scott > My understanding of where we are now in this discussion it could be summarized as: We need to document the (g)mpls-change process, most of this is in the current draft. The concerns I've seen so far is on how and what could be accepted as input to the process, that should be easily solvable. We need to doucment the ietf way of responding to liasions. It is my immediate reaction that this do not really belong in the same document, if for no other reasons, at least for practical reasons. If there is a strong motive to put them in the same document, I can live with that. It has been pointed out that - inter-organization information, requests, suggestions and communications are handled different by differnt organisations. I think we should view the (g)mpls change process as IETF internal, and that we need to add some text to explain how and when external documents sent to the ietf in other format than IDs could and should be taken into the (g)mpls change process. I will update the draft with some text addressing this, the darft won't be possible to re-publish until after the IETF in SF, however we have allocated time on the ccamp and mpls working group agendas for Ron to discuss the issues with this draft. I will have this text ready in good time before this presentation. /Loa Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Feb 2003 01:45:37 -0800 Date: Wed, 26 Feb 2003 04:45:09 -0500 (EST) From: Scott Bradner Message-Id: <200302260945.h1Q9j9GB002436@newdev.harvard.edu> To: dbrungard@att.com, kireeti@juniper.net Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Cc: ccamp@ops.ietf.org, mpls@UU.NET >.Good point. CCAMP has received liaison statements in the past and > we haven't really responded to them - this was pointed out to me (again) this week :-) we (the IETF) need to work out a reliable way to respond to liaison statements Scott Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Feb 2003 01:32:11 -0800 Date: Wed, 26 Feb 2003 04:29:18 -0500 (EST) From: Scott Bradner Message-Id: <200302260929.h1Q9TI05002373@newdev.harvard.edu> To: ccamp@ops.ietf.org, dbrungard@att.com, mpls@UU.NET Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt this ID was brought up in a meeting I am at in the ITU - there is some concern about it - I have asked that people with concerns please send their concerns in. Scott Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Feb 2003 15:41:01 -0800 Date: Tue, 25 Feb 2003 15:39:26 -0800 (PST) From: Kireeti Kompella To: "Brungard, Deborah A, ALABS" cc: mpls@UU.NET, "" Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Message-ID: <20030225153004.J22280@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Deborah, On Tue, 25 Feb 2003, Brungard, Deborah A, ALABS wrote: > The draft does not include any reference to liaisons (inputs from other > standards groups). Will there be a separate process for liaisons or > this draft will be extended to include? It would be useful (especially > for other standards groups) to have clarification on how liaisons are > input to a WG, generation of responses, and process required to > coordinate work/initiate work within a working group in relation to > other standards groups. Good point. CCAMP has received liaison statements in the past and we haven't really responded to them -- in fact, I am not even sure that there is a written process to handle liaison statements, nor a well defined return channel. Since this draft is about writing down processes, we should (a) figure out how liaisons are handled; and (b) write that down as well. Ron and I will have a pow-wow with the ADs and figure this out. > On section 2.2.2 problem statement review, and in other steps where > decisions are taken, it would help to clarify if say that the decision > (e.g., 'no action') plus the basis for the decision be posted to the > Area/WG mailing list within a specified time period. Another good idea -- in line with the "new IETF with better visibility and accountability" thrust. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Feb 2003 15:22:27 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Date: Tue, 25 Feb 2003 18:19:55 -0500 Message-ID: <2FEC2C81634CDB4C9F191943ACCDC624079AA612@OCCLUST02EVS1.ugd.att.com> Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Thread-Index: AcLUIZxSKbwl+0r0RAiQ4XSYlRZL4QJAJQkA From: "Brungard, Deborah A, ALABS" To: , Loa, (I included ccamp as I was not sure everyone is on the mpls list) The draft does not include any reference to liaisons (inputs from other = standards groups). Will there be a separate process for liaisons or this = draft will be extended to include? It would be useful (especially for = other standards groups) to have clarification on how liaisons are input = to a WG, generation of responses, and process required to coordinate = work/initiate work within a working group in relation to other standards = groups. On section 2.2.2 problem statement review, and in other steps where = decisions are taken, it would help to clarify if say that the decision = (e.g., 'no action') plus the basis for the decision be posted to the = Area/WG mailing list within a specified time period. Thanks, Deborah -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Friday, February 14, 2003 6:44 AM Subject: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : MPLS and GMPLS Change Process Author(s) : L. Andersson Filename : draft-andersson-mpls-g-chng-proc-00.txt Pages : 11 Date : 2003-2-13 =09 This memo describes the process through which individuals, working groups and external standards bodies can influence the development of MPLS and GMPLS standards. With respect to standardization, this process means that (G)MPLS extensions and changes can be done through the IETF only, the body that created the (G)MPLS technology. The IETF will not publish a (G)MPLS technology extension RFC outside of the processes described here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.t= xt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-andersson-mpls-g-chng-proc-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Feb 2003 03:49:11 -0800 Message-Id: <200302241145.GAA08794@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mpls@uu.net, ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt Date: Mon, 24 Feb 2003 06:45:04 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OSPF Extensions to Support Multi-Area Traffic Engineering Author(s) : D. Cheng Filename : draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt Pages : 7 Date : 2003-2-21 The [MULTI-AREA] introduces a set of mechanisms that could be used to construct LSPs that span multiple IS-IS/OSPF areas, where one scenario is to allow the head-end LSR to compute the path all the way to the ABR in the tail-end area. This document proposes some new OSPF extensions that can be used in supporting that scenario, i.e., by leaking some of the useful information from individual areas to others, the constraint-based routing at the head-end LSR of LSPs in OSPF networks with multiple areas can be optimized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-21161106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-cheng-ccamp-ospf-multiarea-te-extensions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-21161106.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Feb 2003 03:48:53 -0800 Message-Id: <200302241144.GAA08630@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-douville-ccamp-gmpls-waveband-extensions-03.txt Date: Mon, 24 Feb 2003 06:44:24 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensions to Generalized MPLS in support of Waveband Switching Author(s) : R. Douville et al. Filename : draft-douville-ccamp-gmpls-waveband-extensions-03.txt Pages : 10 Date : 2003-2-21 Generalized MPLS (GMPLS) extends the MPLS control plane to encompass layer 2, time-division, wavelength and spatial switching. A functional description of the extensions to MPLS signaling needed to support the new types of switching is provided in [RFC-3471]. On the other hand, along with the current development on IP over optical switching, considerable advances in optical transport systems based on the multiple optical switching granularities have been developed. [RFC-3471] currently defines two layers of optical granularity using wavelengths and fibers. By introducing an extended definition of waveband switching, this document specifies the corresponding GMPLS extensions, to further integrate optical multi-granularity and benefit from the features of the corresponding switching layers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-douville-ccamp-gmpls-waveband-extensions-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-21160955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-douville-ccamp-gmpls-waveband-extensions-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-douville-ccamp-gmpls-waveband-extensions-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-21160955.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Feb 2003 03:01:34 -0800 Date: Mon, 24 Feb 2003 02:59:44 -0800 (PST) From: Kireeti Kompella To: Bob Braden cc: rsvp@ISI.EDU, "" , "" , "" Subject: Re: IANA Considerations for RSVP Message-ID: <20030224024020.N14571@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Bob, On Wed, 22 Jan 2003, Bob Braden wrote: > There is a growing unease about IANA assignments of RSVP parameters -- > object numbers, CTypes, message types, and error numbers -- for new > uses of RSVP. To come back to your email, I should say that I am happy that someone else is also concerned about this. > 3. The IANA Considerations draft should be published as an RFC, > perhaps after updating. Scant hours from the cut-off, I just submitted an ID (rsvp-change) that is basically new IANA Considerations for RSVP. This is intended to get the discussion rolling. I would suggest to folks who intend to take part in such a discussion to read Bob and Lixia's document at http://www.isi.edu/rsvp/DOCUMENTS/IANAconsider.txt . > (A) How to handle requests for RSVP assignments for > extensions developed outside IETF? > > Here is my suggestion: > > For all assignments of numbers for extensions defined > in non-IETF standards bodies, the IANA should use > assignment names (e.g., object names) that are prefixed > with the name of the responsible standards body. For > example, the "SPIFFY_SESSION" object would become > "ATM_FORUM_SPIFFY_SESSION" or "ITU-T_SPIFFY_SESSION", > etc., object. Not addressed in the rsvp-change ID, but should be. > (B) What policies should be imposed? The rsvp-change ID suggests three sets of spaces: Standards Action (a standards track RFC is needed); Expert Review (used as the moral equivalent of Experimental code points); and Private Use (no registration). > (C) What are the appropriate documentation requirements? A lengthy discussion on the IETF mailing list still hasn't enlightened me as to what "IETF Consensus" means. Thus, the suggestion in the rsvp-change ID is to use the "Standards Action" designation for code points whose specification one cares about. Kireeti. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 23 Feb 2003 20:59:29 -0800 Message-ID: <3E59A5B4.880B91D2@tellabs.com> Date: Sun, 23 Feb 2003 22:55:16 -0600 From: Jonathan Sadler Reply-To: jonathan.sadler@tellabs.com MIME-Version: 1.0 To: iesg@ietf.org, ietf@ietf.org, ccamp@ops.ietf.org Subject: Re: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please consider the following comments on these drafts: draft-ietf-ccamp-gmpls-routing-05.txt draft-ietf-ccamp-ospf-gmpls-extensions-09.txt Many of the comments are based on implementation experience. These comments are marked with a (*). Jonathan Sadler ========== 1. In section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt, the operations for Packet Switch Capable (PSC) are defined. Reference is made to Minimum LSP bandwidth for SDH encoding. None of the examples in section 5 of draft-ietf-ccamp-gmpls-routing-05.txt show how this field should filled. 2. The mechanism for showing relationships between server and client layers is not generalized*. Specifically: - Relationships between SONET/SDH layers (ISC type: TDM) are implicitly stated based on the Min and Max LSP bandwidth advertised*. To quote draft-ietf-ccamp-gmpls-routing-05.txt: "On an interface having Standard SDH multiplexing, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p." This requires node doing the route calculation to understand the G.707 multiplexing hierarchy. Since LSP routing is source routed, it could be the node doing the route calculation doesn't understand G.707. Furthermore, the G.707 multiplexing hierarchy is not a simple tree. For example VC-11 and VC-12 can be supported over VC-3 as well as over VC-4. Consequently, the definition provided does not allow a system to explicitly state which "branch" of the G.707 hierarchy should be followed. - Relationships between PSC-n (for IP switching) and SONET/SDH are explicitly specified on the encoding type specified in the PSC-n announcement*. However, SONET/SDH is not a single layer. It must be possible to identify if the PSC-n layer can be carried by a VC-11 trail, a VC-12 trail, a VC-3 trail, a VC-4 trail, or a VC-4-nc trail. Section 4.4.2 of draft-ietf-ccamp-gmpls-routing-05.txt tries to deal with this in the following paragraph: "On a PSC interface that supports Standard SDH encoding, an LSP at priority p could reserve any bandwidth allowed by the branch of the SDH hierarchy, with the leaf and the root of the branch being defined by the Minimum LSP Bandwidth and the Maximum LSP Bandwidth at priority p." The problem is this contradicts the following paragraph: "The Maximum LSP Bandwidth takes the place of the Maximum Bandwidth ([ISIS-TE], [OSPF-TE]). However, while Maximum Bandwidth is a single fixed value (usually simply the link capacity), Maximum LSP Bandwidth is carried per priority, and may vary as LSPs are set up and torn down." Specifically, how does a completely available OC-48 interface with VC-11 over VC-3, VC-3, and VC-4 get encoded? Based on the first paragraph, the encoding would be MinLSPBW=1.5M, and MaxLSPBW[p]=155M. Ignoring the issue that VC-11 over VC-4 ends up being shown as supported, the second paragraph states that the MaxLSPBW[p] should be 2.5G. Knowing the OC-48 is completely available is useful information, as multiple VC-4s could be used in an LCAS group to support connections that need data rates over 155M*. - The mechanism does not support describing common muli-layer relationships such as IP over DS1 over VC-11 or IP over DS3 over VC-3*. - Sometimes layer relationships are described in an "inverted" manner*. Section 5.1 of draft-ietf-ccamp-gmpls-routing-05.txt states: "STM-16 POS Interface on a LSR Interface Switching Capability Descriptor: Interface Switching Capability = PSC-1 Encoding = SDH Max LSP Bandwidth[p] = 2.5 Gbps, for all p" Where PSC-1 is the client of an SDH (sic) server. Section 5.5 states: "Interface of an opaque OXC (SDH framed) with support for one lambda per port/interface" " Interface Switching Capability Descriptor: Interface Switching Capability = LSC Encoding = SDH" In this case, SDH is a client of a wavelength server (LSC). However, unlike in section 5.1, the layer relationship is inverted. 3. Layer specific attributes are not supported*. Specifically: - It is not possible to have a link with different costs at different layers (ex. VC-11, VC-4, VC4-4c). The link cost is a tool used by network designers to bias traffic toward or away from specific links. Since different hardware platforms are optimized for different layers, the network designer may wish to bias traffic in a layer to use or avoid a platform that inefficiently supports a particular layer. The announcement of a link in the layer may still be desirable to allow for diverse routing. - Many attributes discussed actually refer to a specific layer*. For example SRLG can be an MS-layer attribute that is inherited by all supported layers (VC-11, VC-12, VC-3, VC-4, VC-4-nc). Likewise Protection mechanisms supported can be specified at the MS-layer and the path layer. Knowing the specific layer the attributes exist at allow for higher quality routes to be developed*. It can also allow for proper provisioning of upper layer functions, such as protection hold off timers*. - Combining layer specific attributes with layer relationships can provide a more efficient encoding mechanism than requiring separate link announcements per layer*. 4. The "TDM" Interface Switching Capability presumably includes layers other than SONET/SDH, such as PDH* (DS1, DS3, E1, E3) and G.709. The interaction with these layers needs to be defined. 5. In many cases, 8 levels of priority are not necessary*. A more compact encoding that has a bitfield stating the priority levels being announced would reduce the size of the announcement. The IESG wrote: > The IESG has received a request from the Common Control and Measurement > Plane Working Group to consider publication of the following two > Internet-Drafts as Proposed Standards: > > o Routing Extensions in Support of Generalized MPLS > > o OSPF Extensions in Support of Generalized MPLS > > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-24. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-05.txt > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-09.txt ============================================================ The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs ============================================================ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Feb 2003 16:47:53 -0800 Message-ID: <000501c2d8da$f6022100$92256497@coritel> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit From: "Roberto Albanese" To: "CCAMP WG" Subject: Error Code Info Date: Wed, 19 Feb 2003 19:29:02 +0100 [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi all, can anyone solve my doubts, please? I'd like to implement a link-failure functionality in a MPLS architecture using RSVP. I'd like to do this using a PathErr message i forward towards the SENDER node of the LSP. In this PathErr i put the only information: link-failure event occurred to LSP. I saw that there is an ERROR_SPEC Object with error code and values i can use, but i haven't found any proposal about what error code to use. Have you any? Is there a standard error code i haven't seen? What error code could i use? If there is not even one proposed i can use only an unassigned/private error code. What are the private error codes i can use? Thanks in advance for your kind answer Roberto Albanese Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Feb 2003 07:54:36 -0800 Message-ID: <3E54F98F.ABBE4329@alcatel.be> Date: Thu, 20 Feb 2003 16:51:43 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) MIME-Version: 1.0 To: takao.okamawari@bt.com CC: ccamp@ops.ietf.org Subject: Re: Question about gmpls-recovery-terminology draft Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii hi, the relationship is detailed in the proceedings: http://www.ietf.org/proceedings/02nov/slides/ccamp-8/index.html http://www.ietf.org/proceedings/02nov/slides/ccamp-8/sld2.htm the last status report can be found at: http://psg.com/lists/ccamp/ccamp.2002/msg01243.html we also plan to submit a new status report very soon, hope this will help you, - dimitri. takao.okamawari@bt.com wrote: > > Dimitri, > > Thank you for your answer. I found a similar explanation in 5.4.1 of > the gmpls-recovery-analysis draft as well. Could you tell me how those > drafts > (recovery-analysis, recovery-functional and recovery-terminology) interacts > each other? > > Takao > > On Thursday, February 20, 2003 1:51 PM, Dimitri.Papadimitriou@alcatel.be > [SMTP:Dimitri.Papadimitriou@alcatel.be] wrote: > > hi, > > > > normally in section 7 "restoration schemes" > > which will be completed once other i-d's > > are finalized - note that more description > > of this can be found in section 3.3 of > > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery- > > functional-00.txt > > > > thanks, > > - dimitri. > > > > takao.okamawari@bt.com wrote: > > > > > > Think about the following scenario. > > > > > > A *-------------* B > > > | | > > > C *-------------* D > > > | | > > > E *-------------* F > > > > > > Two working paths are established between A-B and E-F. > > > The protection path for A-B is A-C-D-B. > > > The protection path for E-F is E-C-D-F. > > > Since the two working paths are disjointed, > > > the protection resource between C and D is common, > > > i.e. shared by two working paths. > > > > > > My question is where does this protection/restoration method > > > fit in the gmpls-recovery-terminology document? > > > > > > Takao > > > > -- > > Papadimitriou Dimitri > > E-mail : dimitri.papadimitriou@alcatel.be > > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > > E-mail : dpapadimitriou@psg.com > > Public : http://psg.com/~dpapadimitriou/ > > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Feb 2003 06:37:49 -0800 Message-ID: From: takao.okamawari@bt.com To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org Subject: RE: Question about gmpls-recovery-terminology draft Date: Thu, 20 Feb 2003 14:36:03 -0000 MIME-Version: 1.0 content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Dimitri, Thank you for your answer. I found a similar explanation in 5.4.1 of the gmpls-recovery-analysis draft as well. Could you tell me how those drafts (recovery-analysis, recovery-functional and recovery-terminology) interacts each other? Takao On Thursday, February 20, 2003 1:51 PM, Dimitri.Papadimitriou@alcatel.be [SMTP:Dimitri.Papadimitriou@alcatel.be] wrote: > hi, > > normally in section 7 "restoration schemes" > which will be completed once other i-d's > are finalized - note that more description > of this can be found in section 3.3 of > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery- > functional-00.txt > > thanks, > - dimitri. > > takao.okamawari@bt.com wrote: > > > > Think about the following scenario. > > > > A *-------------* B > > | | > > C *-------------* D > > | | > > E *-------------* F > > > > Two working paths are established between A-B and E-F. > > The protection path for A-B is A-C-D-B. > > The protection path for E-F is E-C-D-F. > > Since the two working paths are disjointed, > > the protection resource between C and D is common, > > i.e. shared by two working paths. > > > > My question is where does this protection/restoration method > > fit in the gmpls-recovery-terminology document? > > > > Takao > > -- > Papadimitriou Dimitri > E-mail : dimitri.papadimitriou@alcatel.be > Private: http://www.rc.bel.alcatel.be/~papadimd/index.html > E-mail : dpapadimitriou@psg.com > Public : http://psg.com/~dpapadimitriou/ > Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium > Phone : Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Feb 2003 05:52:31 -0800 Message-ID: <3E54DD2B.22DDA76D@alcatel.be> Date: Thu, 20 Feb 2003 14:50:35 +0100 From: Dimitri.Papadimitriou@alcatel.be Organization: Optical Network Architecture (NTA - Antwerpen) MIME-Version: 1.0 To: takao.okamawari@bt.com CC: ccamp@ops.ietf.org Subject: Re: Question about gmpls-recovery-terminology draft Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii hi, normally in section 7 "restoration schemes" which will be completed once other i-d's are finalized - note that more description of this can be found in section 3.3 of http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-00.txt thanks, - dimitri. takao.okamawari@bt.com wrote: > > Think about the following scenario. > > A *-------------* B > | | > C *-------------* D > | | > E *-------------* F > > Two working paths are established between A-B and E-F. > The protection path for A-B is A-C-D-B. > The protection path for E-F is E-C-D-F. > Since the two working paths are disjointed, > the protection resource between C and D is common, > i.e. shared by two working paths. > > My question is where does this protection/restoration method > fit in the gmpls-recovery-terminology document? > > Takao -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be Private: http://www.rc.bel.alcatel.be/~papadimd/index.html E-mail : dpapadimitriou@psg.com Public : http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : Work: +32 3 2408491 - Home: +32 2 3434361 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Feb 2003 05:39:38 -0800 Message-ID: From: takao.okamawari@bt.com To: ccamp@ops.ietf.org Subject: Question about gmpls-recovery-terminology draft Date: Thu, 20 Feb 2003 13:36:10 -0000 MIME-Version: 1.0 content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Think about the following scenario. A *-------------* B | | C *-------------* D | | E *-------------* F Two working paths are established between A-B and E-F. The protection path for A-B is A-C-D-B. The protection path for E-F is E-C-D-F. Since the two working paths are disjointed, the protection resource between C and D is common, i.e. shared by two working paths. My question is where does this protection/restoration method fit in the gmpls-recovery-terminology document? Takao Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Feb 2003 00:18:59 -0800 Message-ID: <20030220081550.7962.qmail@web20705.mail.yahoo.com> Date: Thu, 20 Feb 2003 00:15:50 -0800 (PST) From: Sameer K Subject: RFC 3471: IF ID specification WRT component link. To: ccamp@ops.ietf.org, mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hello All, >From the RFC 3471 - GMPLS Signaling Functional Description, Section 9.1.1, it appears that there is no way for upstream node, to specify component links that are numbered, in the IF-ID HOP object. The TLV format for IF-ID Types 4 and 5 assumes that the component link is always un-numbered. Is this the way it was planned to be?. If yes, then what should IF-ID look like for numbered component link (which is a valid scenario per the Link Bundling draft). Or did I get it all wrong? TIA - Sameer __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Feb 2003 00:12:28 -0800 Message-ID: <20030220080747.80712.qmail@web20708.mail.yahoo.com> Date: Thu, 20 Feb 2003 00:07:47 -0800 (PST) From: Sameer K Subject: RE: Regarding Switching capability and GPID in OSPF-TE and GMPLS- RSVP To: Charles Chen , ccamp@ops.ietf.org, mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Thanks for the clarification Charles. I understand that this is not an issue for overlay network model where the peering NEs at each individual layer (in our example, the routers) have an understanding of the "layer resources" and interfaces at the same layer. But does this argument stay valid for peering model as well? - Sameer --- Charles Chen wrote: > It is an interesting question to ask, but it may not > be an issue in the real > world. In your example, one can assume that a router > A would like to ask the > transport network to set up a PPP link dynamically > to a remote router B. > Let's put this in the overlay mode perspective, the > router A (edge device) > will request a connection to a core device (OXC). In > reality, the router A > has some prior knowledge or is driven by the traffic > engineering policy that > it wants to connect to the remote router B. At the > minimum, the router A has > to provide the information about the router B > (destination address in the > transport network), the path constraints and so on. > > It is not possible to build a network that provides > all possible application > level information. The above issue makes no > difference from that a user A > establishes a UDP connection in order to transmit > JPEG video over it to a > user B. The user A finds out later that the > receiving user B only supports > the MPEG coding scheme. Yes, it is a blocking model > but scalable. > > Charles > > > -----Original Message----- > > From: Sameer K [mailto:sameerdw@yahoo.com] > > Sent: Thursday, February 13, 2003 3:01 PM > > To: ccamp@ops.ietf.org; mpls@UU.NET > > Subject: Regarding Switching capability and GPID > in OSPF-TE and > > GMPLS-RSVP > > > > > > Hello All, > > > > I have some questions regarding switching > capability > > descriptor, encoding type and GPID parameters, and > the > > correlation between the values signaled in > signaling > > request and the values advertised in OSPF TE LSAs. > > > > From the previous discussions, it appears that if > a > > data capable device has to establish LSP through a > > network of OXCs, the switching type requested > would be > > FSC, the encoding type would be SDH/SONET with > GPID > > being PPP (assuming that the data device that is > LSP > > ingress wants to send IP data over the LSP). Now, > the > > LSP will be established without any problem as > long as > > the destination node is advertising a switching > > capability FSC and the encoding type SONET/SDH for > all > > its interfaces. > > > > However, for the LSP to be of any use to ingress > node, > > the destination must be capable of terminating PPP > > (which in turn requires data capability on the > > incoming interface of egress node). The way to > ensure > > this would be to read GPID and then egress can > reject > > the LSP if it cannot support the GPID. > > > > However, what if destination is a multi-service > switch > > and bears certain interfaces that are FSC capable > and > > can terminate PPP as well (that is, support data > over > > FSC -if you will), other than the FSC only > interfaces. > > CSPF running at ingress can never tell the > difference > > between these (data over FSC type) interfaces and > > other (FSC only) interfaces and the LSP might end > up > > on an interface that cannot support PPP > termination. > > In such a case, even though the node supports PPP > at > > certain interfaces, the LSP will have to be > rejected. > > > > > > Now, if some "higher layer" information (PPP > > termination capability for this example), is > > advertised as a part of OSPF TE LSAs, the CSPF > running > > on the ingress node can pick up the correct > incoming > > interface on egress node based on the GPID > desired, > > thus reducing the probability of LSP failures. > > > > Would like to hear opinions. > > TIA > > - Sameer. > > > > __________________________________________________ > > Do you Yahoo!? > > Yahoo! Shopping - Send Flowers for Valentine's Day > > http://shopping.yahoo.com > > > __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Feb 2003 19:45:29 -0800 Message-Id: <4.3.2.7.2.20030219223928.01f57f00@toque.cisco.com> Date: Wed, 19 Feb 2003 22:43:44 -0500 To: ccamp@ops.ietf.org From: "Siva Sivabalan (msiva)" Subject: Question on draft-ietf-ccamp-gmpls-routing-05.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, In section 4.4.2 draft-ietf-ccamp-gmpls-routing-05.txt, Max LSP Bandwidth has been defined for PSC capable link as follows: "For a simple (unbundled) link its Maximum LSP Bandwidth at priority p is defined to be the smaller of its unreserved bandwidth at priority p and its Maximum Reservable Bandwidth........" For a link (simple), the initial value of unreserved bandwidth at any given priority is equal to Maximum Reservable Bandwidth. Furthermore, unreserved bandwidth at any given priority is always less than or equal to Maximum Reservable Bandwidth. If this is true, then Maximum LSP Bandwidth at priority p is equal to unreserved bandwidth at priority p. Is it correct or am I missing something ? Thanks, Siva Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Feb 2003 15:23:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 19 Feb 2003 18:19:35 +0100 Subject: =?iso-8859-1?Q?Info_about_code?= From: "=?iso-8859-1?Q?john150@inwind.it?=" To: "=?iso-8859-1?Q?ccamp?=" [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Hi all,=0D=0Ai'd like to know if there is an error code for ERROR_SPEC Ob= ject in PathErr=0D=0Amessage for RSVP Protocol in case of link failure.=0D= =0AIn example when i see that a link is down i'd like to send a PathErr w= ith=0D=0Athis error code.=0D=0AI haven't found such a code or a proposal = for this.=0D=0AHave i any free or personal code i can use if there isn't = a dedicated one?=0D=0A=0D=0AThanks in advance for your kind answer=0D=0A=0D= =0ARoberto Albanese=0D=0A Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 19 Feb 2003 04:11:08 -0800 Message-Id: <200302191203.HAA19927@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-sdhsonet-control-02.txt Date: Wed, 19 Feb 2003 07:03:50 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for GMPLS-based Control of SDH/SONET Networks Author(s) : G. Bernstein, E. Mannie, V. Sharma Filename : draft-ietf-ccamp-sdhsonet-control-02.txt Pages : 26 Date : 2003-2-14 The suite of protocols that defines Multi-Protocol Label Switching (MPLS) is in the process of enhancement to generalize its applicability to the control of non-packet based switching, that is, optical switching. One area of prime consideration is to use these generalized MPLS (GMPLS) protocols in upgrading the control plane of optical transport networks. This document illustrates this process by describing those extensions to MPLS protocols that are directed towards controlling SONET/SDH networks. SONET/SDH networks make very good examples of this process since they possess a rich multiplex structure, a variety of protection/restoration options, are well defined, and are widely deployed. The document discusses extensions to MPLS routing protocols to disseminate information needed in transport path computation and network operations, together with the extensions to MPLS label distribution protocols needed for the provisioning of transport circuits. New capabilities that an MPLS control plane would bring to SONET/SDH networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-sdhsonet-control-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-14105057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-sdhsonet-control-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-sdhsonet-control-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-14105057.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Feb 2003 14:17:55 -0800 Message-ID: <3E4D69F3.6080900@pi.se> Date: Fri, 14 Feb 2003 23:13:07 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 MIME-Version: 1.0 To: "Andrew G. Malis" CC: mpls@uu.net, ccamp@ops.ietf.org, pwe3@ietf.org Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andy, when writing the draft we briefly discussed whether to mention pwe3 or not, I gather that ther were different reasons for different people not to. The mpls and ccamp wg-chairs and the SubIP ADs had discussed the process for some time, on my part I did not want to delay publication by throwing this on the pwe3 chair just minutes before the prublication. I also think that there is an issue that pwe3 is not squarely within what we define as (G)MPLS technology, pwe3 is an end to end technology and that is why it is in transport. This could be splitting hairs by an axe, we took the decision to publish to get the type of reaction you given us here. The draft is out there to be discussed. If the pwe3 were to take up those extensions to ldp today, we would ask for problem description and requirments, on my part it is not my intention (and I don't think of any of the other authors) to retro-engineer existing work to fit the process. You might have noticed that I gave Jerry Ash the same answer when he suggested that the mpls should take up work on header compression over mpls. But since his work is not accepted or rejected yet, give us as much of the information as possible in the format we want to have in the change process. Though he has a certain freedom here. pwe3 in specifying extensions to ldp, would be a "protocol specifying working group", but note that this does not automatically transmorgraphies it into a (g)mpls technology working group. If you suggest that the pwe3 wg should be included as one of the (g)mpls technology working groups, then I suggest that you give us text to be discussed and if a consensus is reached included in the draft. Personally I would like to hear the transport ADs and pwe3 wg chairs opinion on this. Strictly I don't think we can require that people follow the process until the IESG has OKed it, but as a wg chair I can clearly have an opinion on how and where work on protocols specified by the mpls wg are done and how the mpls wg takes on new work. To avoid cross-posts I suggest that we taken the discussion on the draft-andersson-mpls-g-chng-proc-00.txt on the mpls list :). We will allocate time in both the mpls and ccamp working group meetings in SF to discuss this. /Loa Andrew G. Malis wrote: > Loa, > > I assume that the mpls and ccamp lists are the appropriate places for > discussion of this draft. I also included the pwe3 list, since this > also affects the work in that WG. I apologize for the crossposts to > those of you on more than one of these lists (including myself). > Perhaps once the discussion has started, we can pick just one place to > continue it. > > My initial reaction on reading your draft was that I didn't see any > discussion of the pwe3 WG, which as you know is specifying extensions > to RFC 3036. For the purposes of your draft, would pwe3 be classified > as a "protocol specifying working group"? And is it your intention > that the current work in the pwe3 WG be approved by the "requirement > evaluating working group" prior to its documents being published as > RFCs? Or would this be grandfathered in as already having been > chartered by the IESG? > > Thanks, > Andy > > ------- > > At 2/14/2003 06:43 AM -0500, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : MPLS and GMPLS Change Process >> Author(s) : L. Andersson >> Filename : draft-andersson-mpls-g-chng-proc-00.txt >> Pages : 11 >> Date : 2003-2-13 >> >> This memo describes the process through which individuals, working >> groups and external standards bodies can influence the development of >> MPLS and GMPLS standards. With respect to standardization, this >> process means that (G)MPLS extensions and changes can be done through >> the IETF only, the body that created the (G)MPLS technology. The >> IETF will not publish a (G)MPLS technology extension RFC outside of >> the processes described here. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt >> >> >> To remove yourself from the IETF Announcement list, send a message to >> ietf-announce-request with the word unsubscribe in the body of the >> message. >> >> Internet-Drafts are also available by anonymous FTP. Login with the >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-andersson-mpls-g-chng-proc-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail >> readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2003-2-13152703.I-D@ietf.org> >> >> ENCODING mime >> FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt >> >> >> > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Feb 2003 13:22:20 -0800 Message-Id: <5.2.0.9.0.20030214155201.043ebe30@po1.vivacenetworks.com> Date: Fri, 14 Feb 2003 16:05:57 -0500 To: Loa Andersson From: "Andrew G. Malis" Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt Cc: mpls@uu.net,ccamp@ops.ietf.org,pwe3@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Loa, I assume that the mpls and ccamp lists are the appropriate places for discussion of this draft. I also included the pwe3 list, since this also affects the work in that WG. I apologize for the crossposts to those of you on more than one of these lists (including myself). Perhaps once the discussion has started, we can pick just one place to continue it. My initial reaction on reading your draft was that I didn't see any discussion of the pwe3 WG, which as you know is specifying extensions to RFC 3036. For the purposes of your draft, would pwe3 be classified as a "protocol specifying working group"? And is it your intention that the current work in the pwe3 WG be approved by the "requirement evaluating working group" prior to its documents being published as RFCs? Or would this be grandfathered in as already having been chartered by the IESG? Thanks, Andy ------- At 2/14/2003 06:43 AM -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : MPLS and GMPLS Change Process > Author(s) : L. Andersson > Filename : draft-andersson-mpls-g-chng-proc-00.txt > Pages : 11 > Date : 2003-2-13 > >This memo describes the process through which individuals, working >groups and external standards bodies can influence the development of >MPLS and GMPLS standards. With respect to standardization, this >process means that (G)MPLS extensions and changes can be done through >the IETF only, the body that created the (G)MPLS technology. The >IETF will not publish a (G)MPLS technology extension RFC outside of >the processes described here. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-andersson-mpls-g-chng-proc-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-2-13152703.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Feb 2003 16:15:53 -0800 Message-Id: <200302140011.h1E0BmD03614@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3472 on Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Thu, 13 Feb 2003 16:11:47 -0800 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3472 Title: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions Author(s): P. Ashwood-Smith, L. Berger, Editors Status: Standards Track Date: January 2003 Mailbox: petera@nortelnetworks.com, lberger@movaz.com Pages: 23 Characters: 49006 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-generalized-cr-ldp-07.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3472.txt This document describes extensions to Multi-Protocol Label Switching (MPLS) Constraint-based Routed Label Distribution Protocol (CR-LDP) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a CR-LDP specific description of the extensions. A generic functional description can be found in separate documents. This document is a product of the Common Control and Measurement Plane (ccamp) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030213161006.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3472 --OtherAccess Content-Type: Message/External-body; name="rfc3472.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030213161006.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Feb 2003 16:15:45 -0800 Message-Id: <200302140014.h1E0E3D04402@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3473 on Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Thu, 13 Feb 2003 16:14:03 -0800 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3473 Title: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions Author(s): L. Berger, Editor Status: Standards Track Date: January 2003 Mailbox: lberger@movaz.com Pages: 42 Characters: 91808 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-generalized-rsvp-te-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3473.txt This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. This document is a product of the Common Control and Measurement Plane (ccamp) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030213161221.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3473 --OtherAccess Content-Type: Message/External-body; name="rfc3473.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030213161221.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Feb 2003 16:00:38 -0800 Message-Id: <200302132356.h1DNu4D24228@gamma.isi.edu> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart To: IETF-Announce: ; Subject: RFC 3471 on Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org From: rfc-editor@rfc-editor.org Date: Thu, 13 Feb 2003 15:56:04 -0800 --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3471 Title: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description Author(s): L. Berger, Editor Status: Standards Track Date: January 2003 Mailbox: lberger@movaz.com Pages: 34 Characters: 72746 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-generalized-signaling-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3471.txt This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. This document is a product of the Common Control Measurement Plane (ccamp) Working Group of the IETF. This is a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030213155400.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3471 --OtherAccess Content-Type: Message/External-body; name="rfc3471.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030213155400.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Feb 2003 15:46:51 -0800 Message-ID: <9D6D37E97A57D411BB7C00508BAE29C9045DDBC6@main.mahinetworks.com> From: Charles Chen To: 'Sameer K' , ccamp@ops.ietf.org, mpls@UU.NET Subject: RE: Regarding Switching capability and GPID in OSPF-TE and GMPLS- RSVP Date: Thu, 13 Feb 2003 15:45:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" It is an interesting question to ask, but it may not be an issue in the real world. In your example, one can assume that a router A would like to ask the transport network to set up a PPP link dynamically to a remote router B. Let's put this in the overlay mode perspective, the router A (edge device) will request a connection to a core device (OXC). In reality, the router A has some prior knowledge or is driven by the traffic engineering policy that it wants to connect to the remote router B. At the minimum, the router A has to provide the information about the router B (destination address in the transport network), the path constraints and so on. It is not possible to build a network that provides all possible application level information. The above issue makes no difference from that a user A establishes a UDP connection in order to transmit JPEG video over it to a user B. The user A finds out later that the receiving user B only supports the MPEG coding scheme. Yes, it is a blocking model but scalable. Charles > -----Original Message----- > From: Sameer K [mailto:sameerdw@yahoo.com] > Sent: Thursday, February 13, 2003 3:01 PM > To: ccamp@ops.ietf.org; mpls@UU.NET > Subject: Regarding Switching capability and GPID in OSPF-TE and > GMPLS-RSVP > > > Hello All, > > I have some questions regarding switching capability > descriptor, encoding type and GPID parameters, and the > correlation between the values signaled in signaling > request and the values advertised in OSPF TE LSAs. > > From the previous discussions, it appears that if a > data capable device has to establish LSP through a > network of OXCs, the switching type requested would be > FSC, the encoding type would be SDH/SONET with GPID > being PPP (assuming that the data device that is LSP > ingress wants to send IP data over the LSP). Now, the > LSP will be established without any problem as long as > the destination node is advertising a switching > capability FSC and the encoding type SONET/SDH for all > its interfaces. > > However, for the LSP to be of any use to ingress node, > the destination must be capable of terminating PPP > (which in turn requires data capability on the > incoming interface of egress node). The way to ensure > this would be to read GPID and then egress can reject > the LSP if it cannot support the GPID. > > However, what if destination is a multi-service switch > and bears certain interfaces that are FSC capable and > can terminate PPP as well (that is, support data over > FSC -if you will), other than the FSC only interfaces. > CSPF running at ingress can never tell the difference > between these (data over FSC type) interfaces and > other (FSC only) interfaces and the LSP might end up > on an interface that cannot support PPP termination. > In such a case, even though the node supports PPP at > certain interfaces, the LSP will have to be rejected. > > > Now, if some "higher layer" information (PPP > termination capability for this example), is > advertised as a part of OSPF TE LSAs, the CSPF running > on the ingress node can pick up the correct incoming > interface on egress node based on the GPID desired, > thus reducing the probability of LSP failures. > > Would like to hear opinions. > TIA > - Sameer. > > __________________________________________________ > Do you Yahoo!? > Yahoo! Shopping - Send Flowers for Valentine's Day > http://shopping.yahoo.com > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 13 Feb 2003 15:02:58 -0800 Message-ID: <20030213230057.47285.qmail@web20702.mail.yahoo.com> Date: Thu, 13 Feb 2003 15:00:57 -0800 (PST) From: Sameer K Subject: Regarding Switching capability and GPID in OSPF-TE and GMPLS-RSVP To: ccamp@ops.ietf.org, mpls@UU.NET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hello All, I have some questions regarding switching capability descriptor, encoding type and GPID parameters, and the correlation between the values signaled in signaling request and the values advertised in OSPF TE LSAs. >From the previous discussions, it appears that if a data capable device has to establish LSP through a network of OXCs, the switching type requested would be FSC, the encoding type would be SDH/SONET with GPID being PPP (assuming that the data device that is LSP ingress wants to send IP data over the LSP). Now, the LSP will be established without any problem as long as the destination node is advertising a switching capability FSC and the encoding type SONET/SDH for all its interfaces. However, for the LSP to be of any use to ingress node, the destination must be capable of terminating PPP (which in turn requires data capability on the incoming interface of egress node). The way to ensure this would be to read GPID and then egress can reject the LSP if it cannot support the GPID. However, what if destination is a multi-service switch and bears certain interfaces that are FSC capable and can terminate PPP as well (that is, support data over FSC -if you will), other than the FSC only interfaces. CSPF running at ingress can never tell the difference between these (data over FSC type) interfaces and other (FSC only) interfaces and the LSP might end up on an interface that cannot support PPP termination. In such a case, even though the node supports PPP at certain interfaces, the LSP will have to be rejected. Now, if some "higher layer" information (PPP termination capability for this example), is advertised as a part of OSPF TE LSAs, the CSPF running on the ingress node can pick up the correct incoming interface on egress node based on the GPID desired, thus reducing the probability of LSP failures. Would like to hear opinions. TIA - Sameer. __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Feb 2003 23:48:56 -0800 Message-ID: From: Heiles Juergen To: "'Wijnen, Bert (Bert)'" , "Ccamp-wg (E-mail)" Subject: AW: Last Call: Generalized Multiprotocol Label Switching Extensio ns for SONET and SDH Control to Proposed Standard Date: Wed, 12 Feb 2003 08:45:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable The signals that are part of the virtual concatenation are virtually = concatenated. Regards Juergen > -----Urspr=A8=B9ngliche Nachricht----- > Von: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Gesendet: Dienstag, 11. Februar 2003 17:49 > An: Ccamp-wg (E-mail) > Betreff: FW: Last Call: Generalized Multiprotocol Label=20 > Switching Extensio ns for SONET and SDH Control to Proposed Standard >=20 >=20 > IESG received this comment. I guess the answer is: no difference > right? >=20 > Thanks, > Bert=20 >=20 > -----Original Message----- >=20 > I have some doubt with the following text about virtual = concatenation. > ----------------- > The standard definition for virtual concatenation allows each > virtual concatenation components to travel over diverse paths. > Within GMPLS, virtual concatenation components must travel over > the same (component) link if they are part of the same LSP. This > is due to the way that labels are bound to a (component) link. > Note however, that the routing of components on different paths is > indeed equivalent to establishing different LSPs, each one having > its own route. Several LSPs can be initiated and terminated > between the same nodes and their corresponding components can then > be associated together (i.e. virtually concatenated). > --------------- > I wonder what's the difference between "virtual=20 > concatenation" and "virtually concatenated"? > Thanks! >=20 > rick >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Feb 2003 08:50:22 -0800 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155E6478D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: FW: Last Call: Generalized Multiprotocol Label Switching Extensio ns for SONET and SDH Control to Proposed Standard Date: Tue, 11 Feb 2003 17:48:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" IESG received this comment. I guess the answer is: no difference right? Thanks, Bert -----Original Message----- I have some doubt with the following text about virtual concatenation. ----------------- The standard definition for virtual concatenation allows each virtual concatenation components to travel over diverse paths. Within GMPLS, virtual concatenation components must travel over the same (component) link if they are part of the same LSP. This is due to the way that labels are bound to a (component) link. Note however, that the routing of components on different paths is indeed equivalent to establishing different LSPs, each one having its own route. Several LSPs can be initiated and terminated between the same nodes and their corresponding components can then be associated together (i.e. virtually concatenated). --------------- I wonder what's the difference between "virtual concatenation" and "virtually concatenated"? Thanks! rick Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Feb 2003 09:46:24 -0800 Message-Id: <200302101742.MAA17620@ietf.org> To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: The IESG SUBJECT: Last Call: Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Feb 2003 12:42:06 -0500 The IESG has received a request from the Common Control and Measurement Plane Working Group to consider Generalized Multiprotocol Label Switching Extensions for SONET and SDH Control as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-24. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-sonet-sdh-07.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Feb 2003 09:22:37 -0800 Message-Id: <200302101717.MAA16387@ietf.org> To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: The IESG SUBJECT: Last Call: Routing Extensions in Support of Generalized MPLS vto Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Feb 2003 12:17:23 -0500 The IESG has received a request from the Common Control and Measurement Plane Working Group to consider publication of the following two Internet-Drafts as Proposed Standards: o Routing Extensions in Support of Generalized MPLS o OSPF Extensions in Support of Generalized MPLS The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-24. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-routing-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-gmpls-extensions-09.txt Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Feb 2003 04:48:39 -0800 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155D6D119@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ccamp-wg (E-mail)" Subject: AD comments on: draft-ietf-ccamp-gmpls-sonet-sdh-07.txt Date: Mon, 10 Feb 2003 13:47:19 +0100 MIME-Version: 1.0 Content-Type: text/plain All, I have asked IESG secretariat to issue an IETF Last Call for this document for PS. We have detached the sonet-sdh-extensions document from the "package" and it will have to stand on its own. Remember that I am not willing to defend the sonet-sdh-extensions signalling document if nobody can come up with documents (or ptrs to documents) that describe the technology to be signalled. W.r.t. draft-ietf-ccamp-gmpls-sonet-sdh-07.txt I have still a few nits. Pls consider them as the first comments for the IETF Last Call process (so you can integrate any edits with whatever needs to be done as a result of IETF Last Call). - Personal opinion... I find it disgusting that a list of contributors makes up the first 3 pages of the document. I wonder why you moved it to the front... If you want to keep it, I think it much better fits at the end. Nevertheless, I personally will not block it if this is what you want. - At the bottom of section 1, remove the text about changes reb 6 to rev 7 - I see funny redmond characters - in first para on page 8 - in footer on each page - in the references section, 1st reference - in Authors' Addresses section (title) - possibly at other places? You may want to fix that - one but last para page 10: s/Others flags/Other flags/ - in the Security Considerations section, you may want to make clear that RFC3212 discusses security considerations for CR-LDP. - In the IANA considerations... (but I bet IANA will ask for it) you better make it clear which assignments are in which name space. I personally would also repeat the actual code points to be assigned. Thanks, Bert Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 09 Feb 2003 17:08:47 -0800 Message-ID: <002e01c2d0a0$a8726810$1bbffe81@evergreen> From: "Soo-Hyun Choi" To: Subject: [Test Message] Date: Mon, 10 Feb 2003 10:06:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, ccamp-ers, This is [TEST-MESSAGE]. For some reasons, the outgoing e-mail from our site is always bounced. I'm sorry if this bothered you. SH- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 08 Feb 2003 20:24:24 -0800 Date: Sat, 08 Feb 2003 23:21:14 -0500 From: Ron Bonica Subject: Posted on behalf of Young Hwa Kim To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Folks, The following message is posted on behalf of Young Hwa Kim. He attempted to post this message several days ago, but for some reason, it didn't get posted to the list. Ron ===================================================== Hi, all. I'd like to discuss the control plane resilience via the mailing list and in the next IETF meeting. In current, we do not have works about the control plane resilience. The current focus of resilience has been only on transport plane. The draft-ietf-ccamp-gmpls-recovery-analysis-00.txt also describes as follows: "Here, the focus will only be on transport plane survivability and recovery issues and not on control plane resilience related aspects." I do not think it means that control plane does not need to have features of the control plane resilience. In order to provide reliable control networks in relevant networks, the control plane resilience is also important. I think the first issue to handle the problem domain, called the control plane resilience is whether the problem domain is related to the CCAMP charter or not. We could read the following in the CCAMP charter. "Abstract link and path properties needed for link and path protection. Define signaling mechanisms for path protection, diverse routing and fast path restoration. Ensure that multi-layer path protection and restoration functions are achievable using the defined signaling and measurement protocols, either separately or in combination." In the sentence above, I could not assure whether link and path protection means only transport plane, or transport plane and control plane together. If the sentence means the former, the charter have to be updateted. But, if the sentence means the latter, the one seems good as such. I think the latter interpretation is appropriate to us because the CCAMP realm handle control plane. If so, I'm free to get into discussion on the control plane resilience. But, our current concerns are on transport plane. Under this status, it may be not possible to discuss a protocol specification for protecting control channels. I think the work for a framework or requirements for protecting control channels may be good as a starting point. I'm looking forward your opinions. If you're interested in the control plane resilience, please refer to draft-kim-ccamp-cc-protection-01.txt. The document has the abstract section such as the following: Abstract This document proposes a protocol used to protect control channels between adjacent nodes in GMPLS. Control channels are used to carry several control packets that include signaling related, routing related, or link management related information. The protocol may be used not in in-fiber(or in-band) network configurations but in out-of-fiber(or out-of-band) network configurations. Because this proposal is a first document for specifying the protocol used to protect control channels, it has no full contents for the specification to be proposed. Instead, this document focuses on basic concepts, necessity and requirements to be analyzed for protecting control channels. If we agree to this proposal including necessity and requirements for protecting control channels, we may proceed further works for the protection of control channels. Thank you for reading this email. ****************************************** Young Hwa Kim Senior Member, Network Technology Lab., ETRI Office No. : 82-42-860-5819 Fax No. : 82-42-860-6342 Email addr. : yhwkim@etri.re.kr ****************************************** Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Feb 2003 03:49:47 -0800 Message-Id: <200302041143.GAA17008@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-functional-00.txt Date: Tue, 04 Feb 2003 06:43:56 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS Recovery Functional Specification Author(s) : J. Lang, B. Rajagopalan Filename : draft-ietf-ccamp-gmpls-recovery-functional-00.txt Pages : 19 Date : 2003-2-3 This document presents a functional description of the protocol extensions needed to support GMPLS-based recovery (i.e. protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-functional-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-3125311.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-functional-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-functional-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-3125311.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Feb 2003 16:44:09 -0800 Date: Mon, 03 Feb 2003 19:42:09 -0500 From: Ron Bonica Subject: FW: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003) To: ccamp@ops.ietf.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit fyi > -----Original Message----- > From: owner-ietf-announce@ietf.org > [mailto:owner-ietf-announce@ietf.org]On Behalf Of Internet-Drafts > Administrator > Sent: Monday, February 03, 2003 7:08 AM > To: IETF-Announce: > Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, > 2003) > > > > NOTE: There are two (2) Internet-Draft Cutoff dates > > February 24th: Cutoff for Initial Submissions (new documents) > > All initial submissions(-00) must be submitted by Monday, February 24th, > at 09:00 ET. Initial submissions received after this time will NOT be > made available in the Internet-Drafts directory, and will have to be > resubmitted. > > > As before, all initial submissions (-00.txt) with a filename beginning > with a draft-ietf MUST be approved by the appropriate WG Chair prior to > processing and announcing. WG Chair approval must be received by > Monday, February 24th. > > Please do NOT wait until the last minute to submit. > > Be advised: NO placeholders. Updates to initial submissions received > the week of February 24th will NOT be accepted. > > March 3rd: FINAL Internet-Draft Cutoff > > All revised Internet-Draft submissions must be submitted by Monday, > March 3rd, 2003 at 09:00 ET. Internet-Drafts received after this > time will NOT be announced NOR made available in the Internet-Drafts > Directories. > > We will begin accepting Internet-Draft submissions the week of the > meeting, though announcements will NOT be sent until the IETF meeting > is over. > > Thank you for your understanding and cooperation. Please do not hesitate > to contact us if you have any questions or concenrs. > > FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_56.html > >