From owner-ccamp@ops.ietf.org Thu Sep 01 04:56:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAksD-0000WP-R1 for ccamp-archive@megatron.ietf.org; Thu, 01 Sep 2005 04:56:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04595 for ; Thu, 1 Sep 2005 04:56:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAktz-00063l-JY for ccamp-archive@ietf.org; Thu, 01 Sep 2005 04:58:41 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAkfo-000Alj-3F for ccamp-data@psg.com; Thu, 01 Sep 2005 08:43:52 +0000 Received: from [193.74.198.7] (helo=easics.be) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1EAkfm-000AlG-CW for ccamp@ops.ietf.org; Thu, 01 Sep 2005 08:43:50 +0000 Received: (qmail 22785 invoked from network); 1 Sep 2005 08:43:46 -0000 Received: from nestorix.easics.be (HELO [10.0.0.226]) (10.0.0.226) by duvel.easics.be with SMTP; Thu, 01 Sep 2005 10:43:46 +0200 Message-ID: <4316BF41.1070204@txc.com> Date: Thu, 01 Sep 2005 10:43:45 +0200 From: Bert Klaps Reply-To: bertk@txc.com User-Agent: Mozilla Thunderbird 1.0 (X11/20041215) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be CC: "Mack-Crane, T. Benjamin" , Adrian Farrel , Richard Rabbat , Huub van Helvoort , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF References: <43161377.4040804@psg.com> In-Reply-To: <43161377.4040804@psg.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Hi Dimitri, Note 2 refers to transparent STS-N/STM-N signals only (signal types 7 through 12), OIF is requesting clarification on the coding of STS-3c SPE versus VC-4 (both signal type 6). Since VC-4 == STS-3c SPE it should be possible to swap both terms without making a technical change which is not the case for examples 1 and 8. Any such difference is confusing and a potential interworking problem. Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc identical (examples 3 and 9) but not their base signal ?!?... Regards, Bert Klaps dimitri papadimitriou wrote: > ben, > > the purpose of the sentence you were initially pointing out addresses as > generic rule more than the specific case under discussion (reason why i > pointed to this note 2) from the initial clarification asked by the OIF > - ditto > > "Clarification is requested from IETF CCAMP as to which setting is > considered correct, or if both settings should be accepted (this > procedure was used during testing at Supercomm)." > > hence, any further discussion is involving much more than the requested > clarification since questioning the logic behind the settings specified > in this RFC; as these are pure conventions we may debated them forever, > however, it suffice that one logic gets consensus (with all what it > implies), which is the case otherwise this would have not become an RFC > > --- > > > Mack-Crane, T. Benjamin wrote: > >> Dimitri, >> >> Note 2 on page 6 refers to transparent mode, which is a >> different thing altogether. I think this encoding is >> poorly chosen as well (and may not allow for the full >> flexibility of equipment that provides various levels >> of transparent STS-N/STM-N switching), but that is not >> currently under discussion. >> >> Regards, >> Ben >> >>> -----Original Message----- >>> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] Sent: >>> Wednesday, August 31, 2005 2:38 PM >>> To: Mack-Crane, T. Benjamin >>> Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort; ccamp@ops.ietf.org >>> Subject: Re: Final draft of response to the OIF >>> >>> >>> to clarify: >>> >>> >>>> The example did not adhere to the rule RCC=1 implies NCC>1 >>>> which was stated in the RFC (and is technically sound) thus >>>> one could reasonable presume the example was in error. >>> >>> >>> actually your interpretation is not correct - see note 2 of RFC 3946 >>> (page 6) where the settings RCC=1 can imply NCC=1 is explicitly stated - >>> >>> this said, one of the reason for this setting wrt the specific point >>> raised by the OIF is due to the logic that has been used in making >>> use of RCC and NCC value when the signal spelling include a "c" i.e. >>> STS-(3xN)c SPE so for STS-3c SPE the setting is a logical consequence >>> of N = 1 >>> >>> however, editors have been using a wording for the generic rule which >>> has not been understood as expected hence the clarification stated >>> last march on this list - and reproduced in the bis version - >>> >>> in brief, all this doesn't deserve this flurry of e-mails wrt to the >>> specific point to be addressed >>> >>> >>> >>> >> >> ============================================================ >> 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 >> ============================================================ >> >> >> . >> > From owner-ccamp@ops.ietf.org Thu Sep 01 06:20:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAmBM-0003N1-Sb for ccamp-archive@megatron.ietf.org; Thu, 01 Sep 2005 06:20:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12340 for ; Thu, 1 Sep 2005 06:20:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAmDG-00005J-Ly for ccamp-archive@ietf.org; Thu, 01 Sep 2005 06:22:33 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAm4e-0003r8-HE for ccamp-data@psg.com; Thu, 01 Sep 2005 10:13:36 +0000 Received: from [128.87.251.113] (helo=smtpoutuk02.marconi.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAm4c-0003qt-Bs for ccamp@ops.ietf.org; Thu, 01 Sep 2005 10:13:34 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk02.marconi.com (8.12.11/8.12.11) with ESMTP id j81ADNSN011140; Thu, 1 Sep 2005 11:13:26 +0100 (envelope-from Diego.Caviglia@marconi.com) Subject: Comments on draft-kim-ccamp-cc-protection-04 To: ccamp@ops.ietf.org, yhwkim@etri.re.kr X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Thu, 1 Sep 2005 12:13:44 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 01/09/2005 11:13:21 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hi all, I'd like to make some comments on the ID in the subjec. Section 7 In general, there may be several advantages of out-of-fiber over in- fiber such as the followings: [dc] I don't agree with this sentence. I don't think that there are advantes in the usage of out-of-fiber. - When using the overhead bytes of SONET/SDH as a control channel, in-fiber may require more resources such as HDLC controllers whereas out-of-fiber could reduce the number of these resources; [dc] This is a strange sentece. SONET/SDH DCC have not been developed for GMPLS, are there since several years and seems very strange to me to think about a SONET/SDH box that do not support DCC processing. - In case of only in-fiber, it looks that there is no room or no need for protecting control channels. However, out-of-fiber may apply the various and effective software based protection schemes; [dc] Why there is no room for protecting control channels? Do you have any figures about this? The line level DCC is 576 kbps while the section DCC is 192 kbps. Do you thing the control traffic will be more than that? - In-fiber is difficult to separate control plane from transport plane, whereas out-of-fiber is easy to separate control plane; [dc] IMHO this is not true and moreover you need to explain why is more difficult. Today DCC are widely used to transport management traffic and there are no difficulties in order to separate management from data traffic. - Because in-fiber provides the connection control function only within a single fiber, in-fiber could not provide the connection control function beyond a single fiber, whereas out-of-fiber has no restriction about the number of fibers for the connection control function. [dc] Could you explain me a little bit more this? I don't see anything that prevent me to set-up more that one CC on a fiber. [quote] When the out-of-fiber configuration is used, control channels may be shared to handle several fibers [/quote] [dc] IMHO the cc are associated to the TE and not to the fibre, so a single CC can serve several TE link and thus several fibre; this is not related on how it is implemented. [quote] Consequently, to provide the resilience capability of control channels, it is reasonable to use out-of-fiber rather than in-fiber for GMPLS. [quote/] [dc] I don't see how the previous sentences can lead to this statement. What is reasonable is that the control channels must be resilient but this don't implies the fact they should be out-of-fiber. Regards Diego From owner-ccamp@ops.ietf.org Thu Sep 01 06:23:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAmE4-0004UL-DI for ccamp-archive@megatron.ietf.org; Thu, 01 Sep 2005 06:23:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12935 for ; Thu, 1 Sep 2005 06:23:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAmFv-0000BD-O4 for ccamp-archive@ietf.org; Thu, 01 Sep 2005 06:25:20 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAm9a-00053f-0s for ccamp-data@psg.com; Thu, 01 Sep 2005 10:18:42 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAm9X-00053N-Q6; Thu, 01 Sep 2005 10:18:40 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j81AIWDf031362; Thu, 1 Sep 2005 12:18:32 +0200 To: bertk@txc.com Cc: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Mack-Crane, T. Benjamin" , Adrian Farrel , Richard Rabbat , Huub van Helvoort , ccamp@ops.ietf.org MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Final draft of response to the OIF Date: Thu, 1 Sep 2005 12:18:30 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 09/01/2005 12:18:32 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_20_30, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_BASE64_TEXT,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 4.8 (++++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpLDxCUj4gPEJSPiZndDsgSGkgRGlt aXRyaSw8QlI+Jmd0OzxCUj4mZ3Q7IE5vdGUgMiByZWZlcnMgdG8gdHJhbnNwYXJlbnQgU1RTLU4v U1RNLU4gc2lnbmFscyBvbmx5IChzaWduYWwgdHlwZXMgNzxCUj4mZ3Q7IHRocm91Z2ggMTIpLCBP SUYgaXMgcmVxdWVzdGluZyBjbGFyaWZpY2F0aW9uIG9uIHRoZSBjb2Rpbmcgb2YgU1RTLTNjIFNQ RTxCUj4mZ3Q7IHZlcnN1cyBWQy00IChib3RoIHNpZ25hbCB0eXBlIDYpLjxCUj48L0ZPTlQ+PC9Q PjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj55ZXMsIGkgbm90aWNlZCA7LSkgdGhp cyB3YXMgbm90IHRoZSBwdXJwb3NlIG9mIG15IGZpcnN0IGNvbW1lbnQgPC9GT05UPjwvUD48UD48 Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+PEJSPiZndDsgU2luY2UgVkMtNCA9PSBTVFMt M2MgU1BFIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBzd2FwIGJvdGggdGVybXM8QlI+Jmd0OyB3 aXRob3V0IG1ha2luZyBhIHRlY2huaWNhbCBjaGFuZ2Ugd2hpY2ggaXMgbm90IHRoZSBjYXNlIGZv ciBleGFtcGxlcyAxPEJSPiZndDsgYW5kIDguIEFueSBzdWNoIGRpZmZlcmVuY2UgaXMgY29uZnVz aW5nIGFuZCBhIHBvdGVudGlhbCBpbnRlcndvcmtpbmc8QlI+Jmd0OyBwcm9ibGVtLjxCUj48L0ZP TlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5zbyB5b3UgY2FuIGZsZXhp YmlseSBzd2FwIGJldHdlZW4gbG9jYWwgY29uZmlndXJhdGlvbiBhbmQgbm90IGhhdmUgdGhhdCBm bGV4aWJpbGl0eSBpbiB0aGUgY29udHJvbCBwbGFuZSA/PC9GT05UPjwvUD48UD48Rk9OVCBGQUNF PSJNb25vc3BhY2UsQ291cmllciI+PEJSPiZndDsgU3RhbmRhcmQgY29udGlndW91cyBjb25jYXRl bmF0ZWQgU1RTLU5jIFNQRSBpcyBhY3R1YWxseSBTVFMtM2MtWGMgU1BFPEJSPiZndDsgd2l0aCBO PTNYIGFuZCBYPTQsMTYsNjQsLi4uIHdoaWNoIGV4cGxhaW5zIHRoZSBjb2Rpbmcgd2l0aCBhIFNU Uy0zYyBTUEU8QlI+Jmd0OyBlbGVtZW50YXJ5IHNpZ25hbCBhbmQgTkNDPVguIFNvIHdlIGNvZGUg dGhlIFNUUy1OYyBTUEUgYW5kIFZDLTQtWGM8QlI+Jmd0OyBpZGVudGljYWwgKGV4YW1wbGVzIDMg YW5kIDkpIGJ1dCBub3QgdGhlaXIgYmFzZSBzaWduYWwgPyE/Li4uPEJSPjwvRk9OVD48L1A+PFA+ PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmkgcmVmZXIgeW91IHRvIHNlY3Rpb24gNy4z LjEgb2YgQU5TSSBUMS4xMDUgLSAyMDAxIChha2EgU09ORVQgYmFzZSBzcGVjKSB5b3Ugd2lsbCB0 aGF0IHlvdXIgaW50ZXJwcmV0YXRpb24gaXMgbm90IHRoZSBvbmUgc3BlY2lmaWVkIGluIHRoaXMg cmVjb21tZW5kYXRpb248L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy Ij4mcXVvdDsgU3VwZXIgcmF0ZXMgc2VydmljZXMgYXJlIG1hcHBlZCBpbnRvIGFuZCB0cmFuc3Bv cnRlZCBhcyBTVFMtTmMgU1BFIFtOPTNYIHRoZXJlIFggPSAxLCA0LCAxNiwgNjQgb3IgMjU2XSZx dW90OzwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnRoaXMgaXMg ZXhhY3RseSB3aGF0IHdlIHVzZWQgaW4gUkZDIDM5NDY8L0ZPTlQ+PC9QPjxQPiZuYnNwOzwvUD48 UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+dGhhbmtzIGFuZCBnb29kIGJ5ZTwvRk9O VD48L1A+PFA+Jm5ic3A7PC9QPjxQPiZuYnNwOzwvUD48UD4mbmJzcDs8L1A+PFA+PEJSPjxGT05U IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5SZWdhcmRzLDxCUj5CZXJ0IEtsYXBzPEJSPjwvRk9O VD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmRpbWl0cmkgcGFwYWRpbWl0cmlv dSB3cm90ZTo8QlI+Jmd0OyBiZW4sPEJSPiZndDs8QlI+Jmd0OyB0aGUgcHVycG9zZSBvZiB0aGUg c2VudGVuY2UgeW91IHdlcmUgaW5pdGlhbGx5IHBvaW50aW5nIG91dCBhZGRyZXNzZXMgYXM8QlI+ Jmd0OyBnZW5lcmljIHJ1bGUgbW9yZSB0aGFuIHRoZSBzcGVjaWZpYyBjYXNlIHVuZGVyIGRpc2N1 c3Npb24gKHJlYXNvbiB3aHkgaTxCUj4mZ3Q7IHBvaW50ZWQgdG8gdGhpcyBub3RlIDIpIGZyb20g dGhlIGluaXRpYWwgY2xhcmlmaWNhdGlvbiBhc2tlZCBieSB0aGUgT0lGPEJSPiZndDsgLSBkaXR0 bzxCUj4mZ3Q7PEJSPiZndDsgJnF1b3Q7Q2xhcmlmaWNhdGlvbiBpcyByZXF1ZXN0ZWQgZnJvbSBJ RVRGIENDQU1QIGFzIHRvIHdoaWNoIHNldHRpbmcgaXM8QlI+Jmd0OyBjb25zaWRlcmVkIGNvcnJl Y3QsIG9yIGlmIGJvdGggc2V0dGluZ3Mgc2hvdWxkIGJlIGFjY2VwdGVkICh0aGlzPEJSPiZndDsg cHJvY2VkdXJlIHdhcyB1c2VkIGR1cmluZyB0ZXN0aW5nIGF0IFN1cGVyY29tbSkuJnF1b3Q7PEJS PiZndDs8QlI+Jmd0OyBoZW5jZSwgYW55IGZ1cnRoZXIgZGlzY3Vzc2lvbiBpcyBpbnZvbHZpbmcg bXVjaCBtb3JlIHRoYW4gdGhlIHJlcXVlc3RlZDxCUj4mZ3Q7IGNsYXJpZmljYXRpb24gc2luY2Ug cXVlc3Rpb25pbmcgdGhlIGxvZ2ljIGJlaGluZCB0aGUgc2V0dGluZ3Mgc3BlY2lmaWVkPEJSPiZn dDsgaW4gdGhpcyBSRkM7IGFzIHRoZXNlIGFyZSBwdXJlIGNvbnZlbnRpb25zIHdlIG1heSBkZWJh dGVkIHRoZW0gZm9yZXZlciw8QlI+Jmd0OyBob3dldmVyLCBpdCBzdWZmaWNlIHRoYXQgb25lIGxv Z2ljIGdldHMgY29uc2Vuc3VzICh3aXRoIGFsbCB3aGF0IGl0PEJSPiZndDsgaW1wbGllcyksIHdo aWNoIGlzIHRoZSBjYXNlIG90aGVyd2lzZSB0aGlzIHdvdWxkIGhhdmUgbm90IGJlY29tZSBhbiBS RkM8QlI+Jmd0OzxCUj4mZ3Q7IC0tLTxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBNYWNrLUNyYW5l LCBULiBCZW5qYW1pbiB3cm90ZTo8QlI+Jmd0OzxCUj4mZ3Q7Jmd0OyBEaW1pdHJpLDxCUj4mZ3Q7 Jmd0OzxCUj4mZ3Q7Jmd0OyBOb3RlIDIgb24gcGFnZSA2IHJlZmVycyB0byB0cmFuc3BhcmVudCBt b2RlLCB3aGljaCBpcyBhPEJSPiZndDsmZ3Q7IGRpZmZlcmVudCB0aGluZyBhbHRvZ2V0aGVyLiAm bmJzcDtJIHRoaW5rIHRoaXMgZW5jb2RpbmcgaXM8QlI+Jmd0OyZndDsgcG9vcmx5IGNob3NlbiBh cyB3ZWxsIChhbmQgbWF5IG5vdCBhbGxvdyBmb3IgdGhlIGZ1bGw8QlI+Jmd0OyZndDsgZmxleGli aWxpdHkgb2YgZXF1aXBtZW50IHRoYXQgcHJvdmlkZXMgdmFyaW91cyBsZXZlbHM8QlI+Jmd0OyZn dDsgb2YgdHJhbnNwYXJlbnQgU1RTLU4vU1RNLU4gc3dpdGNoaW5nKSwgYnV0IHRoYXQgaXMgbm90 PEJSPiZndDsmZ3Q7IGN1cnJlbnRseSB1bmRlciBkaXNjdXNzaW9uLjxCUj4mZ3Q7Jmd0OzxCUj4m Z3Q7Jmd0OyBSZWdhcmRzLDxCUj4mZ3Q7Jmd0OyBCZW48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZndDsmZ3Q7Jmd0OyBGcm9tOiBkaW1p dHJpIHBhcGFkaW1pdHJpb3UgW21haWx0bzpkcGFwYWRpbWl0cmlvdUBwc2cuY29tXSBTZW50OjxC Uj4mZ3Q7Jmd0OyZndDsgV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMDUgMjozOCBQTTxCUj4mZ3Q7 Jmd0OyZndDsgVG86IE1hY2stQ3JhbmUsIFQuIEJlbmphbWluPEJSPiZndDsmZ3Q7Jmd0OyBDYzog QWRyaWFuIEZhcnJlbDsgUmljaGFyZCBSYWJiYXQ7IEh1dWIgdmFuIEhlbHZvb3J0OyBjY2FtcEBv cHMuaWV0Zi5vcmc8QlI+Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBGaW5hbCBkcmFmdCBvZiBy ZXNwb25zZSB0byB0aGUgT0lGPEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0 OyZndDsmZ3Q7IHRvIGNsYXJpZnk6PEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDs8QlI+ Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgZXhhbXBsZSBkaWQgbm90IGFkaGVyZSB0byB0aGUgcnVsZSBS Q0M9MSBpbXBsaWVzIE5DQyZndDsxPEJSPiZndDsmZ3Q7Jmd0OyZndDsgd2hpY2ggd2FzIHN0YXRl ZCBpbiB0aGUgUkZDIChhbmQgaXMgdGVjaG5pY2FsbHkgc291bmQpIHRodXM8QlI+Jmd0OyZndDsm Z3Q7Jmd0OyBvbmUgY291bGQgcmVhc29uYWJsZSBwcmVzdW1lIHRoZSBleGFtcGxlIHdhcyBpbiBl cnJvci48QlI+Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDsgYWN0 dWFsbHkgeW91ciBpbnRlcnByZXRhdGlvbiBpcyBub3QgY29ycmVjdCAtIHNlZSBub3RlIDIgb2Yg UkZDIDM5NDY8QlI+Jmd0OyZndDsmZ3Q7IChwYWdlIDYpIHdoZXJlIHRoZSBzZXR0aW5ncyBSQ0M9 MSBjYW4gaW1wbHkgTkNDPTEgaXMgZXhwbGljaXRseSBzdGF0ZWQgLTxCUj4mZ3Q7Jmd0OyZndDs8 QlI+Jmd0OyZndDsmZ3Q7IHRoaXMgc2FpZCwgb25lIG9mIHRoZSByZWFzb24gZm9yIHRoaXMgc2V0 dGluZyB3cnQgdGhlIHNwZWNpZmljIHBvaW50PEJSPiZndDsmZ3Q7Jmd0OyByYWlzZWQgYnkgdGhl IE9JRiBpcyBkdWUgdG8gdGhlIGxvZ2ljIHRoYXQgaGFzIGJlZW4gdXNlZCBpbiBtYWtpbmc8QlI+ Jmd0OyZndDsmZ3Q7IHVzZSBvZiBSQ0MgYW5kIE5DQyB2YWx1ZSB3aGVuIHRoZSBzaWduYWwgc3Bl bGxpbmcgaW5jbHVkZSBhICZxdW90O2MmcXVvdDsgaS5lLjxCUj4mZ3Q7Jmd0OyZndDsgU1RTLSgz eE4pYyBTUEUgc28gZm9yIFNUUy0zYyBTUEUgdGhlIHNldHRpbmcgaXMgYSBsb2dpY2FsIGNvbnNl cXVlbmNlPEJSPiZndDsmZ3Q7Jmd0OyBvZiBOID0gMTxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0OyZn dDsmZ3Q7IGhvd2V2ZXIsIGVkaXRvcnMgaGF2ZSBiZWVuIHVzaW5nIGEgd29yZGluZyBmb3IgdGhl IGdlbmVyaWMgcnVsZSB3aGljaDxCUj4mZ3Q7Jmd0OyZndDsgaGFzIG5vdCBiZWVuIHVuZGVyc3Rv b2QgYXMgZXhwZWN0ZWQgaGVuY2UgdGhlIGNsYXJpZmljYXRpb24gc3RhdGVkPEJSPiZndDsmZ3Q7 Jmd0OyBsYXN0IG1hcmNoIG9uIHRoaXMgbGlzdCAtIGFuZCByZXByb2R1Y2VkIGluIHRoZSBiaXMg dmVyc2lvbiAtPEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDsgaW4gYnJpZWYsIGFsbCB0 aGlzIGRvZXNuJ3QgZGVzZXJ2ZSB0aGlzIGZsdXJyeSBvZiBlLW1haWxzIHdydCB0byB0aGU8QlI+ Jmd0OyZndDsmZ3Q7IHNwZWNpZmljIHBvaW50IHRvIGJlIGFkZHJlc3NlZDxCUj4mZ3Q7Jmd0OyZn dDs8QlI+Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0 OyZndDs8QlI+Jmd0OyZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PEJSPiZndDsmZ3Q7IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBwcml2aWxlZ2VkPEJSPiZndDsmZ3Q7IGFuZCBjb25m aWRlbnRpYWwgYW5kIHByb3RlY3RlZCBmcm9tIGRpc2Nsb3N1cmUuIElmIHRoZSByZWFkZXI8QlI+ Jmd0OyZndDsgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBv ciBhbiBlbXBsb3llZTxCUj4mZ3Q7Jmd0OyBvciBhZ2VudCByZXNwb25zaWJsZSBmb3IgZGVsaXZl cmluZyB0aGlzIG1lc3NhZ2UgdG8gdGhlPEJSPiZndDsmZ3Q7IGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgcmVwcm9kdWN0aW9uLDxCUj4mZ3Q7Jmd0 OyBkaXNzZW1pbmF0aW9uIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMg c3RyaWN0bHk8QlI+Jmd0OyZndDsgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluIGVycm9yLDxCUj4mZ3Q7Jmd0OyBwbGVhc2Ugbm90aWZ5IHVzIGlt bWVkaWF0ZWx5IGJ5IHJlcGx5aW5nIHRvIHRoZSBtZXNzYWdlIGFuZDxCUj4mZ3Q7Jmd0OyBkZWxl dGluZyBpdCBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4gVGVsbGFiczxCUj4mZ3Q7Jmd0 OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgLjxCUj4mZ3Q7Jmd0OzxC Uj4mZ3Q7PC9GT05UPjwvUD4= From owner-ccamp@ops.ietf.org Thu Sep 01 06:52:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAmg7-00083e-QF for ccamp-archive@megatron.ietf.org; Thu, 01 Sep 2005 06:52:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20522 for ; Thu, 1 Sep 2005 06:52:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAmi1-0001H8-PA for ccamp-archive@ietf.org; Thu, 01 Sep 2005 06:54:20 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAmas-000Acd-QK for ccamp-data@psg.com; Thu, 01 Sep 2005 10:46:54 +0000 Received: from [213.46.243.17] (helo=amsfep12-int.chello.nl) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAmao-000AcN-Cn for ccamp@ops.ietf.org; Thu, 01 Sep 2005 10:46:50 +0000 Received: from [192.168.1.2] (really [24.132.27.149]) by amsfep12-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050901104638.CBSK2093.amsfep12-int.chello.nl@[192.168.1.2]>; Thu, 1 Sep 2005 12:46:38 +0200 Message-ID: <4316DC09.3010801@chello.nl> Date: Thu, 01 Sep 2005 12:46:33 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: bertk@txc.com, dpapadimitriou@psg.com, Adrian Farrel , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Hello Dimitri, You quoted T1.105: --8<-- snipped > > Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE > > with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE > > elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc > > identical (examples 3 and 9) but not their base signal ?!?... > > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET base spec) > you will that your interpretation is not the one specified in this > recommendation > > " Super rates services are mapped into and transported as STS-Nc SPE > [N=3X there X = 1, 4, 16, 64 or 256]" Somehow you left out the last part between the square brackets: "or SDH VC-4 or VC-4-Xc, where X=N/3]" This clearly means that an STS-3c == VC-4 == super rate of STS-1. > this is exactly what we used in RFC 3946 -- ================================================================ http://www.gironet.nl/home/idefiks/ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Thu Sep 01 07:59:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAnjW-00026Y-FA for ccamp-archive@megatron.ietf.org; Thu, 01 Sep 2005 07:59:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28962 for ; Thu, 1 Sep 2005 07:59:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAnlR-0003bt-0J for ccamp-archive@ietf.org; Thu, 01 Sep 2005 08:01:55 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAncY-000P7B-EG for ccamp-data@psg.com; Thu, 01 Sep 2005 11:52:42 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAncU-000P6c-KR; Thu, 01 Sep 2005 11:52:38 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j81BqWDf017961; Thu, 1 Sep 2005 13:52:32 +0200 To: Huub van Helvoort Cc: Dimitri.Papadimitriou@alcatel.be, bertk@txc.com, dpapadimitriou@psg.com, Adrian Farrel , ccamp@ops.ietf.org MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Final draft of response to the OIF Date: Thu, 1 Sep 2005 13:52:31 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 09/01/2005 13:52:32 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_20_30, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_BASE64_TEXT,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 4.8 (++++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmh1dWIsIDxCUj48QlI+Jmd0OyAmZ3Q7 ICZndDsgU3RhbmRhcmQgY29udGlndW91cyBjb25jYXRlbmF0ZWQgU1RTLU5jIFNQRSBpcyBhY3R1 YWxseSBTVFMtM2MtWGMgU1BFPEJSPiZndDsgJmd0OyAmZ3Q7IHdpdGggTj0zWCBhbmQgWD00LDE2 LDY0LC4uLiB3aGljaCBleHBsYWlucyB0aGUgY29kaW5nIHdpdGggYSBTVFMtM2MgU1BFPEJSPiZn dDsgJmd0OyAmZ3Q7IGVsZW1lbnRhcnkgc2lnbmFsIGFuZCBOQ0M9WC4gU28gd2UgY29kZSB0aGUg U1RTLU5jIFNQRSBhbmQgVkMtNC1YYzxCUj4mZ3Q7ICZndDsgJmd0OyBpZGVudGljYWwgKGV4YW1w bGVzIDMgYW5kIDkpIGJ1dCBub3QgdGhlaXIgYmFzZSBzaWduYWwgPyE/Li4uPEJSPiZndDsgJmd0 OzxCUj4mZ3Q7ICZndDsgaSByZWZlciB5b3UgdG8gc2VjdGlvbiA3LjMuMSBvZiBBTlNJIFQxLjEw NSAtIDIwMDEgKGFrYSBTT05FVCBiYXNlIHNwZWMpPEJSPiZndDsgJmd0OyB5b3Ugd2lsbCB0aGF0 IHlvdXIgaW50ZXJwcmV0YXRpb24gaXMgbm90IHRoZSBvbmUgc3BlY2lmaWVkIGluIHRoaXM8QlI+ Jmd0OyAmZ3Q7IHJlY29tbWVuZGF0aW9uPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJnF1b3Q7 IFN1cGVyIHJhdGVzIHNlcnZpY2VzIGFyZSBtYXBwZWQgaW50byBhbmQgdHJhbnNwb3J0ZWQgYXMg U1RTLU5jIFNQRTxCUj4mZ3Q7ICZndDsgW049M1ggdGhlcmUgWCA9IDEsIDQsIDE2LCA2NCBvciAy NTZdJnF1b3Q7PEJSPiZndDs8QlI+Jmd0OyBTb21laG93IHlvdSBsZWZ0IG91dCB0aGUgbGFzdCBw YXJ0IGJldHdlZW4gdGhlIHNxdWFyZSBicmFja2V0czo8QlI+Jmd0OyAmcXVvdDtvciBTREggVkMt NCBvciBWQy00LVhjLCB3aGVyZSBYPU4vM10mcXVvdDs8QlI+Jmd0OzxCUj4mZ3Q7IFRoaXMgY2xl YXJseSBtZWFucyB0aGF0IGFuIFNUUy0zYyA9PSBWQy00ID09IHN1cGVyIHJhdGUgb2YgU1RTLTEu PEJSPjwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmluZGVlZCBi dXQgd2UgYXJlIG5vdCBkaXNjdXNzaW5nIHRoaXMgaXNzdWUgb3IgcHV0IHRoaXMgJnF1b3Q7ZXF1 aXZhbGVuY2UmcXVvdDsgdW5kZXIgcXVlc3Rpb25pbmcgKGluIGZhY3QgdGhpcyBpcyByZXByb2R1 Y2VkIGluIHRoZSBzaWduYWwgdHlwZSA2IGRlZmluaXRpb24pIHRoZSBSRkMgdG9vayBhcyBsb2dp YyAoY29udHJvbCBwbGFuZSkgdG8gc2V0IHRoZSBSQ0MgdmFsdWUgd2hlbiB0aGUgbm90YXRpb24g b2YgdGhlIHNpZ25hbCBpbmNsdWRlZCBhICZxdW90O2MmcXVvdDsgd2UgY291bGQgaGF2ZSBjcmVh dGVkIHlldCBhbm90aGVyIGV4Y2VwdGlvbiBidXQgd2UgZGlkIG5vdCAtIGZvciBzZXZlcmFsIHJl YXNvbnMgLTwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjxCUj4m Z3Q7ICZndDsgdGhpcyBpcyBleGFjdGx5IHdoYXQgd2UgdXNlZCBpbiBSRkMgMzk0NjxCUj48L0ZP TlQ+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+LS08QlI+PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwv Rk9OVD48L1A+PFVMPjxVTD48VUw+PFVMPjxVTD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmll ciI+PEEgSFJFRj1odHRwOi8vd3d3Lmdpcm9uZXQubmwvaG9tZS9pZGVmaWtzLz5odHRwOi8vd3d3 Lmdpcm9uZXQubmwvaG9tZS9pZGVmaWtzLzwvQT48QlI+PEEgSFJFRj1odHRwOi8vbWVtYmVycy5j aGVsbG8ubmwvaGhlbHZvb3J0Lz5odHRwOi8vbWVtYmVycy5jaGVsbG8ubmwvaGhlbHZvb3J0Lzwv QT48L0ZPTlQ+PC9VTD48L1VMPjwvVUw+PC9VTD48L1VMPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFj ZSxDb3VyaWVyIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PEJSPkFsd2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUgdW5pcXVl Li4uanVzdCBsaWtlIGV2ZXJ5b25lIGVsc2UuLi48L0ZPTlQ+PC9QPg== From owner-ccamp@ops.ietf.org Thu Sep 01 10:32:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAq7O-0001dS-W7 for ccamp-archive@megatron.ietf.org; Thu, 01 Sep 2005 10:32:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07896 for ; Thu, 1 Sep 2005 10:32:41 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAq9G-0000F8-8a for ccamp-archive@ietf.org; Thu, 01 Sep 2005 10:34:45 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAq1w-00076R-O4 for ccamp-data@psg.com; Thu, 01 Sep 2005 14:27:04 +0000 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAq1u-000764-GY for ccamp@ops.ietf.org; Thu, 01 Sep 2005 14:27:02 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 01 Sep 2005 14:40:29 +0000 X-SBRS: None X-IronPort-AV: i="3.96,161,1122854400"; d="scan'208,217"; a="27498645:sNHT33270180" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Sep 2005 09:27:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AF01.36D2C69E" Subject: RE: Final draft of response to the OIF Date: Thu, 1 Sep 2005 09:26:34 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWu7BNpifROSQ+hSAa9OevYQ0xcNAAFFmXw From: "Mack-Crane, T. Benjamin" To: , "Huub van Helvoort" Cc: , , "Adrian Farrel" , X-OriginalArrivalTime: 01 Sep 2005 14:27:01.0768 (UTC) FILETIME=[37E79880:01C5AF01] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AF01.36D2C69E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dimitri, The control plane is intended to control the data plane, not the naming of data plane signals in various standards. The fact that two names are used in SONET and SDH for the same data plane signal is not justification for creating two encodings in the control plane. This should be a simple thing to fix, if we (CCAMP) are willing to fix it. Regards, Ben ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Dimitri.Papadimitriou@alcatel.be Sent: Thursday, September 01, 2005 6:53 AM To: Huub van Helvoort Cc: Dimitri.Papadimitriou@alcatel.be; bertk@txc.com; dpapadimitriou@psg.com; Adrian Farrel; ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF huub, > > > Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE > > > with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE > > > elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc > > > identical (examples 3 and 9) but not their base signal ?!?... > > > > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET base spec) > > you will that your interpretation is not the one specified in this > > recommendation > > > > " Super rates services are mapped into and transported as STS-Nc SPE > > [N=3X there X = 1, 4, 16, 64 or 256]" > > Somehow you left out the last part between the square brackets: > "or SDH VC-4 or VC-4-Xc, where X=N/3]" > > This clearly means that an STS-3c == VC-4 == super rate of STS-1. indeed but we are not discussing this issue or put this "equivalence" under questioning (in fact this is reproduced in the signal type 6 definition) the RFC took as logic (control plane) to set the RCC value when the notation of the signal included a "c" we could have created yet another exception but we did not - for several reasons - > > this is exactly what we used in RFC 3946 -- ================================================================ http://www.gironet.nl/home/idefiks/ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... ============================================================ 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 ============================================================ ------_=_NextPart_001_01C5AF01.36D2C69E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Dimitri,
 
The control plane is intended to control the data plane, not the naming of data plane signals in various standards.  The fact that two names are used in SONET and SDH for the same data plane signal is not justification for creating two encodings in the control plane.
 
This should be a simple thing to fix, if we (CCAMP) are willing to fix it.
 
Regards,
Ben

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Thursday, September 01, 2005 6:53 AM
To: Huub van Helvoort
Cc: Dimitri.Papadimitriou@alcatel.be; bertk@txc.com; dpapadimitriou@psg.com; Adrian Farrel; ccamp@ops.ietf.org
Subject: Re: Final draft of response to the OIF

huub,

> > > Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE
> > > with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE
> > > elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc
> > > identical (examples 3 and 9) but not their base signal ?!?...
> >
> > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET base spec)
> > you will that your interpretation is not the one specified in this
> > recommendation
> >
> > " Super rates services are mapped into and transported as STS-Nc SPE
> > [N=3X there X = 1, 4, 16, 64 or 256]"
>
> Somehow you left out the last part between the square brackets:
> "or SDH VC-4 or VC-4-Xc, where X=N/3]"
>
> This clearly means that an STS-3c == VC-4 == super rate of STS-1.

indeed but we are not discussing this issue or put this "equivalence" under questioning (in fact this is reproduced in the signal type 6 definition) the RFC took as logic (control plane) to set the RCC value when the notation of the signal included a "c" we could have created yet another exception but we did not - for several reasons -


> > this is exactly what we used in RFC 3946


--
================================================================

================================================================
Always remember that you are unique...just like everyone else...

============================================================
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
============================================================
------_=_NextPart_001_01C5AF01.36D2C69E-- From owner-ccamp@ops.ietf.org Thu Sep 01 10:32:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAq7R-0001hM-UI for ccamp-archive@megatron.ietf.org; Thu, 01 Sep 2005 10:32:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07901 for ; Thu, 1 Sep 2005 10:32:44 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAq9P-0000Fv-Qv for ccamp-archive@ietf.org; Thu, 01 Sep 2005 10:34:48 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EApro-0004wi-4P for ccamp-data@psg.com; Thu, 01 Sep 2005 14:16:36 +0000 Received: from [193.74.198.7] (helo=easics.be) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1EAprl-0004wP-Mw for ccamp@ops.ietf.org; Thu, 01 Sep 2005 14:16:34 +0000 Received: (qmail 310 invoked from network); 1 Sep 2005 14:16:32 -0000 Received: from nestorix.easics.be (HELO [10.0.0.226]) (10.0.0.226) by duvel.easics.be with SMTP; Thu, 01 Sep 2005 16:16:32 +0200 Message-ID: <43170D40.90208@txc.com> Date: Thu, 01 Sep 2005 16:16:32 +0200 From: Bert Klaps Reply-To: bertk@txc.com User-Agent: Mozilla Thunderbird 1.0 (X11/20041215) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: dpapadimitriou@psg.com, "Mack-Crane, T. Benjamin" , Adrian Farrel , Richard Rabbat , Huub van Helvoort , ccamp@ops.ietf.org Subject: Re: {Spam?} Re: Final draft of response to the OIF References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 7bit Hi Dimitri, Dimitri.Papadimitriou@alcatel.be wrote: > > Note 2 refers to transparent STS-N/STM-N signals only (signal types 7 > > through 12), OIF is requesting clarification on the coding of STS-3c SPE > > versus VC-4 (both signal type 6). > > yes, i noticed ;-) this was not the purpose of my first comment > > > Since VC-4 == STS-3c SPE it should be possible to swap both terms > > without making a technical change which is not the case for examples 1 > > and 8. Any such difference is confusing and a potential interworking > > problem. > > so you can flexibily swap between local configuration and not have that > flexibility in the control plane ? This way the control plane will make a distinction which is not present in the data plane and therefore will confuse. > > Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE > > with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE > > elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc > > identical (examples 3 and 9) but not their base signal ?!?... > > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET base spec) > you will that your interpretation is not the one specified in this > recommendation Er, I'm quite familiar with the contents of T1.105-2001 ;-) That content doesn't change my observations about the signal structure above. Note that T1.105 at multiple locations states the VC-4 == STS-3c SPE equivalence. E.g. from the definitions: 3.5 "The equivalent SDH term for an STS-3c SPE is a VC-4. The equivalent SDH term for an STS-Nc (N>3) SPE is a VC-4-Xc, where X=N/3." or, 3.73 "A VC-4 is equivalent to an STS-3c SPE, and a VC-4-Xc is equivalent to an STS-Nc (N=3X) SPE." > " Super rates services are mapped into and transported as STS-Nc SPE > [N=3X there X = 1, 4, 16, 64 or 256]" This is a list of signal names with a "c" in them, as you put it. You have to look at the figures to understand the signal structure and how they relate to each other, which was my point. Also from 7.3: "Two methods for concatenation are defined; contiguous and virtual concatenation. Both methods provide concatenated bandwidth of X times the SPE payload capacity at the path termination." A STS-Nc SPE has a payload capicity of X times the payload capacity of a STS-3c SPE with N=3X. However a STS-Nc SPE does _not_ have a payload capacity of N times the payload capacity of a STS-1 SPE, not even for N=3... > this is exactly what we used in RFC 3946 Regards, Bert Klaps > dimitri papadimitriou wrote: > > ben, > > > > the purpose of the sentence you were initially pointing out addresses as > > generic rule more than the specific case under discussion (reason why i > > pointed to this note 2) from the initial clarification asked by the OIF > > - ditto > > > > "Clarification is requested from IETF CCAMP as to which setting is > > considered correct, or if both settings should be accepted (this > > procedure was used during testing at Supercomm)." > > > > hence, any further discussion is involving much more than the requested > > clarification since questioning the logic behind the settings specified > > in this RFC; as these are pure conventions we may debated them forever, > > however, it suffice that one logic gets consensus (with all what it > > implies), which is the case otherwise this would have not become an RFC > > > > --- > > > > > > Mack-Crane, T. Benjamin wrote: > > > >> Dimitri, > >> > >> Note 2 on page 6 refers to transparent mode, which is a > >> different thing altogether. I think this encoding is > >> poorly chosen as well (and may not allow for the full > >> flexibility of equipment that provides various levels > >> of transparent STS-N/STM-N switching), but that is not > >> currently under discussion. > >> > >> Regards, > >> Ben > >> > >>> -----Original Message----- > >>> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] Sent: > >>> Wednesday, August 31, 2005 2:38 PM > >>> To: Mack-Crane, T. Benjamin > >>> Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort; > ccamp@ops.ietf.org > >>> Subject: Re: Final draft of response to the OIF > >>> > >>> > >>> to clarify: > >>> > >>> > >>>> The example did not adhere to the rule RCC=1 implies NCC>1 > >>>> which was stated in the RFC (and is technically sound) thus > >>>> one could reasonable presume the example was in error. > >>> > >>> > >>> actually your interpretation is not correct - see note 2 of RFC 3946 > >>> (page 6) where the settings RCC=1 can imply NCC=1 is explicitly > stated - > >>> > >>> this said, one of the reason for this setting wrt the specific point > >>> raised by the OIF is due to the logic that has been used in making > >>> use of RCC and NCC value when the signal spelling include a "c" i.e. > >>> STS-(3xN)c SPE so for STS-3c SPE the setting is a logical consequence > >>> of N = 1 > >>> > >>> however, editors have been using a wording for the generic rule which > >>> has not been understood as expected hence the clarification stated > >>> last march on this list - and reproduced in the bis version - > >>> > >>> in brief, all this doesn't deserve this flurry of e-mails wrt to the > >>> specific point to be addressed > >>> > >>> > >>> > >>> > >> > >> ============================================================ > >> 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 > >> ============================================================ > >> > >> > >> . > >> > > > From owner-ccamp@ops.ietf.org Thu Sep 01 13:46:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAt8j-0007Iw-Nt for ccamp-archive@megatron.ietf.org; Thu, 01 Sep 2005 13:46:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16918 for ; Thu, 1 Sep 2005 13:46:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAtAc-0006L2-VZ for ccamp-archive@ietf.org; Thu, 01 Sep 2005 13:48:21 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAsxw-000N9O-Tk for ccamp-data@psg.com; Thu, 01 Sep 2005 17:35:08 +0000 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAsxu-000N91-T7 for ccamp@ops.ietf.org; Thu, 01 Sep 2005 17:35:07 +0000 Received: from [192.168.0.100] (c-67-170-201-38.hsd1.ca.comcast.net [67.170.201.38]) (authenticated bits=0) by pro.abac.com (8.13.4/8.13.4) with ESMTP id j81HYnUk017164; Thu, 1 Sep 2005 10:34:53 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <43173BBA.4020608@grotto-networking.com> Date: Thu, 01 Sep 2005 10:34:50 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mack-Crane, T. Benjamin" CC: Dimitri.Papadimitriou@alcatel.be, Huub van Helvoort , bertk@txc.com, dpapadimitriou@psg.com, Adrian Farrel , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.51 on 66.226.64.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Concur with Ben and Huub. This is also why all current framer chips support both SONET and SDH. STS-3c == VC-4. Greg B. Mack-Crane, T. Benjamin wrote: > Dimitri, > > The control plane is intended to control the data plane, not the > naming of data plane signals in various standards. The fact that two > names are used in SONET and SDH for the same data plane signal is not > justification for creating two encodings in the control plane. > > This should be a simple thing to fix, if we (CCAMP) are willing to fix it. > > Regards, > Ben > > ------------------------------------------------------------------------ > *From:* owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] > *On Behalf Of *Dimitri.Papadimitriou@alcatel.be > *Sent:* Thursday, September 01, 2005 6:53 AM > *To:* Huub van Helvoort > *Cc:* Dimitri.Papadimitriou@alcatel.be; bertk@txc.com; > dpapadimitriou@psg.com; Adrian Farrel; ccamp@ops.ietf.org > *Subject:* Re: Final draft of response to the OIF > > huub, > > > > > Standard contiguous concatenated STS-Nc SPE is actually > STS-3c-Xc SPE > > > > with N=3X and X=4,16,64,... which explains the coding with a > STS-3c SPE > > > > elementary signal and NCC=X. So we code the STS-Nc SPE and > VC-4-Xc > > > > identical (examples 3 and 9) but not their base signal ?!?... > > > > > > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET > base spec) > > > you will that your interpretation is not the one specified in this > > > recommendation > > > > > > " Super rates services are mapped into and transported as > STS-Nc SPE > > > [N=3X there X = 1, 4, 16, 64 or 256]" > > > > Somehow you left out the last part between the square brackets: > > "or SDH VC-4 or VC-4-Xc, where X=N/3]" > > > > This clearly means that an STS-3c == VC-4 == super rate of STS-1. > > indeed but we are not discussing this issue or put this > "equivalence" under questioning (in fact this is reproduced in the > signal type 6 definition) the RFC took as logic (control plane) to > set the RCC value when the notation of the signal included a "c" > we could have created yet another exception but we did not - for > several reasons - > > > > > this is exactly what we used in RFC 3946 > > > -- > ================================================================ > > http://www.gironet.nl/home/idefiks/ > http://members.chello.nl/hhelvoort/ > > ================================================================ > Always remember that you are unique...just like everyone else... > >============================================================ >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 >============================================================ > > From owner-ccamp@ops.ietf.org Sun Sep 04 12:13:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBx7f-0002Fi-0m for ccamp-archive@megatron.ietf.org; Sun, 04 Sep 2005 12:13:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12769 for ; Sun, 4 Sep 2005 12:13:32 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBxA8-0001lC-It for ccamp-archive@ietf.org; Sun, 04 Sep 2005 12:16:16 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EBwxm-000E0H-Qr for ccamp-data@psg.com; Sun, 04 Sep 2005 16:03:22 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EBwxl-000E00-K8 for ccamp@ops.ietf.org; Sun, 04 Sep 2005 16:03:21 +0000 Received: from du-069-0055.access.clara.net ([217.158.132.55] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1EBwxi-00062A-H4 for ccamp@ops.ietf.org; Sun, 04 Sep 2005 17:03:20 +0100 Message-ID: <00d901c5b16a$8bc37760$93849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <43173BBA.4020608@grotto-networking.com> Subject: Re: Final draft of response to the OIF Date: Sun, 4 Sep 2005 17:04:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit OK. So I see two questions here. 1. What is meant by RFC3946? 2. Do we want to change what is said by RFC3946? Question 1 appears to be the question that was asked by the OIF. I think we have a clear answer. I think some people are not happy with this answer, but that feeds into question 2. My understanding of the answer to question 1 is based on the input from the editors of the RFC and reading the CCAMP archive. Thus, the response to the question from the OIF is as follows: This question about RFC 3946 was raised informally on the CCAMP mailing list at the start of March this year. Even when the signal Type value is the same (i.e. value 6) the NCC, RCC and NVC values depend on the specific signal being requested. From the examples in the annex we have... A VC-4 signal is formed by applying the following settings to a VC-4 Elementary Signal. RCC = 0 NCC = 0 NVC = 0 MT = 1 T = 0 An STS-3c SPE signal is formed by applying the following settings to an STS-3c SPE Elementary Signal. RCC = 1 (standard contiguous concatenation) NCC = 1 NVC = 0 MT = 1 T = 0 Your question probably arises from the two notes and subsequent paragraph in section 2.1 or RFC 3946. Here it says... Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the Elementary Signal to use must always be an STS-3c_SPE signal type and the value of NCC must always be equal to X. This allows also facilitating the interworking between SONET and SDH. In particular, it means that the contiguous concatenation of three STS-1 SPEs can not be requested because according to this specification, this type of signal must be coded using the STS-3c SPE signal type. Note 2: when requesting a transparent STS-N/STM-N signal limited to a single contiguously concatenated STS-Nc_SPE/ VC-4-Nc, the signal type must be STS-N/STM-N, RCC with flag 1 and NCC set to 1. The NCC value must be consistent with the type of contiguous concatenation being requested in the RCC field. In particular, this field is irrelevant if no contiguous concatenation is requested (RCC = 0), in that case it must be set to zero when sent, and should be ignored when received. A RCC value different from 0 must imply a number of contiguous components greater than 1. This final sentence should read "greater than or equal to 1," and was mistyped in the RFC. This change resolves all of your questions and makes the text consistent with the examples. The CCAMP working group is discussing a revision to RFC 3946 to clarify the situation. Question 2 is a different issue. Quite a few people have stated that they believe that RFC 3946 with its current interpretation by the editors, should be changed. At the moment I do not see consensus on this issue and frankly I do not see any weighty reason to change although if the community shows consensus in favor of a change, that would be fine *if* someone does the work. My observations on this point are as follows. a. This is control plane code. It is definitively not relevant to any interworking in the data plane. So long as it is written down clearly, *any* unambiguous control plane encoding is adequate. b. Even if the data plane signal is identical, there may be value in distinguishing between the SDH and SONET origins of the signal. c. We MUST support existing implementations. That means that whatever encoding rules we end up with, we MUST continue to support the receipt of existing encoding. It seems to me that this dilutes the purpose of any change. d. Regardless of the definition of the signal encodings, and regardless of whether fields with the same names are used in the definition of those signals, I find the textual descriptions of NCC and RCC in RFC 3946 unambiguous in English. It may be that those descriptions should be changed (or perhaps the names of the fields should be changed?). e. At the end of the day you are arguing about whether there is a difference between: - "I would like a shoal of fish, with just one fish in the shoal." and - "I would like just one fish" Do you really have time for this debate? f. Changing an RFC does not just happen through email exchanges. Someone has to do the work. If no-one does the work, it is clear to the chairs how much people care about the issue. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Sep 06 02:32:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECX0I-0005F8-Qn for ccamp-archive@megatron.ietf.org; Tue, 06 Sep 2005 02:32:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08408 for ; Tue, 6 Sep 2005 02:32:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECX3C-0002cQ-Rx for ccamp-archive@ietf.org; Tue, 06 Sep 2005 02:35:24 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECWri-000BdT-FK for ccamp-data@psg.com; Tue, 06 Sep 2005 06:23:30 +0000 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1ECWrf-000Bd4-IQ for ccamp@ops.ietf.org; Tue, 06 Sep 2005 06:23:27 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Tue, 6 Sep 2005 15:24:34 +0900 X-ReadCheckName: ccamp%40ops.ietf.org Thread-Topic: Comments on draft-kim-ccamp-cc-protection-04 X-ReadCheckMessageID: thread-index: AcWyq6X97fVOSbkaTom2uoJpK4LyFg== Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: "Diego Caviglia" , Subject: RE: Comments on draft-kim-ccamp-cc-protection-04 Date: Tue, 6 Sep 2005 15:24:34 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_62BF_01C5B2F7.15E73F70" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 06 Sep 2005 06:24:34.0626 (UTC) FILETIME=[A6210220:01C5B2AB] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_IMAGE_ONLY_04,HTML_MESSAGE,MPART_ALT_DIFF autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 This is a multi-part message in MIME format. ------=_NextPart_000_62BF_01C5B2F7.15E73F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Diego Thanks for your comments. And, sorry for late resposnse. I feel the contents of "Necessities for Resilience of Control Channels" should be rewritten. I think contents of other sections could be updated as well. I'm on rewriting the requirements for the area of control palne robustness or resilience. Please, look at in-line comments about more detailed things. Regards Young ----- Original Message ----- From: "Diego Caviglia" From Date: 2005-09-01 ?? 7:13:44 To: "ccamp@ops.ietf.org" , "yhwkim@etri.re.kr" Cc: Subject: Comments on draft-kim-ccamp-cc-protection-04 > >Hi all, > I'd like to make some comments on the ID in the subjec. > > >Section 7 > > In general, there may be several advantages of out-of-fiber over in- > fiber such as the followings: >[dc] I don't agree with this sentence. I don't think that there are >advantes in the usage of out-of-fiber. > > - When using the overhead bytes of SONET/SDH as a control channel, > in-fiber may require more resources such as HDLC controllers whereas > out-of-fiber could reduce the number of these resources; >[dc] This is a strange sentece. SONET/SDH DCC have not been developed for >GMPLS, are there since several years >and seems very strange to me to think about a SONET/SDH box that do not >support DCC processing. > As you guess, to use DCC overhead bytes, HDLC controllers should be considered. However, in case of out-of-fiber, there is no need to consider resources such as HDLC controllers. > - In case of only in-fiber, it looks that there is no room or no need > for protecting control channels. However, out-of-fiber may apply the > various and effective software based protection schemes; >[dc] Why there is no room for protecting control channels? Do you have any >figures about this? The line level DCC is 576 kbps while >the section DCC is 192 kbps. Do you thing the control traffic will be more >than that? > Contro channels are used to carry packets generated from signaling protocols, routing protocols, ,LMP, and so on. I think DCC overhaed bytes could not afford to support the bandwidth of control channels for these control protocols. According to a private document, it is said the bandwidth of IS-IS protocols amount to about 7 or 8 Mbps within a certain AS. I think that DCC overhead bytes will be used for the extremely limited control traffic due to the limitation of bandwidth. DCC overhead bytes could not support routing protocols. > > - In-fiber is difficult to separate control plane from transport > plane, whereas out-of-fiber is easy to separate control plane; >[dc] IMHO this is not true and moreover you need to explain why is more >difficult. Today DCC are widely used to transport management traffic and >there are no difficulties in order to separate management from data >traffic. > I agree DCC could be used for management traffic. Even in this case, but, short management traffic could be supported. It is difficult to support long management traffic such as bulky data. My view is related to whether DCC based in-fiber is not proper in supporting generic control plane requirements, or not. However, I think a possibilty of using DCC overhead bytes as control channels should be considered in control plane. > > - Because in-fiber provides the connection control function only > within a single fiber, in-fiber could not provide the connection > control function beyond a single fiber, whereas out-of-fiber has no > restriction about the number of fibers for the connection control > function. >[dc] Could you explain me a little bit more this? I don't see anything >that prevent me to set-up more that one CC on a fiber. > Here, I assumed the in-fiber control channel is used for the only own fiber. If you think an in-fiber control channel could be used for controlling other fibers, I or you share thought. Nevertheless, I think there may be a subtle gap bewteen you and me. Even though in-fiber control channels could be used in controlling physically other fibers, from the view-point of the physically other fibers, I think the control channels are not in-fiber but out-of-fiber. > >[quote] When the out-of-fiber configuration is used, control channels may be shared >to handle several fibers >[/quote] >[dc] IMHO the cc are associated to the TE and not to the fibre, so a single >CC can serve several TE link and thus several fibre; this is not related on >how it is implemented. I think it's okey if we agree that control channels are used to control data channels between adjacent nodes. > >[quote] >Consequently, to provide the resilience capability of control channels, it >is reasonable to use out-of-fiber rather than in-fiber for GMPLS. >[quote/] >[dc] I don't see how the previous sentences can lead to this statement. >What is reasonable is that the control channels must be resilient but this >don't implies the fact they should be out-of-fiber. > I agree to your point. I think that it is not good to argue the resilience capability of control channels with in-fiber and out-of-fiber. I will modify these parts in a further document. >Regards > >Diego ------=_NextPart_000_62BF_01C5B2F7.15E73F70 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_62BF_01C5B2F7.15E73F70-- From owner-ccamp@ops.ietf.org Tue Sep 06 02:49:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECXHK-0007JQ-Qg for ccamp-archive@megatron.ietf.org; Tue, 06 Sep 2005 02:49:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09135 for ; Tue, 6 Sep 2005 02:49:57 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECXKD-00032z-Jd for ccamp-archive@ietf.org; Tue, 06 Sep 2005 02:53:00 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECXBV-000F4l-Ta for ccamp-data@psg.com; Tue, 06 Sep 2005 06:43:57 +0000 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1ECXBU-000F4U-6Q for ccamp@ops.ietf.org; Tue, 06 Sep 2005 06:43:56 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Tue, 6 Sep 2005 15:45:02 +0900 X-ReadCheckName: ccamp%40ops.ietf.org Thread-Topic: Comments on draft-kim-ccamp-cc-protection-04 X-ReadCheckMessageID: <9fa98004-536e-4e58-8c27-a7b9bdaa53bc@etri.re.kr> thread-index: AcWyroGu/xD6EEqdQE+gpYcSD/Z8Sw== Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: , Subject: Re: Comments on draft-kim-ccamp-cc-protection-04 Date: Tue, 6 Sep 2005 15:45:02 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_6677_01C5B2F9.F198A200" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 06 Sep 2005 06:45:02.0219 (UTC) FILETIME=[81D4D5B0:01C5B2AE] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_IMAGE_ONLY_04,HTML_MESSAGE,MPART_ALT_DIFF autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f This is a multi-part message in MIME format. ------=_NextPart_000_6677_01C5B2F9.F198A200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Maybe, it looks like that there is a problem on sending this email. I will try it one more. Hi, Diego Thanks for your comments. And, sorry for late resposnse. I feel the contents of "Necessities for Resilience of Control Channels" should be rewritten. I think contents of other sections could be updated as well. I'm on rewriting the requirements for the area of control palne robustness or resilience. Please, look at in-line comments about more detailed things. Regards Young ----- Original Message ----- From: "Diego Caviglia" From Date: 2005-09-01 ?? 7:13:44 To: "ccamp@ops.ietf.org" , "yhwkim@etri.re.kr" Cc: Subject: Comments on draft-kim-ccamp-cc-protection-04 > >Hi all, > I'd like to make some comments on the ID in the subjec. > > >Section 7 > > In general, there may be several advantages of out-of-fiber over in- > fiber such as the followings: >[dc] I don't agree with this sentence. I don't think that there are >advantes in the usage of out-of-fiber. > > - When using the overhead bytes of SONET/SDH as a control channel, > in-fiber may require more resources such as HDLC controllers whereas > out-of-fiber could reduce the number of these resources; >[dc] This is a strange sentece. SONET/SDH DCC have not been developed for >GMPLS, are there since several years >and seems very strange to me to think about a SONET/SDH box that do not >support DCC processing. > As you guess, to use DCC overhead bytes, HDLC controllers should be considered. However, in case of out-of-fiber, there is no need to consider resources such as HDLC controllers. > - In case of only in-fiber, it looks that there is no room or no need > for protecting control channels. However, out-of-fiber may apply the > various and effective software based protection schemes; >[dc] Why there is no room for protecting control channels? Do you have any >figures about this? The line level DCC is 576 kbps while >the section DCC is 192 kbps. Do you thing the control traffic will be more >than that? > Contro channels are used to carry packets generated from signaling protocols, routing protocols, ,LMP, and so on. I think DCC overhaed bytes could not afford to support the bandwidth of control channels for these control protocols. According to a private document, it is said the bandwidth of IS-IS protocols amount to about 7 or 8 Mbps within a certain AS. I think that DCC overhead bytes will be used for the extremely limited control traffic due to the limitation of bandwidth. DCC overhead bytes could not support routing protocols. > > - In-fiber is difficult to separate control plane from transport > plane, whereas out-of-fiber is easy to separate control plane; >[dc] IMHO this is not true and moreover you need to explain why is more >difficult. Today DCC are widely used to transport management traffic and >there are no difficulties in order to separate management from data >traffic. > I agree DCC could be used for management traffic. Even in this case, but, short management traffic could be supported. It is difficult to support long management traffic such as bulky data. My view is related to whether DCC based in-fiber is not proper in supporting generic control plane requirements, or not. However, I think a possibilty of using DCC overhead bytes as control channels should be considered in control plane. > > - Because in-fiber provides the connection control function only > within a single fiber, in-fiber could not provide the connection > control function beyond a single fiber, whereas out-of-fiber has no > restriction about the number of fibers for the connection control > function. >[dc] Could you explain me a little bit more this? I don't see anything >that prevent me to set-up more that one CC on a fiber. > Here, I assumed the in-fiber control channel is used for the only own fiber. If you think an in-fiber control channel could be used for controlling other fibers, I or you share thought. Nevertheless, I think there may be a subtle gap bewteen you and me. Even though in-fiber control channels could be used in controlling physically other fibers, from the view-point of the physically other fibers, I think the control channels are not in-fiber but out-of-fiber. > >[quote] When the out-of-fiber configuration is used, control channels may be shared >to handle several fibers >[/quote] >[dc] IMHO the cc are associated to the TE and not to the fibre, so a single >CC can serve several TE link and thus several fibre; this is not related on >how it is implemented. I think it's okey if we agree that control channels are used to control data channels between adjacent nodes. > >[quote] >Consequently, to provide the resilience capability of control channels, it >is reasonable to use out-of-fiber rather than in-fiber for GMPLS. >[quote/] >[dc] I don't see how the previous sentences can lead to this statement. >What is reasonable is that the control channels must be resilient but this >don't implies the fact they should be out-of-fiber. > I agree to your point. I think that it is not good to argue the resilience capability of control channels with in-fiber and out-of-fiber. I will modify these parts in a further document. >Regards > >Diego ------=_NextPart_000_6677_01C5B2F9.F198A200 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_6677_01C5B2F9.F198A200-- From owner-ccamp@ops.ietf.org Tue Sep 06 03:32:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECXwZ-0004fD-7Z for ccamp-archive@megatron.ietf.org; Tue, 06 Sep 2005 03:32:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10692 for ; Tue, 6 Sep 2005 03:32:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECXzU-00048K-Ki for ccamp-archive@ietf.org; Tue, 06 Sep 2005 03:35:37 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECXr8-000Ng3-3v for ccamp-data@psg.com; Tue, 06 Sep 2005 07:26:58 +0000 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1ECXr6-000Nfn-8U for ccamp@ops.ietf.org; Tue, 06 Sep 2005 07:26:56 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Tue, 6 Sep 2005 16:28:03 +0900 X-ReadCheckName: ccamp%40ops.ietf.org Thread-Topic: Comments on draft-kim-ccamp-cc-protection-04 X-ReadCheckMessageID: <1f7a3ce6-8f8f-48b8-be58-99d4ff19d6f5@etri.re.kr> thread-index: AcWytIQtjuzcI9HjSR+FYGVxebgSVA== Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: , Subject: RE: Comments on draft-kim-ccamp-cc-protection-04 Date: Tue, 6 Sep 2005 16:28:03 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_7359_01C5B2FF.F417EB20" X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-OriginalArrivalTime: 06 Sep 2005 07:28:03.0357 (UTC) FILETIME=[844F3CD0:01C5B2B4] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE,MIME_BASE64_TEXT,MIME_HTML_MOSTLY,MPART_ALT_DIFF autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 3.5 (+++) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 This is a multi-part message in MIME format. ------=_NextPart_000_7359_01C5B2FF.F417EB20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 ------=_NextPart_000_7359_01C5B2FF.F417EB20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj5IaSwgRGllZ288QlI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBBbmQsIHNv cnJ5IGZvciBsYXRlIHJlc3Bvc25zZS48QlI+SSBmZWVsIHRoZSBjb250ZW50cyBvZiAiTmVjZXNz aXRpZXMgZm9yIFJlc2lsaWVuY2Ugb2YgQ29udHJvbCBDaGFubmVscyIgc2hvdWxkIGJlIHJld3Jp dHRlbi48QlI+SSB0aGluayBjb250ZW50cyBvZiBvdGhlciBzZWN0aW9ucyBjb3VsZCBiZSB1cGRh dGVkIGFzIHdlbGwuPEJSPkknbSBvbiByZXdyaXRpbmcgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhl IGFyZWEgb2YgY29udHJvbCBwYWxuZSByb2J1c3RuZXNzIG9yIHJlc2lsaWVuY2UuPEJSPlBsZWFz ZSwgbG9vayBhdCBpbi1saW5lIGNvbW1lbnRzIGFib3V0IG1vcmUgZGV0YWlsZWQgdGhpbmdzLjxC Uj48QlI+UmVnYXJkczxCUj48QlI+WW91bmc8QlI+PEJSPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gPEJSPkZyb206ICJEaWVnbyBDYXZpZ2xpYSIgJmx0O0RpZWdvLkNhdmlnbGlhQG1hcmNv bmkuY29tJmd0OyA8QlI+RnJvbSBEYXRlOiAyMDA1LTA5LTAxID8/IDc6MTM6NDQgPEJSPlRvOiAi Y2NhbXBAb3BzLmlldGYub3JnIiAmbHQ7Y2NhbXBAb3BzLmlldGYub3JnJmd0OywgInlod2tpbUBl dHJpLnJlLmtyIiAmbHQ7eWh3a2ltQGV0cmkucmUua3ImZ3Q7IDxCUj5DYzogPEJSPlN1YmplY3Q6 IENvbW1lbnRzIG9uIGRyYWZ0LWtpbS1jY2FtcC1jYy1wcm90ZWN0aW9uLTA0IDxCUj48QlI+Jmd0 OyA8QlI+PEJSPiZndDtIaSBhbGwsIDxCUj4mZ3Q7IEknZCBsaWtlIHRvIG1ha2Ugc29tZSBjb21t ZW50cyBvbiB0aGUgSUQgaW4gdGhlIHN1YmplYy4gPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDtT ZWN0aW9uIDcgPEJSPiZndDsgPEJSPiZndDsgSW4gZ2VuZXJhbCwgdGhlcmUgbWF5IGJlIHNldmVy YWwgYWR2YW50YWdlcyBvZiBvdXQtb2YtZmliZXIgb3ZlciBpbi0gPEJSPiZndDsgZmliZXIgc3Vj aCBhcyB0aGUgZm9sbG93aW5nczogPEJSPiZndDtbZGNdIEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGlz IHNlbnRlbmNlLiBJIGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgYXJlIDxCUj4mZ3Q7YWR2YW50ZXMg aW4gdGhlIHVzYWdlIG9mIG91dC1vZi1maWJlci4gPEJSPiZndDsgPEJSPiZndDsgLSBXaGVuIHVz aW5nIHRoZSBvdmVyaGVhZCBieXRlcyBvZiBTT05FVC9TREggYXMgYSBjb250cm9sIGNoYW5uZWws IDxCUj4mZ3Q7IGluLWZpYmVyIG1heSByZXF1aXJlIG1vcmUgcmVzb3VyY2VzIHN1Y2ggYXMgSERM QyBjb250cm9sbGVycyB3aGVyZWFzIDxCUj4mZ3Q7IG91dC1vZi1maWJlciBjb3VsZCByZWR1Y2Ug dGhlIG51bWJlciBvZiB0aGVzZSByZXNvdXJjZXM7IDxCUj4mZ3Q7W2RjXSBUaGlzIGlzIGEgc3Ry YW5nZSBzZW50ZWNlLiBTT05FVC9TREggRENDIGhhdmUgbm90IGJlZW4gZGV2ZWxvcGVkIGZvciA8 QlI+Jmd0O0dNUExTLCBhcmUgdGhlcmUgc2luY2Ugc2V2ZXJhbCB5ZWFycyA8QlI+Jmd0O2FuZCBz ZWVtcyB2ZXJ5IHN0cmFuZ2UgdG8gbWUgdG8gdGhpbmsgYWJvdXQgYSBTT05FVC9TREggYm94IHRo YXQgZG8gbm90IDxCUj4mZ3Q7c3VwcG9ydCBEQ0MgcHJvY2Vzc2luZy4gPEJSPiZndDs8QlI+PEJS PjxCUj48QlI+QXMgeW91IGd1ZXNzLCB0byB1c2UgRENDIG92ZXJoZWFkIGJ5dGVzLCBIRExDIGNv bnRyb2xsZXJzIHNob3VsZCBiZSBjb25zaWRlcmVkLiBIb3dldmVyLDxCUj5pbiBjYXNlIG9mIG91 dC1vZi1maWJlciwgdGhlcmUgaXMgbm8gbmVlZCB0byBjb25zaWRlciByZXNvdXJjZXMgc3VjaCBh cyBIRExDIGNvbnRyb2xsZXJzLjxCUj48QlI+Jmd0OyAtIEluIGNhc2Ugb2Ygb25seSBpbi1maWJl ciwgaXQgbG9va3MgdGhhdCB0aGVyZSBpcyBubyByb29tIG9yIG5vIG5lZWQgPEJSPiZndDsgZm9y IHByb3RlY3RpbmcgY29udHJvbCBjaGFubmVscy4gSG93ZXZlciwgb3V0LW9mLWZpYmVyIG1heSBh cHBseSB0aGUgPEJSPiZndDsgdmFyaW91cyBhbmQgZWZmZWN0aXZlIHNvZnR3YXJlIGJhc2VkIHBy b3RlY3Rpb24gc2NoZW1lczsgPEJSPiZndDtbZGNdIFdoeSB0aGVyZSBpcyBubyByb29tIGZvciBw cm90ZWN0aW5nIGNvbnRyb2wgY2hhbm5lbHM/IERvIHlvdSBoYXZlIGFueSA8QlI+Jmd0O2ZpZ3Vy ZXMgYWJvdXQgdGhpcz8gVGhlIGxpbmUgbGV2ZWwgRENDIGlzIDU3NiBrYnBzIHdoaWxlIDxCUj4m Z3Q7dGhlIHNlY3Rpb24gRENDIGlzIDE5MiBrYnBzLiBEbyB5b3UgdGhpbmcgdGhlIGNvbnRyb2wg dHJhZmZpYyB3aWxsIGJlIG1vcmUgPEJSPiZndDt0aGFuIHRoYXQ/IDxCUj4mZ3Q7PEJSPjxCUj5D b250cm8gY2hhbm5lbHMgYXJlIHVzZWQgdG8gY2FycnkgcGFja2V0cyBnZW5lcmF0ZWQgZnJvbSBz aWduYWxpbmcgcHJvdG9jb2xzLCByb3V0aW5nIHByb3RvY29scywgLExNUCwgYW5kIHNvIG9uLiBJ IHRoaW5rIERDQyBvdmVyaGFlZCBieXRlcyBjb3VsZCBub3QgYWZmb3JkIHRvIHN1cHBvcnQgdGhl IGJhbmR3aWR0aCBvZiBjb250cm9sIGNoYW5uZWxzIGZvciB0aGVzZSBjb250cm9sIHByb3RvY29s cy4gQWNjb3JkaW5nIHRvIGEgcHJpdmF0ZSBkb2N1bWVudCwgaXQgaXMgc2FpZCB0aGUgYmFuZHdp ZHRoIG9mIElTLUlTIHByb3RvY29scyBhbW91bnQgdG8gYWJvdXQgNyBvciA4IE1icHMgd2l0aGlu IGEgY2VydGFpbiBBUy4gSSB0aGluayB0aGF0IERDQyBvdmVyaGVhZCBieXRlcyB3aWxsIGJlIHVz ZWQgZm9yIHRoZSBleHRyZW1lbHkgbGltaXRlZCBjb250cm9sIHRyYWZmaWMgZHVlIHRvIHRoZSBs aW1pdGF0aW9uIG9mIGJhbmR3aWR0aC4gRENDIG92ZXJoZWFkIGJ5dGVzIGNvdWxkIG5vdCBzdXBw b3J0IHJvdXRpbmcgcHJvdG9jb2xzLjxCUj48QlI+Jmd0OyA8QlI+Jmd0OyAtIEluLWZpYmVyIGlz IGRpZmZpY3VsdCB0byBzZXBhcmF0ZSBjb250cm9sIHBsYW5lIGZyb20gdHJhbnNwb3J0IDxCUj4m Z3Q7IHBsYW5lLCB3aGVyZWFzIG91dC1vZi1maWJlciBpcyBlYXN5IHRvIHNlcGFyYXRlIGNvbnRy b2wgcGxhbmU7IDxCUj4mZ3Q7W2RjXSBJTUhPIHRoaXMgaXMgbm90IHRydWUgYW5kIG1vcmVvdmVy IHlvdSBuZWVkIHRvIGV4cGxhaW4gd2h5IGlzIG1vcmUgPEJSPiZndDtkaWZmaWN1bHQuIFRvZGF5 IERDQyBhcmUgd2lkZWx5IHVzZWQgdG8gdHJhbnNwb3J0IG1hbmFnZW1lbnQgdHJhZmZpYyBhbmQg PEJSPiZndDt0aGVyZSBhcmUgbm8gZGlmZmljdWx0aWVzIGluIG9yZGVyIHRvIHNlcGFyYXRlIG1h bmFnZW1lbnQgZnJvbSBkYXRhIDxCUj4mZ3Q7dHJhZmZpYy4gPEJSPiZndDs8QlI+PEJSPkkgYWdy ZWUgRENDIGNvdWxkIGJlIHVzZWQgZm9yIG1hbmFnZW1lbnQgdHJhZmZpYy4gRXZlbiBpbiB0aGlz IGNhc2UsIGJ1dCwgc2hvcnQgbWFuYWdlbWVudCB0cmFmZmljIGNvdWxkIGJlIHN1cHBvcnRlZC4g SXQgaXMgZGlmZmljdWx0IHRvIHN1cHBvcnQgbG9uZyBtYW5hZ2VtZW50IHRyYWZmaWMgc3VjaCBh cyBidWxreSBkYXRhLjxCUj5NeSB2aWV3IGlzIHJlbGF0ZWQgdG8gd2hldGhlciBEQ0MgYmFzZWQg aW4tZmliZXIgaXMgbm90IHByb3BlciBpbiBzdXBwb3J0aW5nIGdlbmVyaWMgY29udHJvbCBwbGFu ZSByZXF1aXJlbWVudHMsIG9yIG5vdC4gSG93ZXZlciwgSSB0aGluayBhIHBvc3NpYmlsdHkgb2Yg dXNpbmcgRENDIG92ZXJoZWFkIGJ5dGVzIGFzIGNvbnRyb2wgY2hhbm5lbHMgc2hvdWxkIGJlIGNv bnNpZGVyZWQgaW4gY29udHJvbCBwbGFuZS48QlI+PEJSPiZndDsgPEJSPiZndDsgLSBCZWNhdXNl IGluLWZpYmVyIHByb3ZpZGVzIHRoZSBjb25uZWN0aW9uIGNvbnRyb2wgZnVuY3Rpb24gb25seSA8 QlI+Jmd0OyB3aXRoaW4gYSBzaW5nbGUgZmliZXIsIGluLWZpYmVyIGNvdWxkIG5vdCBwcm92aWRl IHRoZSBjb25uZWN0aW9uIDxCUj4mZ3Q7IGNvbnRyb2wgZnVuY3Rpb24gYmV5b25kIGEgc2luZ2xl IGZpYmVyLCB3aGVyZWFzIG91dC1vZi1maWJlciBoYXMgbm8gPEJSPiZndDsgcmVzdHJpY3Rpb24g YWJvdXQgdGhlIG51bWJlciBvZiBmaWJlcnMgZm9yIHRoZSBjb25uZWN0aW9uIGNvbnRyb2wgPEJS PiZndDsgZnVuY3Rpb24uIDxCUj4mZ3Q7W2RjXSBDb3VsZCB5b3UgZXhwbGFpbiBtZSBhIGxpdHRs ZSBiaXQgbW9yZSB0aGlzPyBJIGRvbid0IHNlZSBhbnl0aGluZyA8QlI+Jmd0O3RoYXQgcHJldmVu dCBtZSB0byBzZXQtdXAgbW9yZSB0aGF0IG9uZSBDQyBvbiBhIGZpYmVyLiA8QlI+Jmd0OzxCUj48 QlI+SGVyZSwgSSBhc3N1bWVkIHRoZSBpbi1maWJlciBjb250cm9sIGNoYW5uZWwgaXMgdXNlZCBm b3IgdGhlIG9ubHkgb3duIGZpYmVyLiA8QlI+SWYgeW91IHRoaW5rIGFuIGluLWZpYmVyIGNvbnRy b2wgY2hhbm5lbCBjb3VsZCBiZSB1c2VkIGZvciBjb250cm9sbGluZyBvdGhlciBmaWJlcnMsIEkg b3IgeW91IHNoYXJlIHRob3VnaHQuPEJSPk5ldmVydGhlbGVzcywgSSB0aGluayB0aGVyZSBtYXkg YmUgYSBzdWJ0bGUgZ2FwIGJld3RlZW4geW91IGFuZCBtZS48QlI+RXZlbiB0aG91Z2ggaW4tZmli ZXIgY29udHJvbCBjaGFubmVscyBjb3VsZCBiZSB1c2VkIGluIGNvbnRyb2xsaW5nIHBoeXNpY2Fs bHkgb3RoZXIgZmliZXJzLCBmcm9tIHRoZSB2aWV3LXBvaW50IG9mIHRoZSBwaHlzaWNhbGx5IG90 aGVyIGZpYmVycywgSSB0aGluayB0aGUgY29udHJvbCBjaGFubmVscyBhcmUgbm90IGluLWZpYmVy IGJ1dCBvdXQtb2YtZmliZXIuPEJSPjxCUj4mZ3Q7IDxCUj4mZ3Q7W3F1b3RlXSA8QlI+V2hlbiB0 aGUgb3V0LW9mLWZpYmVyIGNvbmZpZ3VyYXRpb24gaXMgdXNlZCwgY29udHJvbCBjaGFubmVscyBt YXkgYmUgc2hhcmVkIDxCUj4mZ3Q7dG8gaGFuZGxlIHNldmVyYWwgZmliZXJzIDxCUj4mZ3Q7Wy9x dW90ZV0gPEJSPiZndDtbZGNdIElNSE8gdGhlIGNjIGFyZSBhc3NvY2lhdGVkIHRvIHRoZSBURSBh bmQgbm90IHRvIHRoZSBmaWJyZSwgc28gYSBzaW5nbGUgPEJSPiZndDtDQyBjYW4gc2VydmUgc2V2 ZXJhbCBURSBsaW5rIGFuZCB0aHVzIHNldmVyYWwgZmlicmU7IHRoaXMgaXMgbm90IHJlbGF0ZWQg b24gPEJSPiZndDtob3cgaXQgaXMgaW1wbGVtZW50ZWQuPEJSPjxCUj5JIHRoaW5rIGl0J3Mgb2tl eSBpZiB3ZSBhZ3JlZSB0aGF0IGNvbnRyb2wgY2hhbm5lbHMgYXJlIHVzZWQgdG8gY29udHJvbCBk YXRhIGNoYW5uZWxzIGJldHdlZW4gYWRqYWNlbnQgbm9kZXMuPEJSPjxCUj4mZ3Q7IDxCUj4mZ3Q7 W3F1b3RlXSA8QlI+Jmd0O0NvbnNlcXVlbnRseSwgdG8gcHJvdmlkZSB0aGUgcmVzaWxpZW5jZSBj YXBhYmlsaXR5IG9mIGNvbnRyb2wgY2hhbm5lbHMsIGl0IDxCUj4mZ3Q7aXMgcmVhc29uYWJsZSB0 byB1c2Ugb3V0LW9mLWZpYmVyIHJhdGhlciB0aGFuIGluLWZpYmVyIGZvciBHTVBMUy4gPEJSPiZn dDtbcXVvdGUvXSA8QlI+Jmd0O1tkY10gSSBkb24ndCBzZWUgaG93IHRoZSBwcmV2aW91cyBzZW50 ZW5jZXMgY2FuIGxlYWQgdG8gdGhpcyBzdGF0ZW1lbnQuIDxCUj4mZ3Q7V2hhdCBpcyByZWFzb25h YmxlIGlzIHRoYXQgdGhlIGNvbnRyb2wgY2hhbm5lbHMgbXVzdCBiZSByZXNpbGllbnQgYnV0IHRo aXMgPEJSPiZndDtkb24ndCBpbXBsaWVzIHRoZSBmYWN0IHRoZXkgc2hvdWxkIGJlIG91dC1vZi1m aWJlci4gPEJSPiZndDs8QlI+PEJSPkkgYWdyZWUgdG8geW91ciBwb2ludC4gSSB0aGluayB0aGF0 IGl0IGlzIG5vdCBnb29kIHRvIGFyZ3VlIHRoZSByZXNpbGllbmNlIGNhcGFiaWxpdHkgb2YgY29u dHJvbCBjaGFubmVscyB3aXRoIGluLWZpYmVyIGFuZCBvdXQtb2YtZmliZXIuIEkgd2lsbCBtb2Rp ZnkgdGhlc2UgcGFydHMgaW4gYSBmdXJ0aGVyIGRvY3VtZW50LjxCUj48QlI+Jmd0O1JlZ2FyZHMg PEJSPiZndDsgPEJSPiZndDtEaWVnbyA8QlI+PC9ESVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxh eTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0iaHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0 ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9Y2NhbXBAb3BzLmlldGYub3JnJm5hbWU9Y2NhbXAl NDBvcHMuaWV0Zi5vcmcmZnJvbWVtYWlsPXlod2tpbUBldHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0Mx ZjdhM2NlNi04ZjhmLTQ4YjgtYmU1OC05OWQ0ZmYxOWQ2ZjVAZXRyaS5yZS5rciUzRSI+ ------=_NextPart_000_7359_01C5B2FF.F417EB20-- From owner-ccamp@ops.ietf.org Tue Sep 06 17:32:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECl2y-0002ck-7k for ccamp-archive@megatron.ietf.org; Tue, 06 Sep 2005 17:32:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01658 for ; Tue, 6 Sep 2005 17:32:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECl5y-00046Q-Lf for ccamp-archive@ietf.org; Tue, 06 Sep 2005 17:35:13 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ECkrz-0007aV-EU for ccamp-data@psg.com; Tue, 06 Sep 2005 21:20:43 +0000 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1ECkrv-0007a8-At for ccamp@ops.ietf.org; Tue, 06 Sep 2005 21:20:39 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 06 Sep 2005 21:35:02 +0000 X-SBRS: None X-IronPort-AV: i="3.96,172,1122854400"; d="scan'208"; a="27832319:sNHT22469028" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Sep 2005 16:20:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Final draft of response to the OIF Date: Tue, 6 Sep 2005 16:20:10 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWxapMIbhDotaR3QWui/me39CHNnQBh6N6Q From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" , X-OriginalArrivalTime: 06 Sep 2005 21:20:38.0309 (UTC) FILETIME=[D3C7FD50:01C5B328] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable Hi All, It is interesting to note that the technically correct body text in RFC3946 (which would typically be considered normative) is being considered a 'typo' and subject to editorial change, while an example in an annex is being preserved although it appears to be in error according to the body text. A few more comments in-line below. Regards, Ben =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, September 04, 2005 11:05 AM > To: ccamp@ops.ietf.org > Subject: Re: Final draft of response to the OIF >=20 > OK. >=20 > So I see two questions here. >=20 > 1. What is meant by RFC3946? > 2. Do we want to change what is said by RFC3946? >=20 > Question 1 appears to be the question that was asked by the=20 > OIF. I think > we have a clear answer. I think some people are not happy with this > answer, but that feeds into question 2. My understanding of=20 > the answer to > question 1 is based on the input from the editors of the RFC=20 > and reading > the CCAMP archive. Thus, the response to the question from=20 > the OIF is as > follows: >=20 > This question about RFC 3946 was raised informally on the CCAMP > mailing list at the start of March this year. >=20 > Even when the signal Type value is the same (i.e. value 6) the > NCC, RCC and NVC values depend on the specific signal being > requested. >=20 > From the examples in the annex we have... >=20 > A VC-4 signal is formed by applying the following > settings to a VC-4 Elementary Signal. > RCC =3D 0 > NCC =3D 0 > NVC =3D 0 > MT =3D 1 > T =3D 0 >=20 > An STS-3c SPE signal is formed by applying the > following settings to an STS-3c SPE Elementary > Signal. > RCC =3D 1 (standard contiguous concatenation) > NCC =3D 1 > NVC =3D 0 > MT =3D 1 > T =3D 0 >=20 > Your question probably arises from the two notes and subsequent > paragraph in section 2.1 or RFC 3946. Here it says... >=20 > Note 1: when requesting a SONET STS-Nc SPE with N=3D3*X, the > Elementary Signal to use must always be an STS-3c_SPE signal > type and the value of NCC must always be equal to X. This > allows also facilitating the interworking between SONET and > SDH. In particular, it means that the contiguous > concatenation of three STS-1 SPEs can not be requested because > according to this specification, this type of signal must be > coded using the STS-3c SPE signal type. >=20 > Note 2: when requesting a transparent STS-N/STM-N signal > limited to a single contiguously concatenated STS-Nc_SPE/ > VC-4-Nc, the signal type must be STS-N/STM-N, RCC with flag 1 > and NCC set to 1. >=20 > The NCC value must be consistent with the type of contiguous > concatenation being requested in the RCC field. In particular, > this field is irrelevant if no contiguous concatenation is > requested (RCC =3D 0), in that case it must be set to zero when > sent, and should be ignored when received. A RCC value > different from 0 must imply a number of contiguous components > greater than 1. >=20 > This final sentence should read "greater than or equal to 1," and > was mistyped in the RFC. This change resolves all of your questions > and makes the text consistent with the examples. >=20 > The CCAMP working group is discussing a revision to RFC 3946 to > clarify the situation. >=20 > Question 2 is a different issue. Quite a few people have=20 > stated that they > believe that RFC 3946 with its current interpretation by the editors, > should be changed. At the moment I do not see consensus on=20 > this issue and > frankly I do not see any weighty reason to change although if the > community shows consensus in favor of a change, that would be=20 > fine *if* > someone does the work. >=20 > My observations on this point are as follows. >=20 > a. This is control plane code. It is definitively not > relevant to any interworking in the data plane.=20 Nothing CCAMP does is relevant to interworking in the data plane. However, the control plane should be reflective of the data plane. And the data plane has been made common for SONET/SDH. This is the reason that LSP Encoding Type 6 was depricated (even though at the time there were implementations that used it). We have the opportunity to maintain the same goal of properly reflecting the data plane in the control structure. Remember we're talking about a proposed standard, and taking into account implementation experience. > So > long as it is written down clearly, *any* unambiguous > control plane encoding is adequate. However, not every encoding achieves the goal of unifying SONET and SDH control. Furthermore, what has been proposed doesn't increase interoperability, but rather makes interoperability less likely. >=20 > b. Even if the data plane signal is identical, there may > be value in distinguishing between the SDH and SONET > origins of the signal. Then, as Huub asked, do we also need to distinguish SONET and SDH encodings at other rates as well? This would require a change to the current encodings. >=20 > c. We MUST support existing implementations. That means > that whatever encoding rules we end up with, we MUST > continue to support the receipt of existing encoding. > It seems to me that this dilutes the purpose of any > change. >=20 > d. Regardless of the definition of the signal encodings, > and regardless of whether fields with the same names > are used in the definition of those signals, I find > the textual descriptions of NCC and RCC in RFC 3946 > unambiguous in English. It may be that those > descriptions should be changed (or perhaps the names > of the fields should be changed?). >=20 > e. At the end of the day you are arguing about whether > there is a difference between: > - "I would like a shoal of fish, with just one fish > in the shoal." > and > - "I would like just one fish" > Do you really have time for this debate? >=20 > f. Changing an RFC does not just happen through email > exchanges. Someone has to do the work. If no-one does > the work, it is clear to the chairs how much people > care about the issue. The work is straightforward (change '1' to '0' in two places). I would think the editor(s) could handle this. >=20 > Thanks, > Adrian >=20 >=20 From owner-ccamp@ops.ietf.org Wed Sep 07 11:12:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED1bN-0006Ut-Pk for ccamp-archive@megatron.ietf.org; Wed, 07 Sep 2005 11:12:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25444 for ; Wed, 7 Sep 2005 11:12:39 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED1eX-0008PD-Ju for ccamp-archive@ietf.org; Wed, 07 Sep 2005 11:16:00 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ED1RW-0005yZ-34 for ccamp-data@psg.com; Wed, 07 Sep 2005 15:02:30 +0000 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1ED1RS-0005xu-1V for ccamp@ops.ietf.org; Wed, 07 Sep 2005 15:02:27 +0000 Received: from cvdgwy01.uk.marconicomms.com (cvis26.uk.marconicomms.com [128.87.251.109]) by smtpoutuk01.marconi.com (8.12.11/8.12.11) with ESMTP id j87F2I3q018627 for ; Wed, 7 Sep 2005 16:02:19 +0100 (envelope-from Diego.Caviglia@marconi.com) Subject: RE: Comments on draft-kim-ccamp-cc-protection-04 To: "Kim Young Hwa" Cc: " X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 7 Sep 2005 17:02:26 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 07/09/2005 16:02:17 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Hi Kim, I've some further comments in line. Regards Diego "Kim Young Hwa" on 06/09/2005 09.28.03 Please respond to "Kim Young Hwa" To: , cc: Subject: RE: Comments on draft-kim-ccamp-cc-protection-04 [CUT] > > - When using the overhead bytes of SONET/SDH as a control channel, > in-fiber may require more resources such as HDLC controllers whereas > out-of-fiber could reduce the number of these resources; >[dc] This is a strange sentece. SONET/SDH DCC have not been developed for >GMPLS, are there since several years >and seems very strange to me to think about a SONET/SDH box that do not >support DCC processing. > As you guess, to use DCC overhead bytes, HDLC controllers should be considered. However, in case of out-of-fiber, there is no need to consider resources such as HDLC controllers. [dc] Actually my point was that every box that is compliant with SDH/SONET specs is able to process DCC. So it is not a point to say that "n-fiber may require more resources such as HDLC controllers" because AFAIK every SONET/SDH box in the world have that controllers. > - In case of only in-fiber, it looks that there is no room or no need > for protecting control channels. However, out-of-fiber may apply the > various and effective software based protection schemes; >[dc] Why there is no room for protecting control channels? Do you have any >figures about this? The line level DCC is 576 kbps while >the section DCC is 192 kbps. Do you thing the control traffic will be more >than that? > Contro channels are used to carry packets generated from signaling protocols, routing protocols, ,LMP, and so on. I think DCC overhaed bytes could not afford to support the bandwidth of control channels for these control protocols. [dc] I'm sorry but the sentence "I think DCC overhaed bytes could not afford to support the bandwidth of control channels for these control protocols" is not enough for a technical discussion. According to a private document, it is said the bandwidth of IS-IS protocols amount to about 7 or 8 Mbps within a certain AS. I think that DCC overhead bytes will be used for the extremely limited control traffic due to the limitation of bandwidth. DCC overhead bytes could not support routing protocols. [dc]I'm sorry again but I don't think that a private doc can be used as reference for a ID, otherwise I can state that accordingly to a private doc the bandwidth of IS-IS is less than 1 byte/day. > > - In-fiber is difficult to separate control plane from transport > plane, whereas out-of-fiber is easy to separate control plane; >[dc] IMHO this is not true and moreover you need to explain why is more >difficult. Today DCC are widely used to transport management traffic and >there are no difficulties in order to separate management from data >traffic. > I agree DCC could be used for management traffic. Even in this case, but, short management traffic could be supported. It is difficult to support long management traffic such as bulky data. [dc] Usually SW update is done remotely via DCN and DCN is also made by DCC. IMHO SW update (a.k.a. sw download) is a long management operation. My view is related to whether DCC based in-fiber is not proper in supporting generic control plane requirements, or not. However, I think a possibilty of using DCC overhead bytes as control channels should be considered in control plane. [dc] IMHO if you want to do a requirement docs you don't have to suggest implementation or say the DCC are not good for control plane. Just write down the requirements and leave to the developer the choice. > > - Because in-fiber provides the connection control function only > within a single fiber, in-fiber could not provide the connection > control function beyond a single fiber, whereas out-of-fiber has no > restriction about the number of fibers for the connection control > function. >[dc] Could you explain me a little bit more this? I don't see anything >that prevent me to set-up more that one CC on a fiber. > Here, I assumed the in-fiber control channel is used for the only own fiber. If you think an in-fiber control channel could be used for controlling other fibers, I or you share thought. Nevertheless, I think there may be a subtle gap bewteen you and me. Even though in-fiber control channels could be used in controlling physically other fibers, from the view-point of the physically other fibers, I think the control channels are not in-fiber but out-of-fiber. [dc] So there is a need to make a definition of what in-fiber means. From owner-ccamp@ops.ietf.org Wed Sep 07 15:57:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED63L-00049G-4Q for ccamp-archive@megatron.ietf.org; Wed, 07 Sep 2005 15:57:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13300 for ; Wed, 7 Sep 2005 15:57:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED66Y-0000VF-To for ccamp-archive@ietf.org; Wed, 07 Sep 2005 16:01:12 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ED5vy-0001JS-CV for ccamp-data@psg.com; Wed, 07 Sep 2005 19:50:14 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1ED5vp-0001H3-L7 for ccamp@ops.ietf.org; Wed, 07 Sep 2005 19:50:05 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ED5vl-0005Hb-Nn; Wed, 07 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt Message-Id: Date: Wed, 07 Sep 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 --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 : Node ID based RSVP Hello: A Clarification Statement Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt Pages : 7 Date : 2005-9-7 Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session as a best current practice (BCP) in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rsvp-node-id-based-hello-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-rsvp-node-id-based-hello-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: <2005-9-7111234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-7111234.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Sep 07 16:50:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED6s4-0003Ux-AF for ccamp-archive@megatron.ietf.org; Wed, 07 Sep 2005 16:50:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21529 for ; Wed, 7 Sep 2005 16:50:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED6vD-0003t4-4Q for ccamp-archive@ietf.org; Wed, 07 Sep 2005 16:53:37 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1ED6nk-00069C-2B for ccamp-data@psg.com; Wed, 07 Sep 2005 20:45:48 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1ED6nh-00068w-NT for ccamp@ops.ietf.org; Wed, 07 Sep 2005 20:45:46 +0000 Received: from du-069-0243.access.clara.net ([217.158.132.243] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1ED6ne-000HHr-9d for ccamp@ops.ietf.org; Wed, 07 Sep 2005 21:45:44 +0100 Message-ID: <046701c5b3ed$8271e310$93849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: Subject: Short further last call on draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt Date: Wed, 7 Sep 2005 21:48:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Hi, Alex has reviewed this I-D as AD and says it is fine, but he thinks we should take it down the standards track as Proposed Standard not BCP as it was previously marked. This revision changes: - proposed status - IPR boilerplate - IANA clause to be a little more (about 10 words) detailed Since we have changed the proposed status, we need to check back with you guys. Let's have a two week last call on this change. If you do spot other issues as you go, then I guess we can handle them too. Last call will end 12 noon GMT on Thursday 22nd September. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Wednesday, September 07, 2005 8:50 PM Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > 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 : Node ID based RSVP Hello: A Clarification Statement > Author(s) : Z. Ali, et al. > Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > Pages : 7 > Date : 2005-9-7 > > Use of Node-ID based RSVP Hello messages is implied in a number of > cases, e.g., when data and control plan are separated, when TE links > are unnumbered. Furthermore, when link level failure detection is > performed by some means other than exchanging RSVP Hello messages, > use of Node-ID based Hello session is optimal for detecting signaling > adjacency failure for Resource reSerVation Protocol-Traffic > Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear > and this document formalizes use of Node-ID based RSVP Hello session > as a best current practice (BCP) in some scenarios. The procedure > described in this document applies to both Multi-Protocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-rsvp-node-id-based-hello-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-rsvp-node-id-based-hello-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. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > From owner-ccamp@ops.ietf.org Thu Sep 08 11:55:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOjy-00062B-QS for ccamp-archive@megatron.ietf.org; Thu, 08 Sep 2005 11:55:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28195 for ; Thu, 8 Sep 2005 11:55:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDOnN-000805-6A for ccamp-archive@ietf.org; Thu, 08 Sep 2005 11:58:38 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDOZd-000Bbv-3g for ccamp-data@psg.com; Thu, 08 Sep 2005 15:44:25 +0000 Received: from [207.69.200.28] (helo=pop04.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EDOZb-000Bbf-Ic for ccamp@ops.ietf.org; Thu, 08 Sep 2005 15:44:23 +0000 Received: from h-66-167-248-214.cmbrmaor.dynamic.covad.net ([66.167.248.214] helo=jluciani-laptop) by pop04.mail.atl.earthlink.net with smtp (Exim 3.36 #10) id 1EDOZW-0000NO-00; Thu, 08 Sep 2005 11:44:18 -0400 Message-Id: <3.0.1.32.20050908114852.0147664c@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 08 Sep 2005 11:48:52 -0400 To: tnadeau@cisco.com, adrian@olddog.co.uk, ccamp@ops.ietf.org From: jcucchiara@mindspring.com Subject: review of draft-ietf-ccamp-lsr-mib-08.txt Cc: bwijnen@lucent.com, jcucchiara@mindspring.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1126208932==_" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 662324ecda47446db09bfd0a0092c4ba --=====================_1126208932==_ Content-Type: text/plain; charset="us-ascii" --=====================_1126208932==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="new-review-GMPLS-LSR-STD-MIB.txt" Hello, I would like to thank Bert for his input, especially on the MIB compliances and document reference section. Thank you, -Joan draft-ietf-ccamp-gmpls-lsr-mib-08.txt ======================================= Section 1.1 Migration Strategy -------------------------------- 1) Does the following statement refer to the GMPLS LSR MIB module? "The GMPLS Label MIB module may be referenced using a row pointer from objects within the LSR MIB module." ^^^^ As previously mentioned, using the entire MIB module name would be clearer. Section 4. Outline --------------------- 2) Need to clarify the phrase "this MIB module" because there are 2 MIB modules in this document. "- Enabling GMPLS on GMPLS capable interfaces using this MIB module." (which is referring to the GMPLS-LSR-STD-MIB module??) ... "- Optionally setting up labels in the label table in this MIB module if the textual convention MplsLabel is not capable of holding the required label (for example, if the label requires more than 32 bits to encode it), or if the operator wishes to disambiguate GMPLS label types." The phrase, "in this MIB module", needs to be clarified since there are 2 mib modules in this document. Here, I think you are referring to the GMPLS-LABEL-STD-MIB, but prior to this you use a similar phrase and are referring the the GMPLS-LSR-STD-MIB. Please consistently specify the MIB modules by using their names. 3) Please move section, 4.1 MIB Modules to section 1.1, Migration Strategy. There is much overlap in these 2 sections so please combine them. Section 4.1.2 Summary of GMPLS Label MIB Module ------------------------------------------------- 4) "Generalized Labels can be of variable length and have distinct bit-by-bit interpretations according to the use that is made of them." Please change the above to: "Generalized Labels can be of variable length and have distinct bit-by-bit interpretations depending upon how they are defined by the specific service provider." 5) Same section, 4.1.2 Summary of GMPLS Label MIB Module Please remove this last sentence: These tables are described in the subsequent sections. Section 5. Bidirectional LSPs ------------------------------- 6) "This MIB module..." Please clarify which MIB module, i.e. The GMPLS-LSR-STD-MIB module 7) Please specifically call out which term you will be using in this document. Beginning with the 3rd paragraph, there is much terminology, so please add some statement such as: "In this document, the terms 'forward' and 'reverse' will be used. Section 6. Example of LSP Setup ------------------------------- 8) First and second sentences: "In this section we provide a brief example of using the MIB objects described in sections 7 and 8 to set up an LSP. While this example is not meant to illustrate every nuance of the MIB, it is intended as an aid to understanding some of the key concepts..." The phrase, "every nuance of the MIB" should probably be "every nuance of the MIB modules" since you are referring to both of the MIB modules (sections 7 and 8). 9) Typo: gmplsLableTable 10) Typo: accesible (in several places) Section 7. GMPLS-LSR-STD-MIB ====================== 11) smicngpro gives the following: E: f(GMPLS-LSR-STD-MIB), (315,8) Item "ifGeneralInformationGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (316,8) Item "ifCounterDiscontinuityGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (322,8) Item "mplsInterfaceGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (323,8) Item "mplsInSegmentGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (324,8) Item "mplsOutSegmentGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (325,8) Item "mplsXCGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (326,8) Item "mplsPerfGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (327,8) Item "mplsLsrNotificationGroup" should be IMPORTed W: f(GMPLS-LSR-STD-MIB), (358,18) For "gmplsOutSegmentTTLDecrement", syntax is identical E: f(GMPLS-LSR-STD-MIB), (378,8) Item "ifGeneralInformationGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (379,8) Item "ifCounterDiscontinuityGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (385,8) Item "mplsInterfaceGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (386,8) Item "mplsInSegmentGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (387,8) Item "mplsOutSegmentGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (388,8) Item "mplsXCGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (389,8) Item "mplsPerfGroup" should be IMPORTed W: f(GMPLS-LSR-STD-MIB), (404,14) For "gmplsInterfaceSignalingCaps", syntax is identical W: f(GMPLS-LSR-STD-MIB), (415,18) For "gmplsInterfaceRsvpHelloPeriod", syntax is identical W: f(GMPLS-LSR-STD-MIB), (431,18) For "gmplsInSegmentExtraParamsPtr", syntax is identical W: f(GMPLS-LSR-STD-MIB), (447,18) For "gmplsOutSegmentTTLDecrement", syntax is identical W: f(GMPLS-LSR-STD-MIB), (454,18) For "gmplsOutSegmentExtraParamsPtr", syntax is identical Please correct the above. Also, please change the following 2 statements (which appear twice) to remove the SYNTAX, since this is redundant, unless there is a reason why you prefer to leave it. OBJECT gmplsInSegmentDirection SYNTAX GmplsSegmentDirection MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." OBJECT gmplsOutSegmentDirection SYNTAX GmplsSegmentDirection MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." Compiles cleanly with smilint. 12) DESCRIPTION Please change the first paragraph to (this comment applies to the other MIB modules also.) Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXX; see the RFC itself for full legal notices. 13) Change the following: GmplsSegmentDirection FROM GMPLS-TC-STD-MIB -- GMPLSTCMIB -- RFC-Editor please resolve the reference above TO: GmplsSegmentDirection FROM GMPLS-TC-STD-MIB -- RFCXXXX -- RFC-Editor please resolve the reference above -- and remove this note. 14) Please remove: -- Notifications -- no notifications are currently defined. gmplsLsrNotifications OBJECT IDENTIFIER ::= { gmplsLsrStdMIB 0 } (You don't need to change any numbering, but no sense defining a number you don't need). 15) Please remove comments such as (this request is made for all MIB modules in all 3 documents): -- Top level components of this MIB module. -- Tables, Scalars -- Conformance -- GMPLS Interface Table. -- End of gmplsInterfaceTable -- In-segment table. etc. 16) gmplsInterfaceEntry OBJECT-TYPE "A conceptual row in this table is created automatically by an LSR for every interface capable of supporting GMPLS and which is configured to do so." Please change first sentence: "A conceptual row in this table is created automatically by an LSR when the interface is capable of supporting GMPLS and is correctly configured to do so." .... Please change the first sentence of the last paragraph: "The indexing is the same as that for mplsInterfaceTable." to: "The indexing is the same as the mplsInterfaceTable." 17) object: gmplsInterfaceSignalingCaps OBJECT-TYPE SYNTAX BITS { unknown (0), rsvpGmpls (1), crldpGmpls (2), -- note the use of CR-LDP is deprecated otherGmpls (3) } What is otherGmpls(3)?? Also, this description is confusing. How can unknown(0) and rsvpGmpls(1) be set simultaneously? Additionally, how can no bits be set? If this is a GMPLS interface, then doesn't one of these bits HAVE to be set? 18) gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE "Period, in milliseconds, between sending RSVP Hello messages on this interface. A value of 0 indicates that no Hello messages should be sent on this interface." This object is only valid if the gmplsInterfaceSignalingCaps object is set ot rsvpGmpls. Please update the description to reflect that. 19) gmplsInSegmentEntry OBJECT-TYPE "An entry in this table extends the representation of an incoming segment represented by an entry in mplsInSegmentTable. An entry can be created by a network administrator or an SNMP agent, or a GMPLS signaling protocol. Please use the phrase: "via SNMP SET commands to create an entry" in place of "SNMP agent". 20) same entry, gmplsInSegmentEntry Note that the storage type for this entry SHOULD be inherited from the corresponding entry in the mplsInSegmentTable given by the value of the mplsInSegmentStorageType object." Please change to: Note that the storage type for this entry is given by the value of mplsInSegmentStorageType in the corresponding entry of the mplsInSegmentTable. 21) gmplsInSegmentDirection OBJECT-TYPE Please use "corresponding" instead of "associated" 22) gmplsInSegmentExtraParamsPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "Some Tunnels will run over transports that can usefully support technology-specific additional parameters (for example, SONET resource usage). Such can be supplied from an external table and referenced from here. A value of zeroDotzero in this attribute indicates that there is no such additional information." DEFVAL { zeroDotZero } ::= { gmplsInSegmentEntry 2 } What is meant by "external table"? If this is an enterprise-specific table, then is it necessary to have this object in the MIB. In other words, why is this MIB dictating that a row-pointer be used when an enterprise-specific MIB may which to simply use indices. I think this object is unnecessary, but maybe I don't understand something. 23) gmplsOutSegmentEntry OBJECT-TYPE Same comments as with gmplsInSegmentEntry 24) gmplsOutSegmentDirection OBJECT-TYPE Same comment as with gmplsInSegmentDirection 25) gmplsOutSegmentTTLDecrement OBJECT-TYPE "This object indicates the amount by which to decrement the TTL of any payload packets forwarded on this segment if per-hop decrementing is being done. Please change above to: This object indicates the amount to decrement the TTL... 26) same object's gmplsOutSegmentTTLDecrement OBJECT-TYPE A value of zero indicates that no decrement should be made or that per-hop decrementing is not in force. Please change: in force to enforced. 27) gmplsOutSegmentExtraParamsPtr OBJECT-TYPE Same comment as with gmplsInSegmentExtraParamsPtr 28) Compliance Statements I believe that gmplsInSegmentExtraParamsPtr and gmplsOutSegmentExtraParamsPtr do not need to be supported, so these maybe should be optional. Section 8. GMPLS-LABEL-STD-MIB =================================== smicngPRO gives the following: E: f(GMPLS-LABEL-STD-MIB), (21,13) Module "MPLS-TC-STD-MIB" has already been specified in IMPORTS clause E: f(GMPLS-LABEL-STD-MIB), (481,12) Group "gmplsLabelTableGroup" is both a MANDATORY and conditional group for module "GMPLS-LABEL-STD-MIB" Compiles cleanly with smilint. Also, disconnect in the numbering of the gmplsLabelTable: | \-v-1 gmplsLabelInterface, name "InterfaceIndexOrZero", na, current | |-2 gmplsLabelIndex, Unsigned32(0..4294967295), na, current | |-3 gmplsLabelSubindex, Unsigned32(0..4294967295), na, current | |-4 gmplsLabelType, name "GmplsGeneralizedLabelTypes", rc, current ---> 5 is missing | |-6 gmplsLabelMplsLabel, name "MplsLabel", rc, current | |-7 gmplsLabelPortWavelength, Unsigned32, rc, current | |-8 gmplsLabelFreeform, name "GmplsFreeformLabel", rc, current | |-9 gmplsLabelSonetSdhSignalIndex, Integer32(0..4095), rc, current | |-10 gmplsLabelSdhVc, Integer32(0..15), rc, current | |-11 gmplsLabelSdhVcBranch, Integer32(0..15), rc, current | |-12 gmplsLabelSonetSdhBranch, Integer32(0..15), rc, current | |-13 gmplsLabelSonetSdhGroupBranch, Integer32(0..15), rc, current | |-14 gmplsLabelWavebandId, Unsigned32, rc, current | |-15 gmplsLabelWavebandStart, Unsigned32, rc, current | |-16 gmplsLabelWavebandEnd, Unsigned32, rc, current | |-17 gmplsLabelRowStatus, name "RowStatus", rc, current | \-18 gmplsLabelStorageType, name "StorageType", rc, current 29) DESCRIPTION Please change the first paragraph to (this comment applies to the other MIB modules also.) Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXX; see the RFC itself for full legal notices. 30) Please remove these statements (don't need to change any numbers). -- Notifications -- no notifications are currently defined. gmplsLabelNotifications OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 0 } 31) gmplsLabelTable OBJECT-TYPE The last part of the last paragraph is awkward: "... Labels in the tables in other MIBs are referred to using row pointer into this table. The indexing of this table provides for arbitrary indexing and also for concatenation of labels." Are you saying that other MIBs can use a row pointer to point to this table? Why would they do that if they could just use the indices directly? Also, I don't follow the comment about concatenation of labels. Could you explain this? 32) gmplsLabelEntry OBJECT-TYPE The last sentence of the DESCRIPTION, please remove the word "more" from the phrase "is more persistent." I still don't understand how the subindex provides a way to concatenate the labels. Could you give an example? 33) please switch RowStatus and StorageType (this will more closely match the other MPLS MIBs). 34) gmplsLabelInterface OBJECT-TYPE DESCRIPTION also needs to specify that zero may be used to indicate that the InterfaceIndex is not known or that an InterfaceIndex exists but it is not important wrt this implementation so zero is used. 35) gmplsLabelIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) 36a) I was expecting the SYNTAX to be IndexInteger due to the gmplsLabelIndexNext in the DESCRIPTION. Please explain why the use of zero is needed. You explain the use of zero in the gmplsLabelInterface and gmplsLabelSubindex indices. 36b)Please change the "may" to "should" in this statement: A management application may read the gmplsLabelIndexNext object to find a suitable value for this object." 37) gmplsLabelType OBJECT-TYPE of gmplsMplsLabel (1) denotes that a 23 bit MPLS packet label is present, but does not describe whether this is signaled using MPLS or GMPLS. Is this 23 bit value correct? Is this a FrameRelay DLCI label? 38) gmplsLabelRowStatus OBJECT-TYPE MUST explain which columns must be properly configured before the row can be made active (as per RFC2579) 39) Please clarify in the DESCRIPTION of each of the following groups, if the group is optional or needs to be supported by such implementations: GROUP gmplsLabelPacketGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support packet labels." GROUP gmplsLabelPortWavelengthGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support port and wavelength labels." GROUP gmplsLabelFreeformGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support freeform labels." GROUP gmplsLabelSonetSdhGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support SONET or SDH labels." GROUP gmplsLabelWavebandGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support Waveband labels." 40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE Please change the name to: gmplsLabelModuleReadOnlyCompliance to be consistent with the other MPLS and GMPLS MIB modules. 41) The ReadOnly compliance for gmplsLabelRowStatus does NOT have a MIN-ACCESS of read-only. Is this intentional? 42) Also, (related to the above) OBJECT gmplsLabelRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notInService, createAndWait and notReady is not required." The DESCRIPTION clause conflicts with the WRITE-SYNTAX. Please clarify the intentions for this ReadOnly compliance object. Section 12.2 Informational References --------------------------------------- 43a) The title of this section should be Informative. 43b) Please move the following from Informative to Normative. [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), "Generalized MPLS Signaling - CR-LDP Extensions", RFC 3472, January 2003. [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control", draft-ietf-ccamp-gmpls-sonet-sdh, work in progress. 43c) The above reference now appears to be RFC 3946. Please change the above (NOTE also the changes in the reference itself, more on the Reference format next): [GMPLS-SONET] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004. 44) There are a number of references (as discovered by Bert) that aren't in the RFC expected format. Please review all the references in this document and the other GMPLS MIB docs. Here are some to change. One suggestion is to copy a reference (if possible) from an existing RFC. Sometimes a date is missing and sometimes the authors/editors names do not appear as expected. Also, titles need to appear exactly as on the RFC. Please check the other GMPLS docs also. (NOTE: see also draft-rfc-editor-rfc2223bis-08.txt) Please change: [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. to: [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. Please change: [RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group MIB", RFC 2863, June 2000. to (author name misspelled): [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. Please change: [RFC3032] Rosen, E. et al, "MPLS Label Stack Encoding", RFC 3032, January 2001. to: [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. Please change: [RFC3212] Jamoussi, B., Aboul-Magd, O., Andersson, L., Ashwood-Smith, P., Hellstrand, F., Sundell, K., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Halpern, J., Heinanen, J., Kilty, T., Malis, A., and P. Vaananen, "Constraint-Based LSP Setup using LDP", RFC 3212, December 2001." to: [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. Please change: [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, December 2002. to: [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Please change: [RFC3413] Levi, D., Meyer, P., Stewart, B., "SNMP Applications", RFC 3413, December 2002. to: [RFC3413] Levi, D., Meyers, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. Please change: [RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. to: [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. Please change: [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. to: [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. Please change: [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), "Generalized MPLS Signaling - CR-LDP Extensions", RFC 3472, January 2003. to: [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. Please change: [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. to: [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. --- the end ---- --=====================_1126208932==_ Content-Type: text/plain; charset="us-ascii" --=====================_1126208932==_-- From owner-ccamp@ops.ietf.org Thu Sep 08 21:43:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDXvS-00037D-JA for ccamp-archive@megatron.ietf.org; Thu, 08 Sep 2005 21:43:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10070 for ; Thu, 8 Sep 2005 21:43:32 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDXys-0001KR-Ky for ccamp-archive@ietf.org; Thu, 08 Sep 2005 21:47:11 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDXl9-0007s7-KH for ccamp-data@psg.com; Fri, 09 Sep 2005 01:32:55 +0000 Received: from [207.69.200.28] (helo=pop04.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EDXl7-0007rV-Fj for ccamp@ops.ietf.org; Fri, 09 Sep 2005 01:32:53 +0000 Received: from h-66-167-248-122.cmbrmaor.dynamic.covad.net ([66.167.248.122] helo=jluciani-laptop) by pop04.mail.atl.earthlink.net with smtp (Exim 3.36 #10) id 1EDXl2-0001Pb-00; Thu, 08 Sep 2005 21:32:49 -0400 Message-Id: <3.0.1.32.20050908213717.014708c8@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 08 Sep 2005 21:37:17 -0400 To: tnadeau@cisco.com, adrian@olddog.co.uk, ccamp@ops.ietf.org From: jcucchiara@mindspring.com Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Cc: bwijnen@lucent.com, jcucchiara@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 HI Tom and Adrian, This email has 2 parts: First are comments which pertain to the 3 GMPLS MIB docs under review. I thought this was easier than repeating these comments 3 times. Following are additional comments on draft-ietf-ccamp-gmpls-tc-mib-07.txt. thanks, Joan General comments for all 3 drafts: ================================================ 1*) Suggestion only: When submitting these 3 GMPLS MIBs you may want to ask RFC-editor to give the GMPLS-TC-STD-MIB document the first RFC number, and that all 3 GMPLS MIB docs appear contiguously numbered. If you would like to incorporate this suggestion then you'd need to add a paragraph to the IANA Considerations section and put the usual RFC-editor disclaimers around your request, such as: (Note to RFC-Editor:) We request that you assign the first RFC number to the draft-ietf-ccamp-gmpls-tc-mib, and also assign contiguous numbers to all three GMPLS MIB docs, i.e. draft-ietf-ccamp-gmpls-tc-mib, draft-ietf-ccamp-gmpls-lsr-mib, and draft-ietf-ccamp-gmpls-te-mib. (Please remove this note prior to publication.) 2*) Table of Contents is incorrect, please regenerate it, (e.g. The SNMP Management Framework should be The Internet-Standard Management Framework). 3*) Question if these documents should have a contributors section. It violates the guidelines of "RFC Editorial Guidelines and Procedures" http://www.rfc-editor.org/policy.html#policy.auth2 There are many people listed under Authors but not listed on the front page, so how about adding a Contributors Section? 4*) Tom's Contact info needs to be updated to Boxborough. 5*) would be clearer to be consistent about referring to MIB modules and always use the entire MIB name and site the reference: e.g. MPLS LSR MIB module or LSR MIB module, should be MPLS-LSR-STD-MIB module [RFC3813] e.g. GMPLS LSR MIB module, should be GMPLS-LSR-STD-MIB module [RFCXXX] (NOTE to RFC-Editor: please fill in XXX with the RFC name for draft-ietf-ccamp-gmpls-lsr-mib and remove this note.) 6*) The term "extends" is used and since this term is applied to GMPLS interfaces, the more appropriate phrase is 'sparse augments'. Please change this in the text. 7*) ORGANIZATION, please add IETF as in "IETF Common Control and ...." 8*) DESCRIPTION Please change the first paragraph to: Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXX; see the RFC itself for full legal notices. The exception to this is the IANA-GMPLS-MIB module, which should include: "Copyright (C) The Internet Society (2005). The initial version of this MIB module was published in RFC XXXX. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html 9*) Please make sure to ask RFC-Editor to remove comments prior to publication, e.g. -- RFC Editor's Note (to be removed prior to publication): "Initial version published as part of RFC XXXX." -- replace XXX with actual RFC number & remove this note. 10*) Acknowledgements Section Please start off this section with: This document is a product of the CCAMP Working Group. and remove: This draft is the work of the five authors listed in the next section. 11*) Please change "Informational References" to "Informative References" 12*) There are a number of references (as discovered by Bert) that aren't in the RFC expected format. Please review all the references in this document and the other GMPLS MIB docs. Please see comments in the review of the draft-ietf-ccamp-gmpls-lsr-mib-08.txt for examples of references in the RFC format. draft-ietf-ccamp-gmpls-tc-mib-07.txt ====================================== Section 3. GMPLS Textual Conventions MIB Definitions --------------------------------------------------- 1) GmplsFreeformLabel TC 1a) Could the REFERENCE include section(s)? I suspect that this is referring to the Generalized Label described in section 3.2.1, is this correct? 1b) Please explain why this is 0..64 ? RFC3471 states that the Generalized label can be variable length, so wondering if this should be made larger? 1c) The DESCRIPTION needs a little work: DESCRIPTION "This value represents a freeform generalized MPLS Label. This can be used to represent label types which are not standard in the drafts. It may also be used by systems that do not wish to represent the labels using the specific label types." Please reword to something like: "This value represents a freeform GMPLS label. A freeform GMPLS label is specified by the system which uses it. In other words, the freeform GMPLS label is not a standard GMPLS label type, but is created by the system which uses it." 2) GmplsGeneralizedLabelTypes TC 2a) Could you change the name of the TC GmplsGeneralizedLabelTypes to GmplsLabelType It is more appropriate to have it singular when Imported and used in other MIBs, and dropping the word Generalized, because you already have the prefix Gmpls. 2b) Could the SYNTAX order be changed? Currently: SYNTAX INTEGER { gmplsMplsLabel(1), gmplsPortWavelengthLabel(2), gmplsFreeformGeneralizedLabel(3), gmplsSonetLabel(4), gmplsSdhLabel(5), gmplsWavebandLabel(6) } Proposed (NOTE also some of the names have been changed): SYNTAX INTEGER { gmplsFreeformLabelOrOther(1), gmplsMplsLabel(2), gmplsPortAndWavelengthLabel(3), gmplsSonetLabel(4), gmplsSdhLabel(5), gmplsWavebandLabel(6) } Section 4. Security Considerations ------------------------------------- 3) Change MPLS to GMPLS in the following statement: "This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MPLS MIB modules to define management objects." Section 5. IANA Considerations ------------------------------------- 4) Section 5. IANA Considerations RFC Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for "XXX" under the mib-2/mplsStdMIB subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace the "XXX" (here and in the MIB module) with the assigned value and to remove this note. 5) Section 5. IANA Considerations Please remove the last sentence of this section: "The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB." Section 6.2 Informational References. --------------------------------------- 6) Section 6.2 Informational References. Please change to "Informative". 7) I believe the following references should be moved to the Normative section: [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), "Generalized MPLS Signaling - CR-LDP Extensions", RFC 3472, January 2003. [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual Conventions and for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3945] Mannie, E. (Editor), "Generalized Multiprotocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control", draft-ietf-ccamp-gmpls-sonet-sdh, work in progress. (the above is now RFC 3946) [GMPLS-SONET] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004. Also, as previously mentioned, need to check on the format of these References. Please see comments in the review of the draft-ietf-ccamp-gmpls-lsr-mib-08.txt for examples of references in the RFC format. --- the end --- From owner-ccamp@ops.ietf.org Thu Sep 08 22:03:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDYEr-0006qn-3e for ccamp-archive@megatron.ietf.org; Thu, 08 Sep 2005 22:03:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10669 for ; Thu, 8 Sep 2005 22:03:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDYIL-0001jP-Bo for ccamp-archive@ietf.org; Thu, 08 Sep 2005 22:07:14 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDY8J-0009xn-Cc for ccamp-data@psg.com; Fri, 09 Sep 2005 01:56:51 +0000 Received: from [207.69.200.28] (helo=pop04.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EDY8H-0009xO-FC for ccamp@ops.ietf.org; Fri, 09 Sep 2005 01:56:49 +0000 Received: from h-66-167-248-53.cmbrmaor.dynamic.covad.net ([66.167.248.53] helo=jluciani-laptop) by pop04.mail.atl.earthlink.net with smtp (Exim 3.36 #10) id 1EDY6p-0006CC-00; Thu, 08 Sep 2005 21:55:20 -0400 Message-Id: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 08 Sep 2005 21:59:48 -0400 To: tnadeau@cisco.com, adrian@olddog.co.uk, ccamp@ops.ietf.org From: jcucchiara@mindspring.com Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Cc: bwijnen@lucent.com, jcucchiara@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 Hi Tom and Adrian, Here are some comments on draft-ietf-ccamp-gmpls-te-mib-09.txt. All 3 docs show a good deal of work. -Joan draft-ietf-ccamp-gmpls-te-mib-09.txt ====================================== Section 1.1 Migration Strategy ------------------------------ 1) Please remove "and OBJECT-IDENTIFIERS" Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] and [GMPLSTCMIB]. Section 5.4 gmplsTunnelCHoptable --------------------------------- 2) Please capitalize Table in the Section's title. Section 8. GMPLS Traffic Engineering MIB Module ----------------------------------------------- smicngPRO gives the following: W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should have SIZE specified W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is identical W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is identical W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is identical W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax is identical W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", syntax is identical Disconnect of numbering in the Conformance Section \-3 gmplsTeConformance \-v-1 gmplsTeGroups | \-v-1 gmplsTunnelGroup 2 is missing | |-3 gmplsTunnelSignaledGroup | |-4 gmplsTunnelScalarGroup | |-5 gmplsTunnelIsIntfcGroup | |-6 gmplsTunnelIsNotIntfcGroup | |-7 gmplsTunnelOptionalGroup | \-8 gmplsTeNotificationGroup 3) gmplsTunnelsConfigured OBJECT-TYPE SYNTAX Unsigned32 SYNTAX should be Gauge32 4) gmplsTunnelsActive OBJECT-TYPE SYNTAX Unsigned32 SYNTAX should be Gauge32 5) gmplsTunnelTable DESCRIPTION "The row status of an entry in this table is controlled by mplsTunnelRowStatus in the corresponding entry in mplsTunnelTable. That is, it is not permitted to create a row in this table, nor to modify an existing row, when the corresponding mplsTunnelRowStatus has value active(1).... The sentence beginning with "That is," is awkward. Could you say something like: A row in this table is created when a row is created in the mplsTunnelTable. Entries in this table cannot be modified when the corresponding mplsTunnelRowStatus has a value of active(1). The exception.... Please also update this other places in this MIB (e.g gmplsTunnelHopTable). 6) gmplsTunnelEntry DESCRIPTION: "... An entry can be created by a network administrator or by an SNMP agent as instructed by a signaling protocol." Please change the above to: "An entry can be created by a network administrator via SNMP SET commands, or by the network management entity as instructed by a signaling protocol." 7) gmplsTunnelUnnumIf What IF-MIB object are referring to in the DESCRIPTION? Could you state which object in the description? 8) gmplsTunnelAttributes Could you specify what happens when the bit is set (i.e. 1) vs. 0? 9) gmplsTunnelLSPEncoding The DESCRIPTION states: ...A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling is not in use. Some objects in this MIB module may be of use for MPLS signaling extensions that do not use GMPLS signaling. By setting this object to 'tunnelLspNotGmpls', an application may indicate that only those objects meaningful in MPLS should be examined.... I believe that such objects should be put in to an MPLS MIB module and not included in this GMPLS MIB module. This is also true with the gmplsTunnelErrorTable. 10) gmplsTunnelLinkProtection Same comment as with gmplsTunnelAttributes. 11) gmplsTunnelPathComp DESCRIPTION states: This object deprecates mplsTunnelHopEntryPathComp." The term "deprecates" is loaded. Perhaps something like, this object takes precedence over mplsTunnelHopEntryPathComp. In other words, for GMPLS tunnels, the value of mplsTunnelHopEntryPathComp is meaningless. 12) gmplsTunnelUpNotRecip Need to use InetAddressType and InetAddress. IpAddress is not used in MIBs anymore. Please be sure to support both v4 and v6 IP address Types. If you can't support v6 for some reason, that should be stated clearly. Please change the name of this object to: gmplsTunnelUpstreamRecipientForNotify 13) gmplsTunnelDownNotRecip Same comment as above wrt to IpAddress. Please change the name to gmplsTunnelDownstreamRecipientForNotify 14) gmplsTunnelAdminStatusFlags (please see comments regarding the name of this TC and make adjustments to the name and DESCRIPTION of this object as appropriate). 15) gmplsTunnelExtraParamsPtr OBJECT-TYPE This object does not seem appropriate for this MIB. It would seem an enterprise MIB could do something like this (and possibly not use a RowPointer) so please explain what the intention is. 16) gmplsTunnelHopTable OBJECT-TYPE The storage type for an entry in this table is inherited from mplsTunnelHopStorageType in the corresponding entry in mplsTunnelHopTable. Please change to: The storage type for this entry is given by the value of mplsTunnelHopStorageType in the corresponding entry in the mplsTunnelHopTable. 17) gmplsTunnelHopExpLabel OBJECT-TYPE DESCRIPTION "If gmplsTunnelHopLabelStatuses object indicates that a forward label is present and gmplsTunnelHopExpLabelPtr contains the value zeroDotZero, then the label to use on this hop is found in object encoded within a 32-bit integer." Think the last part of this sentence is awkward: ...to use on this hop is represented by the value of this object. 18) gmplsTunnelHopExpLabel and gmplsTunnelHopExpLabelPtr Need to add the word "Forward" in here as in gmplsTunnelHopExpForwardLabel and gmplsTunnelHopExpForwardLabelPtr That way it will be consistent with the Reverse counterparts. 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpRvrsLabelPtr Please change Rvrs to Reverse. 20) gmplsTunnelHopLabelStatuses and gmplsTunnelARHopLabelStatuses Please change Statuses to State. 21) gmplsTunnelARHopExpLable and gmplsTunnelARHopExpLabelPtr Need to add the word "Forward" in here as in gmplsTunnelARHopExpForwardLabel and gmplsTunnelARHopExpForwardLabelPtr 22) gmplsTunnelARHopExpRvrsLabel and gmplsTunnelARHopExpRvrsLabelPtr Please change Rvrs to Reverse 23) gmplsTunnelARHopProtection OBJECT-TYPE Please add what the BIT set (i.e. 1) vs. 0 means in the DESCRIPTION. 24) gmplsTunnelCHopLabelTable objects Similar comments regarding the objects in this table to those above with regard to naming conventions (Forward and Reverse) and DESCRIPTIONs. Will not repeat the details, please refer to above comments on the prior 2 tables. 25) gmplsTunnelReversePerfTable Please add to the DESCRIPTION how a user knows if this is a bidirectional tunnel (i.e. what object or objects in the gmplsTunnelTable need to have what values?). 26) gmplsTunnelReversePerfPackets Does this object represent the 32-bit value of the least significant part of the 64-bit value (which is contained in gmplsTunnelReversePerfHCPackets)? 27) gmplsTunnelReversePerfBytes Does this object represent the 32-bit value of the least significant part of the 64-bit value (which is contained in gmplsTunnelReversePerfHCBytes)? 28) gmplsTunnelErrorTable OBJECT-TYPE Since this table applies to MPLS, it should be put in a separate MIB module which is MPLS specific. The prefix of gmpls could be confusing. 29) gmplsTunnelErrorTLVs OBJECT-TYPE Need to add a variable size to this string. When the string size is 0 that would indicate that no TLVs are present, so the DESCRIPTION should be modified to reflect this. 30) gmplsTunnelErrorHelpString OBJECT-TYPE SYNTAX DisplayString DisplayString is not used in newer MIBs because it does not meet internationalization standards, better to use SnmpAdminString or something which meets internationalization standards. 31) Compliance Please move some of the following comment in the DESCRIPTION of gmplsTeModuleFullCompliance -- The mandatory group has to be implemented by all LSRs that -- originate, terminate or act as transit for TE-LSPs/tunnels. -- In addition, depending on the type of tunnels supported, other -- groups become mandatory as explained below. 32) gmplsTunnelUnnumIf does not appear in the ReadOnly compliance and it probably should. Section 11.2.1. IANA-GMPLS-MIB Definition ----------------------------------------- 33) Please change the name of this MIB to IANA-GMPLS-TC-MIB and instead of: ianaGmpls MODULE-IDENTITY please use: ianaGmplsTcMIB MODULE-IDENTITY 34) Please add the following to the DESCRIPTION: "Copyright (C) The Internet Society (2005). The initial version of this MIB module was published in RFC XXXX. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html 35) Please change GMPLS-TE-MIB's to GMPLS-TE-STD-MIB's [RFCXXX] (RFC-Editor please fill in the XXX based on the RFC number for draft-ietf-ccamp-gmpls-te-mib and remove this note) in the DESCRIPTION clauses of ALL TCs. 36) Please change the name IANAGmplsLSPEncoding to IANAGmplsLSPEncodingType. (more closely matches what's on IANA's website now) 37) Please change the name IANAGmplsGPid to IANAGmplsGeneralizedPid 38) I believe that the TC IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION should be put in the GMPLS-TC-STD-MIB or should just remain in the GMPLS-TE-STD-MIB. The reason is that this is not an assigned numbers list maintained by IANA, so should not be in the IANA GMPLS MIB. If I am incorrect about this please let me know, but I didn't see an IANA maintained Administrative Status Information enum. Additionally, this should be renamed to GmplsAdminStatusInformation which more closely matches rfc3471. 39) Several comments on the SYNTAX clause: 40a) smicngPRO gives the error E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS must be in contiguous positions SYNTAX BITS { delInProgress (0), adminDown (1), testing (2), reflect (31) } RFC2578 specifies that BITS should be contiguous (although there are exceptions to this, but this object does not seem to be an exception). Could delInProgress, be renamed to deleteInProgress ? Could adminDown be renamed to administrativelyDown? These names more closely match 3471. 40b) Please put in the specific section number on this reference (section 8?). -- the end -- From owner-ccamp@ops.ietf.org Fri Sep 09 06:42:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDgKl-0002N1-MF for ccamp-archive@megatron.ietf.org; Fri, 09 Sep 2005 06:42:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22760 for ; Fri, 9 Sep 2005 06:42:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDgOI-0005Q9-FO for ccamp-archive@ietf.org; Fri, 09 Sep 2005 06:45:57 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDgBG-0000FV-BY for ccamp-data@psg.com; Fri, 09 Sep 2005 10:32:26 +0000 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EDgBE-0000FH-5w for ccamp@ops.ietf.org; Fri, 09 Sep 2005 10:32:24 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j89AWFaT024066; Fri, 9 Sep 2005 05:32:18 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 9 Sep 2005 12:32:14 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507FC55C7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, tnadeau@cisco.com, adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Fri, 9 Sep 2005 12:32:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f [bcc to David HArrington, he also did submit comments] [David, I am not sure if you are on WG mailing list] Joan, thank you very much for your reviews. It seems to me that some WG discussion may be needed and I would also expect new revisions of the 3 documents. Alex and WG chairs, I have put the comments in the I-D tracker as well. Bert > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Friday, September 09, 2005 03:37 > To: tnadeau@cisco.com; adrian@olddog.co.uk; ccamp@ops.ietf.org > Cc: bwijnen@lucent.com; jcucchiara@mindspring.com > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > > > > HI Tom and Adrian, > > This email has 2 parts: First are comments which > pertain to the 3 GMPLS MIB docs under review. > I thought this was easier than repeating these > comments 3 times. > > Following are additional comments on > draft-ietf-ccamp-gmpls-tc-mib-07.txt. > > thanks, Joan > > > > General comments for all 3 drafts: > ================================================ > 1*) Suggestion only: > When submitting these 3 GMPLS MIBs > you may want to ask RFC-editor > to give the GMPLS-TC-STD-MIB document the first > RFC number, and that all 3 GMPLS MIB docs appear > contiguously numbered. > > If you would like to incorporate this suggestion > then you'd need to add a paragraph to the > IANA Considerations section and put the usual > RFC-editor disclaimers around your request, such > as: > > > (Note to RFC-Editor:) > We request that you assign the first RFC number > to the draft-ietf-ccamp-gmpls-tc-mib, and also > assign contiguous numbers to all three GMPLS MIB > docs, i.e. draft-ietf-ccamp-gmpls-tc-mib, > draft-ietf-ccamp-gmpls-lsr-mib, and > draft-ietf-ccamp-gmpls-te-mib. > (Please remove this note prior to publication.) > > > > 2*) Table of Contents is incorrect, please > regenerate it, (e.g. The SNMP Management Framework > should be The Internet-Standard Management Framework). > > > 3*) Question if these documents should have a > contributors section. It violates the guidelines > of "RFC Editorial Guidelines and Procedures" > http://www.rfc-editor.org/policy.html#policy.auth2 > > There are many people listed under > Authors but not listed on the front page, > so how about adding a Contributors Section? > > 4*) Tom's Contact info needs to be updated to > Boxborough. > > > 5*) would be clearer to be consistent about > referring to MIB modules and always use the entire MIB name > and site the reference: > e.g. MPLS LSR MIB module or LSR MIB module, > should be MPLS-LSR-STD-MIB module [RFC3813] > > e.g. GMPLS LSR MIB module, should be > GMPLS-LSR-STD-MIB module [RFCXXX] (NOTE to RFC-Editor: > please fill in XXX with the RFC name for > draft-ietf-ccamp-gmpls-lsr-mib and remove this note.) > > > 6*) The term "extends" is used and since this term is applied > to GMPLS interfaces, the more appropriate phrase is > 'sparse augments'. Please change this in the text. > > > > 7*) ORGANIZATION, please add IETF > as in "IETF Common Control and ...." > > > 8*) DESCRIPTION > Please change the first paragraph to: > > Copyright (C) The Internet Society (2005). This > version of > this MIB module is part of RFC XXX; see the RFC > itself for > full legal notices. > > The exception to this is the IANA-GMPLS-MIB module, which should > include: > > "Copyright (C) The Internet Society (2005). The initial version > of this MIB module was published in RFC XXXX. For full legal > notices see the RFC itself. Supplementary information > may be available on: > http://www.ietf.org/copyrights/ianamib.html > > > > > 9*) Please make sure to ask RFC-Editor to remove comments > prior to publication, e.g. > > -- RFC Editor's Note (to be removed prior to publication): > > "Initial version published as part of RFC XXXX." > -- replace XXX with actual RFC number & remove this note. > > > 10*) Acknowledgements Section > Please start off this section with: > > This document is a product of the CCAMP Working Group. > > and remove: > > This draft is the work of the five authors listed in the next > section. > > > 11*) Please change "Informational References" > to "Informative References" > > 12*) There are a number of references (as discovered by > Bert) that aren't in the RFC expected format. > Please review all the references in this document and > the other GMPLS MIB docs. > Please see comments in the review of the > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > examples of references in the RFC format. > > > > draft-ietf-ccamp-gmpls-tc-mib-07.txt > ====================================== > > Section 3. GMPLS Textual Conventions MIB Definitions > --------------------------------------------------- > > 1) GmplsFreeformLabel TC > > 1a) Could the REFERENCE include section(s)? > I suspect that this is referring to the Generalized Label > described in section 3.2.1, is this correct? > > 1b) Please explain why this is 0..64 ? > RFC3471 states that the Generalized label can be > variable length, so wondering if this should be made > larger? > > 1c) The DESCRIPTION needs a little work: > DESCRIPTION > "This value represents a freeform generalized MPLS Label. This > can be used to represent label types which are not standard in > the drafts. It may also be used by systems that do not wish to > represent the labels using the specific label types." > > Please reword to something like: > > "This value represents a freeform GMPLS label. A freeform GMPLS > label is specified by the system which uses it. In > other words, > the freeform GMPLS label is not a standard GMPLS label type, > but is created by the system which uses it." > > > 2) GmplsGeneralizedLabelTypes TC > > > 2a) Could you change the name of the TC > GmplsGeneralizedLabelTypes to > > GmplsLabelType > > It is more appropriate to have it singular when > Imported and used in other MIBs, and dropping the > word Generalized, because you already have the > prefix Gmpls. > > 2b) Could the SYNTAX order be changed? > > Currently: > > SYNTAX INTEGER { > gmplsMplsLabel(1), > gmplsPortWavelengthLabel(2), > gmplsFreeformGeneralizedLabel(3), > gmplsSonetLabel(4), > gmplsSdhLabel(5), > gmplsWavebandLabel(6) > } > > Proposed (NOTE also some of the names have been changed): > > > SYNTAX INTEGER { > gmplsFreeformLabelOrOther(1), > gmplsMplsLabel(2), > gmplsPortAndWavelengthLabel(3), > gmplsSonetLabel(4), > gmplsSdhLabel(5), > gmplsWavebandLabel(6) > } > > > > Section 4. Security Considerations > ------------------------------------- > > 3) Change MPLS to GMPLS in the following statement: > > "This module does not define any management objects. Instead, it > defines a set of textual conventions which may be used by > other MPLS > MIB modules to define management objects." > > > Section 5. IANA Considerations > ------------------------------------- > > 4) Section 5. IANA Considerations > RFC Editor's Note (to be removed prior to publication): > the IANA is requested to assign a value for "XXX" under > the mib-2/mplsStdMIB subtree and to record the assignment > in the SMI Numbers registry. > When the assignment has been made, the RFC Editor is > asked to replace the "XXX" (here and in the MIB module) with > the assigned value and to remove this note. > > > > 5) Section 5. IANA Considerations > > Please remove the last sentence of this section: > > "The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB." > > > Section 6.2 Informational References. > --------------------------------------- > > 6) Section 6.2 Informational References. > Please change to "Informative". > > 7) I believe the following references should be moved > to the Normative section: > > [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), > "Generalized MPLS Signaling - CR-LDP Extensions", > RFC 3472, January 2003. > > [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - > RSVP-TE Extensions", RFC 3473 January 2003. > > [RFC3811] Nadeau, T. and J. Cucchiara, "Definition > of Textual > Conventions and for Multiprotocol Label Switching > (MPLS) Management", RFC 3811, June 2004. > > [RFC3945] Mannie, E. (Editor), "Generalized Multiprotocol > Label Switching (GMPLS) Architecture", RFC 3945, > October 2004. > > [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), > "Generalized Multi-Protocol Label Switching > Extensions for SONET and SDH Control", > draft-ietf-ccamp-gmpls-sonet-sdh, work in > progress. > > (the above is now RFC 3946) > [GMPLS-SONET] Mannie, E. and D. Papadimitriou, > "Generalized Multi- > Protocol Label Switching (GMPLS) Extensions for > Synchronous Optical Network (SONET) and Synchronous > Digital Hierarchy (SDH) Control", RFC 3946, October > 2004. > > > Also, as previously mentioned, need to check > on the format of these References. > Please see comments in the review of the > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > examples of references in the RFC format. > > > --- the end --- > From owner-ccamp@ops.ietf.org Fri Sep 09 11:11:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDkXa-0001Z2-T6 for ccamp-archive@megatron.ietf.org; Fri, 09 Sep 2005 11:11:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09184 for ; Fri, 9 Sep 2005 11:11:44 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDkb5-0004mf-HM for ccamp-archive@ietf.org; Fri, 09 Sep 2005 11:15:30 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EDk7J-000Mxw-Vj for ccamp-data@psg.com; Fri, 09 Sep 2005 14:44:37 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EDk7H-000MxZ-08 for ccamp@ops.ietf.org; Fri, 09 Sep 2005 14:44:35 +0000 Received: from du-069-0153.access.clara.net ([217.158.132.153] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EDk70-000OVD-FO; Fri, 09 Sep 2005 15:44:23 +0100 Message-ID: <064901c5b54d$5cce2450$93849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Wijnen, Bert \(Bert\)" , , "Thomas D. Nadeau" , References: <7D5D48D2CAA3D84C813F5B154F43B15507FC55C7@nl0006exch001u.nl.lucent.com> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Fri, 9 Sep 2005 15:43:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Content-Transfer-Encoding: 7bit Many thanks to David and Bert, and especially Joan. Tom and I are wading through the comments at the moment and will send a reply as soon as we can. It seems that a good proportion of the requested changes are editorial, some are important boilerplate, and a few are related to ASN.1/SNMP. We should be able to clear them up very quickly. Bert is right that we will need new versions of the documents. Not sure if there is anything for WG discussion, but we will probably want to hold another last call just because of the number of changes. Cheers, Adrian ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: ; ; ; Sent: Friday, September 09, 2005 11:32 AM Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > [bcc to David HArrington, he also did submit comments] > [David, I am not sure if you are on WG mailing list] > > Joan, thank you very much for your reviews. > > It seems to me that some WG discussion may be needed and > I would also expect new revisions of the 3 documents. > > Alex and WG chairs, > I have put the comments in the I-D tracker as well. > > Bert > > > -----Original Message----- > > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > > Sent: Friday, September 09, 2005 03:37 > > To: tnadeau@cisco.com; adrian@olddog.co.uk; ccamp@ops.ietf.org > > Cc: bwijnen@lucent.com; jcucchiara@mindspring.com > > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > > > > > > > > HI Tom and Adrian, > > > > This email has 2 parts: First are comments which > > pertain to the 3 GMPLS MIB docs under review. > > I thought this was easier than repeating these > > comments 3 times. > > > > Following are additional comments on > > draft-ietf-ccamp-gmpls-tc-mib-07.txt. > > > > thanks, Joan > > > > > > > > General comments for all 3 drafts: > > ================================================ > > 1*) Suggestion only: > > When submitting these 3 GMPLS MIBs > > you may want to ask RFC-editor > > to give the GMPLS-TC-STD-MIB document the first > > RFC number, and that all 3 GMPLS MIB docs appear > > contiguously numbered. > > > > If you would like to incorporate this suggestion > > then you'd need to add a paragraph to the > > IANA Considerations section and put the usual > > RFC-editor disclaimers around your request, such > > as: > > > > > > (Note to RFC-Editor:) > > We request that you assign the first RFC number > > to the draft-ietf-ccamp-gmpls-tc-mib, and also > > assign contiguous numbers to all three GMPLS MIB > > docs, i.e. draft-ietf-ccamp-gmpls-tc-mib, > > draft-ietf-ccamp-gmpls-lsr-mib, and > > draft-ietf-ccamp-gmpls-te-mib. > > (Please remove this note prior to publication.) > > > > > > > > 2*) Table of Contents is incorrect, please > > regenerate it, (e.g. The SNMP Management Framework > > should be The Internet-Standard Management Framework). > > > > > > 3*) Question if these documents should have a > > contributors section. It violates the guidelines > > of "RFC Editorial Guidelines and Procedures" > > http://www.rfc-editor.org/policy.html#policy.auth2 > > > > There are many people listed under > > Authors but not listed on the front page, > > so how about adding a Contributors Section? > > > > 4*) Tom's Contact info needs to be updated to > > Boxborough. > > > > > > 5*) would be clearer to be consistent about > > referring to MIB modules and always use the entire MIB name > > and site the reference: > > e.g. MPLS LSR MIB module or LSR MIB module, > > should be MPLS-LSR-STD-MIB module [RFC3813] > > > > e.g. GMPLS LSR MIB module, should be > > GMPLS-LSR-STD-MIB module [RFCXXX] (NOTE to RFC-Editor: > > please fill in XXX with the RFC name for > > draft-ietf-ccamp-gmpls-lsr-mib and remove this note.) > > > > > > 6*) The term "extends" is used and since this term is applied > > to GMPLS interfaces, the more appropriate phrase is > > 'sparse augments'. Please change this in the text. > > > > > > > > 7*) ORGANIZATION, please add IETF > > as in "IETF Common Control and ...." > > > > > > 8*) DESCRIPTION > > Please change the first paragraph to: > > > > Copyright (C) The Internet Society (2005). This > > version of > > this MIB module is part of RFC XXX; see the RFC > > itself for > > full legal notices. > > > > The exception to this is the IANA-GMPLS-MIB module, which should > > include: > > > > "Copyright (C) The Internet Society (2005). The initial version > > of this MIB module was published in RFC XXXX. For full legal > > notices see the RFC itself. Supplementary information > > may be available on: > > http://www.ietf.org/copyrights/ianamib.html > > > > > > > > > > 9*) Please make sure to ask RFC-Editor to remove comments > > prior to publication, e.g. > > > > -- RFC Editor's Note (to be removed prior to publication): > > > > "Initial version published as part of RFC XXXX." > > -- replace XXX with actual RFC number & remove this note. > > > > > > 10*) Acknowledgements Section > > Please start off this section with: > > > > This document is a product of the CCAMP Working Group. > > > > and remove: > > > > This draft is the work of the five authors listed in the next > > section. > > > > > > 11*) Please change "Informational References" > > to "Informative References" > > > > 12*) There are a number of references (as discovered by > > Bert) that aren't in the RFC expected format. > > Please review all the references in this document and > > the other GMPLS MIB docs. > > Please see comments in the review of the > > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > > examples of references in the RFC format. > > > > > > > > draft-ietf-ccamp-gmpls-tc-mib-07.txt > > ====================================== > > > > Section 3. GMPLS Textual Conventions MIB Definitions > > --------------------------------------------------- > > > > 1) GmplsFreeformLabel TC > > > > 1a) Could the REFERENCE include section(s)? > > I suspect that this is referring to the Generalized Label > > described in section 3.2.1, is this correct? > > > > 1b) Please explain why this is 0..64 ? > > RFC3471 states that the Generalized label can be > > variable length, so wondering if this should be made > > larger? > > > > 1c) The DESCRIPTION needs a little work: > > DESCRIPTION > > "This value represents a freeform generalized MPLS Label. This > > can be used to represent label types which are not standard in > > the drafts. It may also be used by systems that do not wish to > > represent the labels using the specific label types." > > > > Please reword to something like: > > > > "This value represents a freeform GMPLS label. A freeform GMPLS > > label is specified by the system which uses it. In > > other words, > > the freeform GMPLS label is not a standard GMPLS label type, > > but is created by the system which uses it." > > > > > > 2) GmplsGeneralizedLabelTypes TC > > > > > > 2a) Could you change the name of the TC > > GmplsGeneralizedLabelTypes to > > > > GmplsLabelType > > > > It is more appropriate to have it singular when > > Imported and used in other MIBs, and dropping the > > word Generalized, because you already have the > > prefix Gmpls. > > > > 2b) Could the SYNTAX order be changed? > > > > Currently: > > > > SYNTAX INTEGER { > > gmplsMplsLabel(1), > > gmplsPortWavelengthLabel(2), > > gmplsFreeformGeneralizedLabel(3), > > gmplsSonetLabel(4), > > gmplsSdhLabel(5), > > gmplsWavebandLabel(6) > > } > > > > Proposed (NOTE also some of the names have been changed): > > > > > > SYNTAX INTEGER { > > gmplsFreeformLabelOrOther(1), > > gmplsMplsLabel(2), > > gmplsPortAndWavelengthLabel(3), > > gmplsSonetLabel(4), > > gmplsSdhLabel(5), > > gmplsWavebandLabel(6) > > } > > > > > > > > Section 4. Security Considerations > > ------------------------------------- > > > > 3) Change MPLS to GMPLS in the following statement: > > > > "This module does not define any management objects. Instead, it > > defines a set of textual conventions which may be used by > > other MPLS > > MIB modules to define management objects." > > > > > > Section 5. IANA Considerations > > ------------------------------------- > > > > 4) Section 5. IANA Considerations > > RFC Editor's Note (to be removed prior to publication): > > the IANA is requested to assign a value for "XXX" under > > the mib-2/mplsStdMIB subtree and to record the assignment > > in the SMI Numbers registry. > > When the assignment has been made, the RFC Editor is > > asked to replace the "XXX" (here and in the MIB module) with > > the assigned value and to remove this note. > > > > > > > > 5) Section 5. IANA Considerations > > > > Please remove the last sentence of this section: > > > > "The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB." > > > > > > Section 6.2 Informational References. > > --------------------------------------- > > > > 6) Section 6.2 Informational References. > > Please change to "Informative". > > > > 7) I believe the following references should be moved > > to the Normative section: > > > > [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), > > "Generalized MPLS Signaling - CR-LDP Extensions", > > RFC 3472, January 2003. > > > > [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - > > RSVP-TE Extensions", RFC 3473 January 2003. > > > > [RFC3811] Nadeau, T. and J. Cucchiara, "Definition > > of Textual > > Conventions and for Multiprotocol Label Switching > > (MPLS) Management", RFC 3811, June 2004. > > > > [RFC3945] Mannie, E. (Editor), "Generalized Multiprotocol > > Label Switching (GMPLS) Architecture", RFC 3945, > > October 2004. > > > > [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), > > "Generalized Multi-Protocol Label Switching > > Extensions for SONET and SDH Control", > > draft-ietf-ccamp-gmpls-sonet-sdh, work in > > progress. > > > > (the above is now RFC 3946) > > [GMPLS-SONET] Mannie, E. and D. Papadimitriou, > > "Generalized Multi- > > Protocol Label Switching (GMPLS) Extensions for > > Synchronous Optical Network (SONET) and Synchronous > > Digital Hierarchy (SDH) Control", RFC 3946, October > > 2004. > > > > > > Also, as previously mentioned, need to check > > on the format of these References. > > Please see comments in the review of the > > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > > examples of references in the RFC format. > > > > > > --- the end --- > > > > > From 022kirk@accessus.net Sat Sep 10 03:32:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDzqx-000433-Ae for ccamp-archive@megatron.ietf.org; Sat, 10 Sep 2005 03:32:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21133 for ; Sat, 10 Sep 2005 03:32:33 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDzuU-00085A-9r for ccamp-archive@ietf.org; Sat, 10 Sep 2005 03:36:27 -0400 Received: from pool-68-160-192-159.ny325.east.verizon.net ([68.160.192.159]) by mx2.foretec.com with smtp (Exim 4.24) id 1EDzqf-0006OX-R8 for ccamp-archive@ietf.org; Sat, 10 Sep 2005 03:32:30 -0400 Message-ID: From: "Vanessa J. Smith" <022kirk@accessus.net> To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?T2ZmaWNlIHNvZnR3YXJlIC0gd2hvbGVzYWxlIHByaWNl?= Date: Sat, 10 Sep 2005 11:20:14 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_96CFF11E.90976338" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.6 (++++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0000_96CFF11E.90976338 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_6B7618A0.677678E3" ------=_NextPart_001_0001_6B7618A0.677678E3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Access all the popular software possible for extremely low prices! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $209.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $149.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Enter here: http://www.softforyou.biz Best, Vanessa J. Smith _____________________________________________________ To stop further mailings, go here _____________________________________________________ ------=_NextPart_001_0001_6B7618A0.677678E3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Access all the popular software possible for extremely low prices!
We sell software 2-6 times cheaper than retail price.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$209.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special Offers:
$149.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... Enter here:

http://www.softforyou.biz

Best,
Vanessa J. Smith


_____________________________________________________
To stop further mailings, go here
_____________________________________________________

------=_NextPart_001_0001_6B7618A0.677678E3-- ------=_NextPart_000_0000_96CFF11E.90976338-- From owner-ccamp@ops.ietf.org Mon Sep 12 15:59:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuT4-0005fu-3j for ccamp-archive@megatron.ietf.org; Mon, 12 Sep 2005 15:59:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12383 for ; Mon, 12 Sep 2005 15:59:44 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEuXA-0007ZN-I4 for ccamp-archive@ietf.org; Mon, 12 Sep 2005 16:04:08 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EEuJh-0007sf-5B for ccamp-data@psg.com; Mon, 12 Sep 2005 19:50:13 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EEuJg-0007sQ-Fq for ccamp@ops.ietf.org; Mon, 12 Sep 2005 19:50:12 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EEuJW-0004CN-8L; Mon, 12 Sep 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-03.txt Message-Id: Date: Mon, 12 Sep 2005 15:50:02 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --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 : GMPLS - Communication of Alarm Information Author(s) : L. Berger Filename : draft-ietf-ccamp-gmpls-alarm-spec-03.txt Pages : 18 Date : 2005-9-12 This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-alarm-spec-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-ietf-ccamp-gmpls-alarm-spec-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: <2005-9-12110024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-alarm-spec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-12110024.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Sep 13 11:51:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFD4f-0003h0-EU for ccamp-archive@megatron.ietf.org; Tue, 13 Sep 2005 11:51:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28315 for ; Tue, 13 Sep 2005 11:51:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFD94-0005g4-HD for ccamp-archive@ietf.org; Tue, 13 Sep 2005 11:56:32 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFCt5-000P0O-B0 for ccamp-data@psg.com; Tue, 13 Sep 2005 15:39:59 +0000 Received: from [205.177.121.2] (helo=ns1.cpanel.btnaccess.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EFCt1-000P07-Uk for ccamp@ops.ietf.org; Tue, 13 Sep 2005 15:39:56 +0000 Received: from [65.213.193.26] (helo=ISODELL002) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1EFCsz-00006n-D2 for ccamp@ops.ietf.org; Tue, 13 Sep 2005 11:39:53 -0400 From: "MPLS 2005" To: Subject: MPLS 2005: Early Registration Deadline in 4 Days Date: Tue, 13 Sep 2005 11:37:41 -0400 Message-ID: <000c01c5b879$172dfa90$1ac1d541@workgroup> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C5B857.901C5A90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_80_90, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.3 (+) X-Scan-Signature: 780d9f1798aa5434ee8803f94549e87a This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5B857.901C5A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MPLS 2005 International Conference October 16-19, 2005 Omni Shoreham Hotel Washington, DC _____ MPLS 2005 International Conference will be held from Sunday October 16 through Wednesday October 19, 2005 at the Omni Shoreham Hotel in Washington DC. Registration for the MPLS 2005 International Conference is now open, with only FOUR days left to take advantage of the discounted registration rates [early registration discount cut off date is September 17]. Go to www.mpls2005.com/registration.htm to register. Take advantage of this opportunity and register NOW! Conference Program: Sunday, October 16 10:30 - 12:00 am Tutorial 1: Scaling Considerations for MPLS Protocols and Applications - Ina Minei, Juniper Networks 1:00 - 2:30 pm Tutorial 2: Inter-Provider MPLS -Azhar Sayeed and Santiago Alvarez, Cisco Systems 2:45 - 4:15 pm Tutorial 3: Metro Ethernet 4:30 - 6:00 pm Tutorial 4: MPLS Network Operations and Management - Peter Busschbach, Lucent Technologies Monday, October 17 8:30 - 10:15 am * Introduction * Opening Speech * Keynote Speech * MPLS, GMPLS and Pseudowires: The Need for Cooperation Between Standards Bodies - Adrian Farrel, IETF Break & Exhibits 10:45 am - 12:30 pm Pseudowires: Extending the reach * Interprovider Pseudowires - Luca Martini, Cisco Systems * Multi-Hop PWs: "A small step for PWs , a giant step for Metro Convergence?" - David McDysan , MCI & Florin Balus , Nortel Networks * Multi segment Pseudo-Wires using RSVP-TE - Ron Bonica , Juniper Networks * OAM for Multihop Pseudowires - Thomas Nadeau, Cisco Systems Lunch & Exhibits 2:00 - 3:30 pm What do we want from multicast MPLS and Point-to-Multipoint Traffic Engineering? * MPLS P2MP: from the needs definition to the solutions description - Renaud Moignard, France Telecom * Design Considerations for Multicast MPLS/BGP VPNs - Maria Napierala, ATT Labs * Carrier-Grade Multicast Deployment in MPLS Backbones - Nicolai Leymann, T-Systems * Multicast VPN Deployment Scenarios and Service Requirements - Seisho Yasukawa, NTT Break & Exhibits 4:00 - 5:00 pm Ethernet in the Metro Network - What is the role for MPLS? * Metro Ethernet and MPLS - Kireeti Kompella, Juniper Networks * MPLS, Ethernet and the Metro - David Allan, Nortel Networks * GMPLS Controlled Ethernet Networks - Loa Andersson, Acreo 5:00 - 6:00 pm Panel: Advanced Services Using MPLS Panelists from selected ISP/Carriers 6:00 - 7:30 pm: Reception & Exhibits Reception Hosted by Avici Systems Tuesday, October 18 8:30 - 10:15 am Broadband Services - Enabling the future * Broadband, the Next Revolution - What it Means to an MPLS Network - Sangeeta Anand, Cisco Systems * Realizing services across regions utilizing dissimilar convergence layers - Andy Malis and Jonathan Sadler, Tellabs * Broadband Services using MPLS - Kurt Melden, Juniper * Enhanced architecture model that deploys MPLS-enabled Ethernet-based Aggregation in DSL networks for Triple Play services - Sunil Khandekar, Alcatel * Subscriber Aware MPLS for Broadband Services - Arpit Joshipura, Redback Networks Break & Exhibits 10:45 - 12:30 am Building blocks for Advanced Services in MPLS Networks * Combining RSVP and MPLS for Scalable Admission Control - Bruce Davie, Cisco Systems * Assuring QoS: Delivering Real Time Services with MPLS Networks - Sridhar Ramachandran, Nextone * LSP Hierarchy in MPLS networks - Arthi Ayyangar, Juniper Networks * VPN Route Reflector Architectures and Operational Impacts - Eric Brendel, Chiaro Networks * Secure MPLS Backbone Design to Support IMS - Scott Poretsky , Reef Point Systems Lunch & Exhibits 12:30 - 2:00 pm 2:00 - 3:30 pm Interworking MPLS and GMPLS * Applicability of GMPLS to Packet LSPs and MPLS to GMPLS Migration Methods - Dimitri Papadimitriou, Alcatel * Investigation of deployment scenarios for a GMPLS network migrating into an existing IP/MPLS network - Tomohiro Otani, Kenichi Ogaki, Hideaki Tanaka (KDDI), Mallik Tatipamula & Zafar Ali (Cisco) * MPLS and GMPLS interworking - Kohei Shiomoto, NTT * Operational, Deployment and Interworking Considerations for GMPLS Technology - Zafar Ali, Cisco Systems Break & Exhibits 4:00 - 5:00 pm MPLS in Enterprise Networks - Experiences from Deployment * Deploying, interworking and operating L2 and L3 MPLS VPNs - MPLS deployment experience: scaling, performance and security - Peter Himmelberger, CSC * Enterprise Customer Deployment - Tom McKinney, Cisco Systems * An All Encompassing MPLS-Enabled VPN - Lee Jalali, Sprint 5:00 - 6:00 pm Vendor's Panel Session: LDP vs. RSVP-TE Panelists from selected vendors Exhibits 6:00 - 7:30 pm Wednesday, October 19 8:30 - 10:00 am Generalized MPLS in the Optical Network * Overview of GMPLS interworking test in Japan and NICT Keihana GMPLS E-NNI trials - Naoaki Yamanaka * Next Generation IP/Optical Integrated Network in KDDI - Masatoshi Suzuki and Tomohiro Otani, KDDI * Extending GMPLS for Pure Photonic Networks - Don Fedyk & Vik Saxena Nortel Networks & Comcast * Dynamic optical link preemption based on GMPLS traffic engineering - Shinya Tanaka , Japan Telecom * The Unified Optical Control Plane: The Time is Now - Vijay Pandian, Sycamore Networks Break & Exhibits 10:45 - 12:30 am Experiences from the Front Line - Building MPLS Networks for Advanced and Triple-play Services * IPv6 and MPLS - Daniel Awduche, MCI * Case Study: Building A Successful Full Packet Voice Network and IP Network - Hamid Laamouri & Cristina Gentili , WANDL & Telecom Italia * IP/MPLS for Live Broadcast Video Applications, Ryan Korte, WilTel Communications * Telenor's pan- nordic NG multiservice network - Lei Wang, Telenor * Some Considerations in the SLA Delivery for MPLS Enabled Networks - Roman Krzanowski , Verizon Lunch & Exhibits 12:30 - 2:00 pm 2:00 - 3:00 pm Supporting multicast traffic in MPLS networks * Multicast LDP - IJsbrand Wijnands, Cisco Systems * Next-Generation Solutions for Multicast in 2547 VPNs and VPLS - Rahul Aggarwal, Juniper Networks * VPLS Multicast challenges and options, Marc Lasserre, Riverstone Break 3:15 - 4:45 pm Multi-domain MPLS - Now we can all talk together * PCE (Path Computation Element) models: architecture and applications - JP Vasseur, Cisco Systems * Advanced MPLS L3 VPN deployment and challenges - Inter-provider VPNs, VoIP support, and MVPNs - Luyuan Fang, AT&T Labs * Inter-AS Security Factors and Best Practice Guidelines, Monique Morrow, Cisco Systems * Multi-layer traffic engineering with PCE in MPLS/GMPLS networks - Eiji Oki, NTT ------=_NextPart_000_000D_01C5B857.901C5A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

MPLS 2005 International Conference
October 16-19, 2005
Omni = Shoreham Hotel
Washington, = DC=

MPLS 2005 International Conference will be held from Sunday October 16 through = Wednesday October 19, = 2005 at the Omni Shoreham Hotel in Washington = DC.

Registration for the MPLS 2005 International Conference is now open, with only FOUR = days left to take advantage of the discounted registration rates [early = registration discount cut off date is September 17]. Go to = www.mpls2005.com/registration.htm= to register.

Take advantage of this = opportunity and register NOW!

Conference Program:

Sunday, October 16

10:30 - 12:00 = am

Tutorial 1: Scaling Considerations for MPLS = Protocols and Applications - Ina Minei, Juniper = Networks

1:00 - 2:30 = pm

Tutorial 2: Inter-Provider MPLS = -Azhar Sayeed and Santiago = Alvarez, Cisco Systems

2:45 - 4:15 = pm

Tutorial 3: Metro = Ethernet

4:30 - 6:00 = pm

Tutorial 4: MPLS Network Operations and Management = - Peter Busschbach, Lucent Technologies

 

Monday, October 17

8:30 - 10:15 = am

·     Introduction
·     Opening Speech
·     Keynote Speech
·     MPLS, GMPLS and Pseudowires: The Need for Cooperation Between Standards = Bodies - Adrian Farrel, IETF

Break & Exhibits

10:45 am - 12:30 = pm
Pseudowires: Extending the = reach

·     Interprovider Pseudowires - Luca Martini, Cisco Systems
·     Multi-Hop PWs: "A small step = for PWs , a giant step for Metro Convergence?" - David McDysan , MCI = & Florin Balus , Nortel Networks
·     Multi segment Pseudo-Wires using = RSVP-TE - Ron Bonica , Juniper Networks
·     OAM for Multihop Pseudowires - = Thomas Nadeau, Cisco Systems

Lunch & = Exhibits

2:00 - 3:30 = pm
What do we want from multicast = MPLS and Point-to-Multipoint Traffic Engineering?

·     MPLS P2MP: from the needs = definition to the solutions description - Renaud = Moignard, = France Telecom
·     Design Considerations for = Multicast MPLS/BGP VPNs - Maria Napierala, ATT Labs
·     Carrier-Grade Multicast = Deployment in MPLS Backbones - Nicolai Leymann, T-Systems
·     Multicast VPN Deployment = Scenarios and Service Requirements - Seisho Yasukawa, NTT

Break & = Exhibits

4:00 - 5:00 = pm
Ethernet in the Metro Network - = What is the role for MPLS?

·     Metro Ethernet and MPLS - Kireeti Kompella, Juniper Networks
·     MPLS, Ethernet and the Metro - = David Allan, Nortel Networks
·     GMPLS Controlled Ethernet = Networks - Loa Andersson, Acreo

5:00 - 6:00 = pm
Panel: Advanced Services Using = MPLS

Panelists from selected ISP/Carriers

6:00 - 7:30 = pm: = Reception & Exhibits
Reception Hosted by Avici Systems

 

Tuesday, October 18

8:30 - 10:15 = am
Broadband Services – = Enabling the future

·     Broadband, the Next Revolution - What it Means to an = MPLS Network - Sangeeta Anand, Cisco Systems
·     Realizing services across regions utilizing dissimilar convergence layers - Andy Malis and Jonathan Sadler, Tellabs
·     Broadband Services using MPLS - Kurt Melden, Juniper
·     Enhanced architecture model that deploys MPLS-enabled Ethernet-based Aggregation in DSL networks for Triple Play services - = Sunil Khandekar, Alcatel
·     Subscriber Aware MPLS for Broadband Services - Arpit = Joshipura, Redback Networks

Break & = Exhibits

10:45 - 12:30 = am
Building blocks for Advanced = Services in MPLS Networks

·     Combining RSVP and MPLS for Scalable Admission Control - = Bruce Davie, Cisco Systems
·     Assuring QoS: Delivering Real Time Services with MPLS = Networks - Sridhar Ramachandran, Nextone
·     LSP Hierarchy in MPLS networks - Arthi Ayyangar, Juniper Networks
·     VPN = Route Reflector Architectures and Operational Impacts - Eric Brendel, Chiaro = Networks
·     Secure MPLS Backbone Design to Support IMS - Scott = Poretsky , Reef Point Systems

Lunch & Exhibits 12:30 – 2:00 pm

2:00 - 3:30 pm =
Interworking MPLS and GMPLS =

·     Applicability of GMPLS to Packet LSPs and MPLS to GMPLS Migration Methods - Dimitri Papadimitriou, Alcatel
·     Investigation of deployment scenarios for a GMPLS = network migrating into an existing IP/MPLS network - Tomohiro Otani, Kenichi = Ogaki, Hideaki Tanaka (KDDI), Mallik Tatipamula & Zafar Ali (Cisco)
·     MPLS and GMPLS interworking - Kohei Shiomoto, NTT
·     Operational, Deployment and Interworking Considerations = for GMPLS Technology - Zafar Ali, Cisco Systems

Break & = Exhibits

4:00 - 5:00 pm =
MPLS in = Enterprise Networks - Experiences from Deployment =

·     Deploying, interworking and operating L2 and L3 MPLS = VPNs - MPLS deployment experience: scaling, performance and security - Peter Himmelberger, CSC
·     Enterprise = Customer Deployment - Tom McKinney, Cisco Systems
·     An All Encompassing MPLS-Enabled VPN - Lee Jalali, = Sprint

5:00 - 6:00 = pm
Vendor’s Panel Session: LDP = vs. RSVP-TE

Panelists from selected vendors

Exhibits 6:00 - 7:30 pm

 

Wednesday, October 19

8:30 - 10:00 = am
Generalized MPLS in the Optical Network

·     Overview of GMPLS interworking test in Japan and NICT = Keihana GMPLS E-NNI trials - Naoaki Yamanaka
·     Next Generation IP/Optical Integrated Network in KDDI - Masatoshi Suzuki and Tomohiro Otani, KDDI
·     Extending GMPLS for Pure Photonic Networks - Don Fedyk = & Vik Saxena Nortel Networks & Comcast
·     Dynamic optical link preemption based on GMPLS traffic engineering - Shinya Tanaka , = Japan Telecom
·     The Unified Optical Control Plane: The Time is Now - = Vijay Pandian, Sycamore Networks

Break & = Exhibits

10:45 - 12:30 = am
Experiences from the Front Line - = Building MPLS Networks for Advanced and Triple-play Services =

·     IPv6 and MPLS - Daniel Awduche, MCI
·     Case Study: Building A Successful Full Packet Voice = Network and IP Network - Hamid Laamouri & = Cristina Gentili , WANDL & Telecom Italia
·     IP/MPLS for Live Broadcast Video Applications, Ryan = Korte, WilTel Communications
·     Telenor's pan- nordic NG multiservice network - Lei = Wang, Telenor
·     Some Considerations in the SLA = Delivery for MPLS Enabled Networks - Roman Krzanowski , Verizon

Lunch & Exhibits 12:30 – 2:00 pm

2:00 - 3:00 = pm
Supporting multicast traffic in = MPLS networks

·     Multicast LDP - IJsbrand Wijnands, Cisco Systems
·     Next-Generation Solutions for Multicast in 2547 VPNs and = VPLS - Rahul Aggarwal, Juniper Networks
·     VPLS Multicast challenges and options, Marc Lasserre, Riverstone

Break

3:15 - 4:45 = pm
Multi-domain MPLS - Now we can all = talk together

·     PCE (Path Computation Element) models: architecture and applications - JP Vasseur, Cisco Systems
·     Advanced MPLS L3 VPN deployment and challenges - = Inter-provider VPNs, VoIP support, and MVPNs - Luyuan Fang, AT&T Labs
·     Inter-AS Security Factors and Best Practice Guidelines, = Monique Morrow, Cisco Systems
·     Multi-layer traffic engineering with PCE in MPLS/GMPLS = networks - Eiji Oki, NTT

 

------=_NextPart_000_000D_01C5B857.901C5A90-- From Can@eon.dk Wed Sep 14 08:07:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFW2w-0000G8-3q; Wed, 14 Sep 2005 08:07:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06711; Wed, 14 Sep 2005 08:07:24 -0400 (EDT) Received: from [85.99.197.77] (helo=deliveryman.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFW7U-0008Vo-0Z; Wed, 14 Sep 2005 08:12:11 -0400 From: "Garcia Ricardo" To: "Bourmakina Toma" Subject: Re[4]: Date: Wed, 14 Sep 2005 12:07:26 +0000 Message-ID: <53f001c5b924$0167dcc8$54007977@deliveryman.com> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_7A89_B53D40CE.1F627A89" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1441 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Antivirus: avast! (VPS 0537-0, 12.09.2005), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 1.6 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_7A89_B53D40CE.1F627A89 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Best choice for those who have it! Go on, give it a try. You'll sure enjoy it! SPUR-m [Cum pills]: http://brachia.com/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_7A89_B53D40CE.1F627A89 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Best choice for those who have it!
 
Go on, give it a try. = You'll sure=20 enjoy it!
SPUR-m [Cum pills]: http://brachia.com/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_7A89_B53D40CE.1F627A89-- From Galonka@gyaloglo.hu Wed Sep 14 14:07:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFbfK-0004VY-Fn; Wed, 14 Sep 2005 14:07:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24185; Wed, 14 Sep 2005 14:07:25 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFbjw-0000b6-Om; Wed, 14 Sep 2005 14:12:14 -0400 Received: from 85-64-187-172.barak-online.net ([85.64.187.172] helo=iname.com) by mx2.foretec.com with smtp (Exim 4.24) id 1EFanF-0001AX-0b; Wed, 14 Sep 2005 13:11:33 -0400 From: "Kao Constance" To: "Howard Kathy" Subject: Re[6]: Date: Wed, 14 Sep 2005 18:07:28 +0000 Message-ID: <46e801c5b957$0608edf9$54007977@iname.com> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_40CE_1F627A89.B53D40CE" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.3 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_40CE_1F627A89.B53D40CE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Increase the size of your penis by up to 30% with MORE-SIZE Go on, give it a try. You'll sure enjoy it! MORE-SIZE: http://efficacies.net/more/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_40CE_1F627A89.B53D40CE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Increase the size of your penis by up to 30% with MORE-SIZE
 
Go on, give it a try. = You'll sure=20 enjoy it!
MORE-SIZE: http://efficacies.net/more/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_40CE_1F627A89.B53D40CE-- From owner-ccamp@ops.ietf.org Wed Sep 14 21:04:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFiB6-0008Hv-BV for ccamp-archive@megatron.ietf.org; Wed, 14 Sep 2005 21:04:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24297 for ; Wed, 14 Sep 2005 21:04:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFiFo-0006RZ-8G for ccamp-archive@ietf.org; Wed, 14 Sep 2005 21:09:32 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EFi2v-000Dx8-FU for ccamp-data@psg.com; Thu, 15 Sep 2005 00:56:13 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EFi2t-000Dwm-L6 for ccamp@ops.ietf.org; Thu, 15 Sep 2005 00:56:11 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j8F0uB949434; Wed, 14 Sep 2005 17:56:11 -0700 (PDT) (envelope-from arthi@juniper.net) Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j8F0u5G27156; Wed, 14 Sep 2005 17:56:05 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Wed, 14 Sep 2005 17:56:05 -0700 (PDT) From: Arthi Ayyangar To: Adrian Farrel cc: "'Jean Philippe Vasseur'" , ccamp@ops.ietf.org Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt In-Reply-To: <0c2201c5aa65$e0b4c7d0$c5919ed9@Puppy> Message-ID: <20050914174809.A77537@zircon.juniper.net> References: <0c2201c5aa65$e0b4c7d0$c5919ed9@Puppy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi Adrian, Sorry for the delay (as usual) and thanks for your comments (as usual). I have incorporated your comments and suggestions for the next rev. Just one major point of contention. See below. > Section 4.1 (also section 9.1) > 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end > node that originates the inter-domain TE LSP if it desires a > contiguous end-to-end TE LSP (in the control & data plane). When set, > this indicates that a boundary node MUST not perform any stitching or > nesting on the TE LSP and the TE LSP MUST be routed as any other TE > LSP (it must be contiguous end to end). When this bit is cleared, a > boundary node may decide to perform stitching or nesting. A mid-point > node not supporting contiguous TE LSP MUST send a Path Error message > > a. s/MUST not/MUST NOT/ > b. I have allocated bit number 4 (0x08) in the temporary registry of > LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp-attrib.txt as > a place holder until the IANA takes over this work. (I think we've > discussed this before - the point of the temporary registry is to save ---------> This has been 0x01 for Contiguous LSP desired and 0x02 for Stitching desired since the beginning of any of these drafts, through the merger and split. And I remember that the LSP Attributes registry used to carry the matching numbers before. But looks like other drafts have appeared and now the numbers for the inter-domain IDs in the registry no longer match the ones in the IDs. Just one point that these inter-domain IDs predate most of the other IDs actually (in fact we went the LSP ATTRIBUTES path because we ran out of bits for the inter-domain IDs), so I am not sure what you propose we do at this point. thanks, -arthi From Yancheva@spl.at Thu Sep 15 10:41:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFuw2-0001lv-RU; Thu, 15 Sep 2005 10:41:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15334; Thu, 15 Sep 2005 10:41:56 -0400 (EDT) Received: from 201-26-71-185.dsl.telesp.net.br ([201.26.71.185] helo=dotcom.fr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFv0n-0002tj-I9; Thu, 15 Sep 2005 10:46:57 -0400 From: "Schriber Pascal" To: "Ghislain Ogandaga" Subject: Re[5]: Date: Thu, 15 Sep 2005 14:41:55 +0000 Message-ID: <1f0601c5ba03$1609b3e1$54007977@dotcom.fr> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1F62_7A89B53D.40CE1F62" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 2.8 (++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_1F62_7A89B53D.40CE1F62 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SPUR-m [Sperm pills] - faster, bigger, better! Go on, give it a try. You'll sure enjoy it! SPUR-m [Cum pills]: http://rehire.net/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_1F62_7A89B53D.40CE1F62 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SPUR-m [Sperm pills] - faster, bigger, better!
 
Go on, give it a try. = You'll sure=20 enjoy it!
SPUR-m [Cum pills]: http://rehire.net/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_1F62_7A89B53D.40CE1F62-- From Rossi@o2.pl Thu Sep 15 11:15:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFvSa-0002uY-Lk; Thu, 15 Sep 2005 11:15:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17192; Thu, 15 Sep 2005 11:15:33 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFvXP-0003pu-2b; Thu, 15 Sep 2005 11:20:36 -0400 Received: from [85.100.22.16] (helo=uolmail.com.mx) by mx2.foretec.com with smtp (Exim 4.24) id 1EFvSR-0000nG-Up; Thu, 15 Sep 2005 11:15:28 -0400 From: "Tench Tracey" To: "Bruns Alfred" Subject: Re[5]: Date: Thu, 15 Sep 2005 15:15:30 +0000 Message-ID: <41fd01c5ba08$027e690f$54007977@uolmail.com.mx> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1F62_7A89B53D.40CE1F62" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_1F62_7A89B53D.40CE1F62 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Miracles happen sometimes - we have sex! Go on, give it a try. You'll sure enjoy it! Cialis Softtabs: http://unglazed.net/now/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_1F62_7A89B53D.40CE1F62 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Miracles happen sometimes - we have sex!
 
Go on, give it a try. = You'll sure=20 enjoy it!
Cialis Softtabs: http://unglazed.net/now/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_1F62_7A89B53D.40CE1F62-- From Morin@sol.dk Thu Sep 15 14:09:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyAn-000854-Iw; Thu, 15 Sep 2005 14:09:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24524; Thu, 15 Sep 2005 14:09:18 -0400 (EDT) Received: from ip51cd5692.speed.planet.nl ([81.205.86.146] helo=slovenia-cafe.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EFyFY-0008CO-4u; Thu, 15 Sep 2005 14:14:21 -0400 From: "Libera Maciek" To: "Carpenter Mark" Subject: Re[9]: Date: Thu, 15 Sep 2005 18:09:20 +0000 Message-ID: <349501c5ba20$0cb529d0$54007977@slovenia-cafe.com> X-SA-Do-Not-Rej: Yes MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_B53D_40CE1F62.7A89B53D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_B53D_40CE1F62.7A89B53D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Take MORE-SIZE and be Superman! Go on, give it a try. You'll sure enjoy it! MORE-SIZE: http://efficacies.net/more/ Discreet, unmarked packaging. >>> NB: No prescription required ------=_NextPart_000_B53D_40CE1F62.7A89B53D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Take MORE-SIZE and be Superman!
 
Go on, give it a try. = You'll sure=20 enjoy it!
MORE-SIZE: http://efficacies.net/more/
 
Discreet, unmarked=20 packaging.
 
>>> NB: No = prescription=20 required
------=_NextPart_000_B53D_40CE1F62.7A89B53D-- From owner-ccamp@ops.ietf.org Sun Sep 18 22:35:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHBVJ-0003ai-CU for ccamp-archive@megatron.ietf.org; Sun, 18 Sep 2005 22:35:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10443 for ; Sun, 18 Sep 2005 22:35:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHBao-0000d9-Ai for ccamp-archive@ietf.org; Sun, 18 Sep 2005 22:41:20 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHBHO-000CiL-WD for ccamp-data@psg.com; Mon, 19 Sep 2005 02:21:15 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1EHBHL-000Ci4-AK for ccamp@ops.ietf.org; Mon, 19 Sep 2005 02:21:11 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j8J2LA989635; Sun, 18 Sep 2005 19:21:10 -0700 (PDT) (envelope-from arthi@juniper.net) Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j8J2KvG31144; Sun, 18 Sep 2005 19:21:05 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Sun, 18 Sep 2005 19:20:57 -0700 (PDT) From: Arthi Ayyangar To: Adrian Farrel cc: "'Jean Philippe Vasseur'" , ccamp@ops.ietf.org Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt In-Reply-To: <0be701c5bc9c$e0651c50$28849ed9@Puppy> Message-ID: <20050918191059.C48484@zircon.juniper.net> References: <0c2201c5aa65$e0b4c7d0$c5919ed9@Puppy> <20050914174809.A77537@zircon.juniper.net> <0be701c5bc9c$e0651c50$28849ed9@Puppy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Hi Adrian, It is unfortunate that this conflict occured and it took so long to find this out. Thanks for noticing it, when you did. On the bright side, atleast we can still fix this. I am okay with changing the bits in the inter-domain and stitching IDs. JP, is this fine with you ? I will send out a mail pointing out this change once the next version has been posted, so that if someone thinks this change is significant and it affects them, then hopefully they will bring it up. thanks, -arthi > I'm sorry that there is a conflict for these bits. Way back in the distant > past a predecessor of your I-D had the Contiguous bit at 0x02 and the > Stitching bit at 0x03 while it also had a Crankback bit at 0x01. There was > an obvious conflict even then with the Crankback I-D and I started the > registry to try to resolve this and sent mail to the MPLS and CCAMP lists. > > Obviously I didn't draw it to your attention well enough. > > I don't think that you can claim to predate the crankback work which was > already at revision 6 in June 2003. But that probably isn't important. > > We have a conflict we need to resolve. > > Since the Crankback I-D completed WG last call in April this year and was > passed to the ADs in May, I think it "wins". > > Cheers, > Adrian > > ----- Original Message ----- > From: "Arthi Ayyangar" > To: "Adrian Farrel" > Cc: "'Jean Philippe Vasseur'" ; > Sent: Thursday, September 15, 2005 1:56 AM > Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt > > >> Hi Adrian, >> >> Sorry for the delay (as usual) and thanks for your comments (as usual). >> I have incorporated your comments and suggestions for the next rev. Just >> one major point of contention. See below. >> >>> Section 4.1 (also section 9.1) >>> 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end >>> node that originates the inter-domain TE LSP if it desires a >>> contiguous end-to-end TE LSP (in the control & data plane). When > set, >>> this indicates that a boundary node MUST not perform any stitching > or >>> nesting on the TE LSP and the TE LSP MUST be routed as any other TE >>> LSP (it must be contiguous end to end). When this bit is cleared, a >>> boundary node may decide to perform stitching or nesting. A > mid-point >>> node not supporting contiguous TE LSP MUST send a Path Error message >>> >>> a. s/MUST not/MUST NOT/ >>> b. I have allocated bit number 4 (0x08) in the temporary registry of >>> LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp-attrib.txt > as >>> a place holder until the IANA takes over this work. (I think we've >>> discussed this before - the point of the temporary registry is to > save >> ---------> This has been 0x01 for Contiguous LSP desired and 0x02 for >> Stitching desired since the beginning of any of these drafts, through > the >> merger and split. And I remember that the LSP Attributes registry used > to >> carry the matching numbers before. But looks like other drafts have >> appeared and now the numbers for the inter-domain IDs in the registry no >> longer match the ones in the IDs. >> >> Just one point that these inter-domain IDs predate most of the other IDs >> actually (in fact we went the LSP ATTRIBUTES path because we ran out of >> bits for the inter-domain IDs), so I am not sure what you propose we do >> at this point. >> >> thanks, >> -arthi > From owner-ccamp@ops.ietf.org Mon Sep 19 14:42:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQbE-0005nN-R2 for ccamp-archive@megatron.ietf.org; Mon, 19 Sep 2005 14:42:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13638 for ; Mon, 19 Sep 2005 14:42:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHQgs-0000ZS-Ga for ccamp-archive@ietf.org; Mon, 19 Sep 2005 14:48:37 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHQSA-000MMZ-Pn for ccamp-data@psg.com; Mon, 19 Sep 2005 18:33:22 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHQS8-000MM9-D7 for ccamp@ops.ietf.org; Mon, 19 Sep 2005 18:33:20 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Sep 2005 14:33:20 -0400 X-IronPort-AV: i="3.97,123,1125892800"; d="scan'208"; a="70871523:sNHT33995136" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8JIWdTg002933; Mon, 19 Sep 2005 14:33:17 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 14:33:12 -0400 Received: from [161.44.70.134] ([161.44.70.134]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Sep 2005 14:33:12 -0400 In-Reply-To: <20050918191059.C48484@zircon.juniper.net> References: <0c2201c5aa65$e0b4c7d0$c5919ed9@Puppy> <20050914174809.A77537@zircon.juniper.net> <0be701c5bc9c$e0651c50$28849ed9@Puppy> <20050918191059.C48484@zircon.juniper.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D765E63-D385-4308-8D8C-B0B975F372CA@cisco.com> Cc: Adrian Farrel , ccamp@ops.ietf.org Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt Date: Mon, 19 Sep 2005 14:33:38 -0400 To: Arthi Ayyangar X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 19 Sep 2005 18:33:12.0163 (UTC) FILETIME=[972E8330:01C5BD48] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Hi Arthi, On Sep 18, 2005, at 10:20 PM, Arthi Ayyangar wrote: > Hi Adrian, > > It is unfortunate that this conflict occured and it took so long to > find this out. Thanks for noticing it, when you did. On the bright > side, atleast we can still fix this. I am okay with changing the > bits in the inter-domain and stitching IDs. JP, is this fine with > you ? > Yes, > I will send out a mail pointing out this change once the next > version has been posted, so that if someone thinks this change is > significant and it affects them, then hopefully they will bring it up. > Thanks. JP. > thanks, > -arthi > > >> I'm sorry that there is a conflict for these bits. Way back in the >> distant >> past a predecessor of your I-D had the Contiguous bit at 0x02 and the >> Stitching bit at 0x03 while it also had a Crankback bit at 0x01. >> There was >> an obvious conflict even then with the Crankback I-D and I started >> the >> registry to try to resolve this and sent mail to the MPLS and >> CCAMP lists. >> >> Obviously I didn't draw it to your attention well enough. >> >> I don't think that you can claim to predate the crankback work >> which was >> already at revision 6 in June 2003. But that probably isn't >> important. >> >> We have a conflict we need to resolve. >> >> Since the Crankback I-D completed WG last call in April this year >> and was >> passed to the ADs in May, I think it "wins". >> >> Cheers, >> Adrian >> >> ----- Original Message ----- >> From: "Arthi Ayyangar" >> To: "Adrian Farrel" >> Cc: "'Jean Philippe Vasseur'" ; >> >> Sent: Thursday, September 15, 2005 1:56 AM >> Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt >> >> >> >>> Hi Adrian, >>> >>> Sorry for the delay (as usual) and thanks for your comments (as >>> usual). >>> I have incorporated your comments and suggestions for the next >>> rev. Just >>> one major point of contention. See below. >>> >>> >>>> Section 4.1 (also section 9.1) >>>> 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end >>>> node that originates the inter-domain TE LSP if it desires a >>>> contiguous end-to-end TE LSP (in the control & data plane). When >>>> >> set, >> >>>> this indicates that a boundary node MUST not perform any >>>> stitching >>>> >> or >> >>>> nesting on the TE LSP and the TE LSP MUST be routed as any >>>> other TE >>>> LSP (it must be contiguous end to end). When this bit is >>>> cleared, a >>>> boundary node may decide to perform stitching or nesting. A >>>> >> mid-point >> >>>> node not supporting contiguous TE LSP MUST send a Path Error >>>> message >>>> >>>> a. s/MUST not/MUST NOT/ >>>> b. I have allocated bit number 4 (0x08) in the temporary >>>> registry of >>>> LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp- >>>> attrib.txt >>>> >> as >> >>>> a place holder until the IANA takes over this work. (I think we've >>>> discussed this before - the point of the temporary registry is to >>>> >> save >> >>> ---------> This has been 0x01 for Contiguous LSP desired and 0x02 >>> for >>> Stitching desired since the beginning of any of these drafts, >>> through >>> >> the >> >>> merger and split. And I remember that the LSP Attributes registry >>> used >>> >> to >> >>> carry the matching numbers before. But looks like other drafts have >>> appeared and now the numbers for the inter-domain IDs in the >>> registry no >>> longer match the ones in the IDs. >>> >>> Just one point that these inter-domain IDs predate most of the >>> other IDs >>> actually (in fact we went the LSP ATTRIBUTES path because we ran >>> out of >>> bits for the inter-domain IDs), so I am not sure what you propose >>> we do >>> at this point. >>> >>> thanks, >>> -arthi >>> >> > From owner-ccamp@ops.ietf.org Mon Sep 19 14:53:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQlO-0000FA-Mv for ccamp-archive@megatron.ietf.org; Mon, 19 Sep 2005 14:53:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14093 for ; Mon, 19 Sep 2005 14:53:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHQr3-0000pQ-HH for ccamp-archive@ietf.org; Mon, 19 Sep 2005 14:59:06 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHQdw-000NSz-Vy for ccamp-data@psg.com; Mon, 19 Sep 2005 18:45:32 +0000 Received: from [143.209.238.6] (helo=auds953.usa.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHQdt-000NRc-1n; Mon, 19 Sep 2005 18:45:29 +0000 Received: from usdaln07161 (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id j8JIjKqK021092; Mon, 19 Sep 2005 13:45:21 -0500 (CDT) Message-Id: <200509191845.j8JIjKqK021092@auds953.usa.alcatel.com> From: "Jim Jones" To: "'Adrian Farrel'" Cc: , "'Kireeti Kompella'" , , "'Bill Fenner'" Subject: RE: Response to your questions about GMPLS parameters Date: Mon, 19 Sep 2005 13:45:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <0c0c01c5bca3$82c18960$28849ed9@Puppy> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-index: AcW8oyQGzTZVDYHRQmSm2ZTpUPRFfQApgrzA X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Content-Transfer-Encoding: 7bit Dear Adrian, Thanks for the detailed reply. I am posting this on the OIF contribution site for discussion during our 4Q Technical Committee meetings next month. I expect we will cover the topic of Ethernet requirements as well as the details regarding GMPLS parameters. Again, we appreciate the efforts of the IETF CCAMP in preparing this reply and look forward to continued cooperation. Best Regards, Jim -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Sunday, September 18, 2005 5:51 PM To: Jim Jones Cc: ccamp@ops.ietf.org; 'Kireeti Kompella'; zinin@psg.com; Bill Fenner Subject: Response to your questions about GMPLS parameters To: Jim Jones, OIF Technical Committee Chair From: Adrian Farrel and Kireeti Kompella, WG Co-Chairs for IETF CCAMP Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors Subject: Response to your questions about GMPLS parameters. Dear Jim, Thanks for your correspondence about the questions with respect to GMPLS parameters that arose before and during your interoperability testing. CCAMP is pleased to receive such questions and is glad to have the opportunity to explain the intended operation of the GMPLS protocols. Much of the material supplied below can be simply extracted from the relevant RFCs. > 1. Use of the NCC and RCC fields for STS-3c/VC-4 connections > > During OIF testing it was noted that some ambiguity exists in the > specification of encoding of NCC, RCC and NVC for certain types of > connections: NCC and RCC for an STS-3c/VC-4 connection can be set to 0 > or to 1 depending on which example of RFC 3946 is followed. > > Clarification is requested from IETF CCAMP as to which setting is > considered correct, or if both settings should be accepted (this > procedure was used during testing at Supercomm). This question about RFC 3946 was raised informally on the CCAMP mailing list at the start of March this year. The intention of the editors of RFC 3946 was that a VC-4 elementary signal would be represented using RCC=0 and NCC=0, while an STS-3c SPE elementary signal would have RCC=1 and NCC=1. This follows the examples in the annex. Your question probably arises from the two notes and subsequent paragraph in section 2.1 or RFC 3946. The text here is compatible with the annex, but culminates with... "A RCC value different from 0 must imply a number of contiguous components greater than 1." The editors intended this to mean "greater than or equal to 1." As a result of your question there has been some heated debate within CCAMP driven by the fact that some people have implemented according to the word of the RFC while others have implemented according to the intention of the editors (using the examples in the annex to drive their work). We plan to issue a revision to RFC 3946 which will include the following compromise position. a. "greater than" will be changed to "greater than or equal to" b. A third note will be added to section 2.1 to clarify the expected behavior as follows... Note 3: Following these rules, when requesting a VC-4 signal, the RCC and the NCC values are set to 0, whereas for an STS-3c SPE signal, the RCC and the NCC values are set to 1. However, since the signals are indistinguishable in the data plane, the requesting upstream node MAY set the RCC and NCC values to either both 0 or both 1 without impacting the function. The downstream node MUST accept both possible settings of RCC and NCC and handle them interchangeably. The upstream node SHOULD be consistent in its choice of RCC and NCC value settings for all LSPs requested on any one interface. This solution is still subject to agreement from the CCAMP community, but appears to reflect a position which facilitates maximum interworking. > 2. Setting of NVC for VCAT connections > > It was also noted that the setting of NVC may be somewhat ambiguous > for the case where diverse connections are used within a single VCAT group. > Each individual RSVP session controls a single connection, but the > connection is part of a larger VCAT group and carries VCAT encoding of > the H4 byte. Clarification is requested from IETF CCAMP and ITU-T Q.14/15 > as to the correct setting of NVC for this case (0 or 1?). It should be > noted that this case may occur with a VCAT group with only a single initial > member, and that the NVC may provide an indication that VCAT encoding > of the H4 byte is in use for the connection. A VCn-Xv group split into X components requires each of its component to be signaled with the NVC value set to 1. This setting is regardless of how the components are established. > 3. Length of the Interface Switching Capability TLV > > Although the Interface Switching Capability TLV defined by CCAMP for > SONET/SDH connections was not used for the testing, it was noted that > the text describing the length of the Interface Switching Capability > TLV defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be > slightly ambiguous due to the use of padding bytes. > > RFC 3630 states that "The TLV is padded to four-octet alignment; > padding is not included in the length field (so a three octet value > would have a length of three, but the total size of the TLV would be eight octets)." Yes. Section 2.3.2 of RFC3630 gives a definitive statement of the meaning of the length field and the use of padding, and provides an example. > Reading of the encoding in > draft-ietf-ccamp-ospf-gmpls-extensions-12.txt > specifies that the length of the TLV for TDM is 41 bytes plus 3 bytes > of padding, and should be given in the length field as 41 bytes rather > than 44. OIF requests verification of this interpretation from the > experts in IETF CCAMP group. Note that the Interface Switching Capability Descriptor defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link TLV. Sub-TLVs and TLVs follow the same encoding rules. The ISCD TLV for TDM contains the following fields... type 2 bytes length 2 bytes --- switch cap 1 byte encoding 1 byte reserve 2 bytes LSP b/w 0 4 bytes LSP b/w 1 4 bytes LSP b/w 2 4 bytes LSP b/w 3 4 bytes LSP b/w 4 4 bytes LSP b/w 5 4 bytes LSP b/w 6 4 bytes LSP b/w 7 4 bytes min b/w 4 bytes indication 1 byte == 41 bytes We presume that your question relates to whether the 3-byte field shown as "padding" in the TDM-specific figure on page 6 of draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an explicit field. It is an implicit field, and should not be included in the length of the TLV. Nevertheless, we take this opportunity to remind the OIF that implementations of GMPLS protocols should be conservative in what they send and liberal in what they receive. Thus, an implementation that receives a TDM ISCD TLV with length 44 should not reject the TLV for this reason. It should parse the TLV according to the defined fields and skip the final three bytes. Thus, it should not affect a receiving implementation if the sending implementation has treated the "padding" field as implicit or explicit. In the event that a receiving implementation rejected such a TLV on grounds of the value contained in the length field being too large, the fault would lie with the receiving implementation not the sending implementation. > 4. Use of ADMIN_STATUS in an initial PATH message > > Some implementations sent an ADMIN_STATUS object with no flags set in > the initial PATH message, i.e., when no status change was being requested. > Although this did not serve any particular function, it was believed > that this could be accepted as RFC3473, sect. 7.2 (page 18) states: > > "The absence of the object is equivalent to receiving an object > containing values all set to zero (0)." > > It was our interpretation based on this text that a node should accept > an ADMIN_STATUS object with no flags set in the same way as if the > object was missing. Comment on this interpretation is welcome. The effect of the meaning is as you state, but the intention of the meaning is reversed. That is, an implementation should accept the absence of the ADMIN_STATUS object in the same way as if the object was present with no flags set. That is, the default behavior is to consider the ADMIN_STATUS object as a standard part of the processing. We note from your first paragraph that you assume that the ADMIN_STATUS object is used to change the status of the LSP. This is a misinterpretation - it is used to control the status of the LSP. Thus, if there is no change to the status of an LSP, refresh messages must continue to carry the ADMIN_STATUS object with the same bit setting. In this way, it is not possible to "drop" the ADMIN_STATUS object without having the same meaning as transmitting the object with all bits cleared. > 5. Handling of multiple received ResvConf Request objects > > When a connection desires a confirmation that the service (i.e. > connection) requested is in place, a RESV_CONF_REQ object is included > in the RESV message. As this object is received by the remote end of > the reservation, it will send a RESV_CONF message back to the requester. > > However, it is unclear whether it is necessary to send a RESV_CONF > message when the RSVP connection state is refreshed by subsequent > RESV. This becomes potentially burdensome, especially when the > reservation is being rapidly refreshed. Therefore we ask: should the > remote end send a RESV_CONF message for subsequent RESV messages that > still include the RESV_CONF_REQ object? Or is it required that the > requestor of the reservation remove the RESV_CONF_REQ object to > prevent the generation of further RESV_CONF messages? Comment on this > issue from IETF CCAMP is requested. It is fundamental to the implementation of RSVP-TE that there is a good understanding of the distinction between a trigger message and a refresh message. This can be achieved by reading section 1.1 of RFC2961. Following this understanding, you will note that a refresh message does not cause any processing to be performed at the LSR that receives it (in this case the ingress). You will also note that refresh processing is not end-to-end as implied in your text, but is hop-by-hop. Thus, a downstream LSR that wishes to trigger a new ResvConf message must make a specific change to the content of the Resv message that it sends in order to cause a trigger message to be propagated through the network to the ingress LSR. Such processing is implementation specific but might include the toggling of the presence of the RESV_CONFIRM object on the Resv message. Note that a ResvConf message is not necessarily reliably delivered end-to-end. Relying on the receipt of a ResvConf message before doing something (e.g. turning on the laser) might be a poor idea. GMPLS uses the Administrative Status object and in particular the R-bit in order to reliably achieve this function. > 6. Symmetry of Refresh Reduction usage > > During interop testing, we ran into a conflict caused by varying > interpretations of RFC2961, regarding the use of SRefresh messages and > the Refresh Reduction capabilities of the two ends of a given link. > One interpretation of RFC2961 indicates that setting the Refresh > Reduction Capability flag in the RSVP header indicates that that > interface shall be capable of receiving messages related to Refresh > Reduction - including the SRefresh message. This would be true even if > the other end of the link for that interface were NOT indicating > Refresh Reduction Capability, since the RFC makes no statement about > symmetry in this matter. > > Another interpretation is that both ends of an interface must indicate > Refresh Reduction Capability before either end can use such messages, > i.e, use of Refresh Reduction on a link is symmetric. > > Comment from CCAMP WG on the correct interpretation is requested. We are confused by your question. You correctly state that the use of the refresh-reduction-capable bit indicates the ability of an LSR to support the receipt of refresh reduction options and messages. To quote from section 2 of RFC2961... When set, indicates that this node is willing and capable of receiving all the messages and objects described in this document. This includes the Bundle message described in Section 3, the MESSAGE_ID objects and Ack messages described in Section 4, and the MESSAGE_ID LIST objects and Srefresh message described in Section 5. This bit is meaningful only between RSVP neighbors. This makes no statement about whether the LSR intends to use these options when communicating with another LSR. However, you will note that some refresh reduction procedures require that a message is sent and response returned. In order to make use of the response, the receiver must be capable of receiving and processing the response. Thus, it would be usual for an LSR that is capable of sending refresh reduction options and messages to also set the refresh-reduction-capable bit. In summary: - An LSR must not send refresh reduction options or messages to an LSR that is not setting the refresh-reduction-capable bit. - An LSR may send refresh reduction options or messages to an LSR that is setting the refresh-reduction-capable bit. - An LSR that wishes to successfully use responded refresh reduction options or messages should set the refresh- reduction-capable bit. Note, finally, that section 2 of RFC 2961 states that "When it is not known if a next hop supports the extension, standard Path and Resv message based refreshes MUST be used." > 7. Sending of ACKs bundled with the RSVP HELLO > > During interop testing, it was observed that Message Acks were > piggybacked onto RSVP Hello messages, when the receiving end was not > using the Hello protocol. In this situation, the incoming Hello's were > discarded and the Acks were lost. > > We believe that Message Acks should only be piggybacked onto mandatory > messages, and not on Hello messages because of this problem. Comment > on this interpretation is requested. You use of the terms "bundled" and "piggybacked" are contradictory. "Bundled" implies the use of the Bundle message. RFC 2961 states... A sub-message MAY be any message type except for another Bundle message. Thus, Ack messages may be bundled with other messages. (Although one might consider this perverse since the Ack message is only introduced to handle the case when the Ac/Nack objects have no other message on which they can be carried.) Further, RFC 3209 states... A Hello message may be included as a sub-message within a bundle message. Therefore, it acceptable for a Ack and Hello messages to be bundled together. The processing rules (RFC 29610 for Bundled messages are such that each sub-message is processed in its own right, and the non-support/non-use of Hello messages should not impact the processing of other messages. On the other hand, "piggybacked" implies the use of the Ack/Nack objects within a Hello message. Section 4.1 of RFC2961 states that Ack/Nack objects may be included in the "standard" RSVP messages, and shows where they are placed. However, RFC 3209 defines the Hello message as not including the Ack/Nack objects... ::= [ ] Since RFC 3209 post-dates RFC 2961, this definition is definitive and the Ack/Nack objects should not be present on the Hello message. Give that section 5.3 of RFC 3209 states... The Hello Message is completely OPTIONAL. All messages may be ignored by nodes which do not wish to participate in Hello message processing. ...it is not particularly important what the message format rules are. An implementation that chooses to place an Ack/Nack object in a Hello message knows that the object might be discarded unprocessed. > 8. TSPEC format to be used for Ethernet connections The CCAMP working group has discussed the use of GMPLS for control of Ethernet devices, and this has led to the publication of a new Internet-Draft entitled "Use of the Generalized Multi-Protocol Label Switching control plane for point-to-point Ethernet Label Switching" which you can find at http://www.ietf.org/internet-drafts/draft-andersson-gels-bof-prep-00.txt. The Abstract of this draft reads as follows: This document proposes starting a work within the IETF to apply the Generalized Multi-Protocol Label Switching (GMPLS) control plane to Ethernet Label Switching and to make extensions to the GMPLS control plane protocols as necessary for this application. This will be done based on the protocols developed by the MPLS and CCAMP working groups in the IETF. Ethernet Label Switching will use the data plane encodings as specified by the IEEE 802 standards. This document intends to gather the information necessary to have a "GMPLS Ethernet Label Switching" BoF in Vancouver. We are certain that the IETF will want to ensure that the OIF's requirements for Ethernet are adequately covered by GMPLS and would urge the OIF to document its requirements and to send them to the IETF for inclusion. In this instance you may send such requirements to us and we will ensure that they are passed on to the correct group that undertakes this work. Best regards, Adrian Farrel Kireeti Kompella From owner-ccamp@ops.ietf.org Tue Sep 20 04:48:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHdnT-00065e-7H for ccamp-archive@megatron.ietf.org; Tue, 20 Sep 2005 04:48:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16381 for ; Tue, 20 Sep 2005 04:48:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHdtC-0005ws-5I for ccamp-archive@ietf.org; Tue, 20 Sep 2005 04:54:11 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHdfb-0006Jr-IL for ccamp-data@psg.com; Tue, 20 Sep 2005 08:40:07 +0000 Received: from [80.86.78.228] (helo=smtp.testbed.se) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHdfX-0006Id-6Q for ccamp@ops.ietf.org; Tue, 20 Sep 2005 08:40:03 +0000 Received: from [81.183.251.5] (helo=[172.28.43.120]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1EHdf5-0006Da-TA; Tue, 20 Sep 2005 10:39:40 +0200 Message-ID: <432FCA7B.5090704@pi.se> Date: Tue, 20 Sep 2005 10:38:19 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gels@rtg.ietf.org, mpls@ietf.org, ccamp@ops.ietf.org, pwe3 , l1vpn@ietf.org, L2VPN , "Developing a hybrid router/bridge." , rtgwg@ietf.org, rtg-dir@ietf.org Subject: GMPLS Ethernet in Vancouver Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit All, following the discussion in the CCAMP working group on the L2SC design team report, the discussion continued off-line and the idea to hold a GMPLS Ethernet BoF in Vancouver was born. We have collected bits and pieces of the discussion so far and tried to come up with a way to proceed. We have put together a more focused proposal for GMPLS controled Ethernet Label Switching and have requested that a BoF will be held in Vancouver. This request has been approved by the Routing Area directors. A draft draft-andersson-gels-bof-prep-00.txt has been published to serve as a starting point for the discussion at the BoF. The intention has been to reflect the GMPLS Ethernet discussion so far, without any claim to be complete or "objective", but to specify limited and focused work that can serve starting as a point for GMPLS controlled Ethernet Label Switching. A mailing list has been set up to host the discussion before the BoF to subscribe to the mailing list send mail to gels-request@rtg.ietf.org (subsribe) in body or subject or visit https://rtg.ietf.org/mailman/listinfo/gels Looking forward to comments and discussion. /Loa and Dimitri -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From owner-ccamp@ops.ietf.org Tue Sep 20 22:44:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHubB-0007wF-2Y for ccamp-archive@megatron.ietf.org; Tue, 20 Sep 2005 22:44:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21818 for ; Tue, 20 Sep 2005 22:44:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHuh1-0002TI-Ic for ccamp-archive@ietf.org; Tue, 20 Sep 2005 22:50:50 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHuSY-00069u-K7 for ccamp-data@psg.com; Wed, 21 Sep 2005 02:35:46 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHuSW-00069b-EX for ccamp@ops.ietf.org; Wed, 21 Sep 2005 02:35:44 +0000 Received: from du-069-0194.access.clara.net ([217.158.132.194] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EH7Df-0004wZ-Ew; Sun, 18 Sep 2005 23:01:09 +0100 Message-ID: <0be701c5bc9c$e0651c50$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Arthi Ayyangar" Cc: "'Jean Philippe Vasseur'" , References: <0c2201c5aa65$e0b4c7d0$c5919ed9@Puppy> <20050914174809.A77537@zircon.juniper.net> Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt Date: Sun, 18 Sep 2005 23:02:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Hi Arthi, I'm sorry that there is a conflict for these bits. Way back in the distant past a predecessor of your I-D had the Contiguous bit at 0x02 and the Stitching bit at 0x03 while it also had a Crankback bit at 0x01. There was an obvious conflict even then with the Crankback I-D and I started the registry to try to resolve this and sent mail to the MPLS and CCAMP lists. Obviously I didn't draw it to your attention well enough. I don't think that you can claim to predate the crankback work which was already at revision 6 in June 2003. But that probably isn't important. We have a conflict we need to resolve. Since the Crankback I-D completed WG last call in April this year and was passed to the ADs in May, I think it "wins". Cheers, Adrian ----- Original Message ----- From: "Arthi Ayyangar" To: "Adrian Farrel" Cc: "'Jean Philippe Vasseur'" ; Sent: Thursday, September 15, 2005 1:56 AM Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt > Hi Adrian, > > Sorry for the delay (as usual) and thanks for your comments (as usual). > I have incorporated your comments and suggestions for the next rev. Just > one major point of contention. See below. > > > Section 4.1 (also section 9.1) > > 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end > > node that originates the inter-domain TE LSP if it desires a > > contiguous end-to-end TE LSP (in the control & data plane). When set, > > this indicates that a boundary node MUST not perform any stitching or > > nesting on the TE LSP and the TE LSP MUST be routed as any other TE > > LSP (it must be contiguous end to end). When this bit is cleared, a > > boundary node may decide to perform stitching or nesting. A mid-point > > node not supporting contiguous TE LSP MUST send a Path Error message > > > > a. s/MUST not/MUST NOT/ > > b. I have allocated bit number 4 (0x08) in the temporary registry of > > LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp-attrib.txt as > > a place holder until the IANA takes over this work. (I think we've > > discussed this before - the point of the temporary registry is to save > ---------> This has been 0x01 for Contiguous LSP desired and 0x02 for > Stitching desired since the beginning of any of these drafts, through the > merger and split. And I remember that the LSP Attributes registry used to > carry the matching numbers before. But looks like other drafts have > appeared and now the numbers for the inter-domain IDs in the registry no > longer match the ones in the IDs. > > Just one point that these inter-domain IDs predate most of the other IDs > actually (in fact we went the LSP ATTRIBUTES path because we ran out of > bits for the inter-domain IDs), so I am not sure what you propose we do > at this point. > > thanks, > -arthi From owner-ccamp@ops.ietf.org Tue Sep 20 22:45:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHubY-00087y-3v for ccamp-archive@megatron.ietf.org; Tue, 20 Sep 2005 22:45:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21830 for ; Tue, 20 Sep 2005 22:45:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHuhU-0002Tq-0o for ccamp-archive@ietf.org; Tue, 20 Sep 2005 22:51:13 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHuUx-0006Ls-Px for ccamp-data@psg.com; Wed, 21 Sep 2005 02:38:15 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHuUv-0006LQ-SE for ccamp@ops.ietf.org; Wed, 21 Sep 2005 02:38:14 +0000 Received: from du-069-0194.access.clara.net ([217.158.132.194] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EH7xd-000D0R-FC; Sun, 18 Sep 2005 23:48:45 +0100 Message-ID: <0c0c01c5bca3$82c18960$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Jim Jones" Cc: , "'Kireeti Kompella'" , , "Bill Fenner" Subject: Response to your questions about GMPLS parameters Date: Sun, 18 Sep 2005 23:51:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 17cf8eab1d6bbd2874a56f9e3554d91d Content-Transfer-Encoding: 7bit To: Jim Jones, OIF Technical Committee Chair From: Adrian Farrel and Kireeti Kompella, WG Co-Chairs for IETF CCAMP Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors Subject: Response to your questions about GMPLS parameters. Dear Jim, Thanks for your correspondence about the questions with respect to GMPLS parameters that arose before and during your interoperability testing. CCAMP is pleased to receive such questions and is glad to have the opportunity to explain the intended operation of the GMPLS protocols. Much of the material supplied below can be simply extracted from the relevant RFCs. > 1. Use of the NCC and RCC fields for STS-3c/VC-4 connections > > During OIF testing it was noted that some ambiguity exists in the > specification of encoding of NCC, RCC and NVC for certain types of > connections: NCC and RCC for an STS-3c/VC-4 connection can be set to 0 > or to 1 depending on which example of RFC 3946 is followed. > > Clarification is requested from IETF CCAMP as to which setting is > considered correct, or if both settings should be accepted (this > procedure was used during testing at Supercomm). This question about RFC 3946 was raised informally on the CCAMP mailing list at the start of March this year. The intention of the editors of RFC 3946 was that a VC-4 elementary signal would be represented using RCC=0 and NCC=0, while an STS-3c SPE elementary signal would have RCC=1 and NCC=1. This follows the examples in the annex. Your question probably arises from the two notes and subsequent paragraph in section 2.1 or RFC 3946. The text here is compatible with the annex, but culminates with... "A RCC value different from 0 must imply a number of contiguous components greater than 1." The editors intended this to mean "greater than or equal to 1." As a result of your question there has been some heated debate within CCAMP driven by the fact that some people have implemented according to the word of the RFC while others have implemented according to the intention of the editors (using the examples in the annex to drive their work). We plan to issue a revision to RFC 3946 which will include the following compromise position. a. "greater than" will be changed to "greater than or equal to" b. A third note will be added to section 2.1 to clarify the expected behavior as follows... Note 3: Following these rules, when requesting a VC-4 signal, the RCC and the NCC values are set to 0, whereas for an STS-3c SPE signal, the RCC and the NCC values are set to 1. However, since the signals are indistinguishable in the data plane, the requesting upstream node MAY set the RCC and NCC values to either both 0 or both 1 without impacting the function. The downstream node MUST accept both possible settings of RCC and NCC and handle them interchangeably. The upstream node SHOULD be consistent in its choice of RCC and NCC value settings for all LSPs requested on any one interface. This solution is still subject to agreement from the CCAMP community, but appears to reflect a position which facilitates maximum interworking. > 2. Setting of NVC for VCAT connections > > It was also noted that the setting of NVC may be somewhat ambiguous for > the case where diverse connections are used within a single VCAT group. > Each individual RSVP session controls a single connection, but the > connection is part of a larger VCAT group and carries VCAT encoding of > the H4 byte. Clarification is requested from IETF CCAMP and ITU-T Q.14/15 > as to the correct setting of NVC for this case (0 or 1?). It should be > noted that this case may occur with a VCAT group with only a single initial > member, and that the NVC may provide an indication that VCAT encoding of > the H4 byte is in use for the connection. A VCn-Xv group split into X components requires each of its component to be signaled with the NVC value set to 1. This setting is regardless of how the components are established. > 3. Length of the Interface Switching Capability TLV > > Although the Interface Switching Capability TLV defined by CCAMP for > SONET/SDH connections was not used for the testing, it was noted that > the text describing the length of the Interface Switching Capability TLV > defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly > ambiguous due to the use of padding bytes. > > RFC 3630 states that "The TLV is padded to four-octet alignment; padding > is not included in the length field (so a three octet value would have a > length of three, but the total size of the TLV would be eight octets)." Yes. Section 2.3.2 of RFC3630 gives a definitive statement of the meaning of the length field and the use of padding, and provides an example. > Reading of the encoding in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt > specifies that the length of the TLV for TDM is 41 bytes plus 3 bytes of > padding, and should be given in the length field as 41 bytes rather than > 44. OIF requests verification of this interpretation from the experts in > IETF CCAMP group. Note that the Interface Switching Capability Descriptor defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link TLV. Sub-TLVs and TLVs follow the same encoding rules. The ISCD TLV for TDM contains the following fields... type 2 bytes length 2 bytes --- switch cap 1 byte encoding 1 byte reserve 2 bytes LSP b/w 0 4 bytes LSP b/w 1 4 bytes LSP b/w 2 4 bytes LSP b/w 3 4 bytes LSP b/w 4 4 bytes LSP b/w 5 4 bytes LSP b/w 6 4 bytes LSP b/w 7 4 bytes min b/w 4 bytes indication 1 byte == 41 bytes We presume that your question relates to whether the 3-byte field shown as "padding" in the TDM-specific figure on page 6 of draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an explicit field. It is an implicit field, and should not be included in the length of the TLV. Nevertheless, we take this opportunity to remind the OIF that implementations of GMPLS protocols should be conservative in what they send and liberal in what they receive. Thus, an implementation that receives a TDM ISCD TLV with length 44 should not reject the TLV for this reason. It should parse the TLV according to the defined fields and skip the final three bytes. Thus, it should not affect a receiving implementation if the sending implementation has treated the "padding" field as implicit or explicit. In the event that a receiving implementation rejected such a TLV on grounds of the value contained in the length field being too large, the fault would lie with the receiving implementation not the sending implementation. > 4. Use of ADMIN_STATUS in an initial PATH message > > Some implementations sent an ADMIN_STATUS object with no flags set in > the initial PATH message, i.e., when no status change was being requested. > Although this did not serve any particular function, it was believed > that this could be accepted as RFC3473, sect. 7.2 (page 18) states: > > "The absence of the object is equivalent to receiving an object > containing values all set to zero (0)." > > It was our interpretation based on this text that a node should accept > an ADMIN_STATUS object with no flags set in the same way as if > the object was missing. Comment on this interpretation is welcome. The effect of the meaning is as you state, but the intention of the meaning is reversed. That is, an implementation should accept the absence of the ADMIN_STATUS object in the same way as if the object was present with no flags set. That is, the default behavior is to consider the ADMIN_STATUS object as a standard part of the processing. We note from your first paragraph that you assume that the ADMIN_STATUS object is used to change the status of the LSP. This is a misinterpretation - it is used to control the status of the LSP. Thus, if there is no change to the status of an LSP, refresh messages must continue to carry the ADMIN_STATUS object with the same bit setting. In this way, it is not possible to "drop" the ADMIN_STATUS object without having the same meaning as transmitting the object with all bits cleared. > 5. Handling of multiple received ResvConf Request objects > > When a connection desires a confirmation that the service (i.e. > connection) requested is in place, a RESV_CONF_REQ object is included in > the RESV message. As this object is received by the remote end of the > reservation, it will send a RESV_CONF message back to the requester. > > However, it is unclear whether it is necessary to send a RESV_CONF > message when the RSVP connection state is refreshed by subsequent > RESV. This becomes potentially burdensome, especially when the > reservation is being rapidly refreshed. Therefore we ask: should the > remote end send a RESV_CONF message for subsequent RESV > messages that still include the RESV_CONF_REQ object? Or is it > required that the requestor of the reservation remove the > RESV_CONF_REQ object to prevent the generation of further > RESV_CONF messages? Comment on this issue from IETF CCAMP > is requested. It is fundamental to the implementation of RSVP-TE that there is a good understanding of the distinction between a trigger message and a refresh message. This can be achieved by reading section 1.1 of RFC2961. Following this understanding, you will note that a refresh message does not cause any processing to be performed at the LSR that receives it (in this case the ingress). You will also note that refresh processing is not end-to-end as implied in your text, but is hop-by-hop. Thus, a downstream LSR that wishes to trigger a new ResvConf message must make a specific change to the content of the Resv message that it sends in order to cause a trigger message to be propagated through the network to the ingress LSR. Such processing is implementation specific but might include the toggling of the presence of the RESV_CONFIRM object on the Resv message. Note that a ResvConf message is not necessarily reliably delivered end-to-end. Relying on the receipt of a ResvConf message before doing something (e.g. turning on the laser) might be a poor idea. GMPLS uses the Administrative Status object and in particular the R-bit in order to reliably achieve this function. > 6. Symmetry of Refresh Reduction usage > > During interop testing, we ran into a conflict caused by varying > interpretations of RFC2961, regarding the use of SRefresh messages and > the Refresh Reduction capabilities of the two ends of a given link. One > interpretation of RFC2961 indicates that setting the Refresh Reduction > Capability flag in the RSVP header indicates that that interface shall > be capable of receiving messages related to Refresh Reduction - > including the SRefresh message. This would be true even if the other > end of the link for that interface were NOT indicating Refresh Reduction > Capability, since the RFC makes no statement about symmetry in this > matter. > > Another interpretation is that both ends of an interface must indicate > Refresh Reduction Capability before either end can use such messages, > i.e, use of Refresh Reduction on a link is symmetric. > > Comment from CCAMP WG on the correct interpretation is requested. We are confused by your question. You correctly state that the use of the refresh-reduction-capable bit indicates the ability of an LSR to support the receipt of refresh reduction options and messages. To quote from section 2 of RFC2961... When set, indicates that this node is willing and capable of receiving all the messages and objects described in this document. This includes the Bundle message described in Section 3, the MESSAGE_ID objects and Ack messages described in Section 4, and the MESSAGE_ID LIST objects and Srefresh message described in Section 5. This bit is meaningful only between RSVP neighbors. This makes no statement about whether the LSR intends to use these options when communicating with another LSR. However, you will note that some refresh reduction procedures require that a message is sent and response returned. In order to make use of the response, the receiver must be capable of receiving and processing the response. Thus, it would be usual for an LSR that is capable of sending refresh reduction options and messages to also set the refresh-reduction-capable bit. In summary: - An LSR must not send refresh reduction options or messages to an LSR that is not setting the refresh-reduction-capable bit. - An LSR may send refresh reduction options or messages to an LSR that is setting the refresh-reduction-capable bit. - An LSR that wishes to successfully use responded refresh reduction options or messages should set the refresh- reduction-capable bit. Note, finally, that section 2 of RFC 2961 states that "When it is not known if a next hop supports the extension, standard Path and Resv message based refreshes MUST be used." > 7. Sending of ACKs bundled with the RSVP HELLO > > During interop testing, it was observed that Message Acks were > piggybacked onto RSVP Hello messages, when the receiving end > was not using the Hello protocol. In this situation, the incoming > Hello's were discarded and the Acks were lost. > > We believe that Message Acks should only be piggybacked onto mandatory > messages, and not on Hello messages because of this problem. Comment on > this interpretation is requested. You use of the terms "bundled" and "piggybacked" are contradictory. "Bundled" implies the use of the Bundle message. RFC 2961 states... A sub-message MAY be any message type except for another Bundle message. Thus, Ack messages may be bundled with other messages. (Although one might consider this perverse since the Ack message is only introduced to handle the case when the Ac/Nack objects have no other message on which they can be carried.) Further, RFC 3209 states... A Hello message may be included as a sub-message within a bundle message. Therefore, it acceptable for a Ack and Hello messages to be bundled together. The processing rules (RFC 29610 for Bundled messages are such that each sub-message is processed in its own right, and the non-support/non-use of Hello messages should not impact the processing of other messages. On the other hand, "piggybacked" implies the use of the Ack/Nack objects within a Hello message. Section 4.1 of RFC2961 states that Ack/Nack objects may be included in the "standard" RSVP messages, and shows where they are placed. However, RFC 3209 defines the Hello message as not including the Ack/Nack objects... ::= [ ] Since RFC 3209 post-dates RFC 2961, this definition is definitive and the Ack/Nack objects should not be present on the Hello message. Give that section 5.3 of RFC 3209 states... The Hello Message is completely OPTIONAL. All messages may be ignored by nodes which do not wish to participate in Hello message processing. ...it is not particularly important what the message format rules are. An implementation that chooses to place an Ack/Nack object in a Hello message knows that the object might be discarded unprocessed. > 8. TSPEC format to be used for Ethernet connections The CCAMP working group has discussed the use of GMPLS for control of Ethernet devices, and this has led to the publication of a new Internet-Draft entitled "Use of the Generalized Multi-Protocol Label Switching control plane for point-to-point Ethernet Label Switching" which you can find at http://www.ietf.org/internet-drafts/draft-andersson-gels-bof-prep-00.txt. The Abstract of this draft reads as follows: This document proposes starting a work within the IETF to apply the Generalized Multi-Protocol Label Switching (GMPLS) control plane to Ethernet Label Switching and to make extensions to the GMPLS control plane protocols as necessary for this application. This will be done based on the protocols developed by the MPLS and CCAMP working groups in the IETF. Ethernet Label Switching will use the data plane encodings as specified by the IEEE 802 standards. This document intends to gather the information necessary to have a "GMPLS Ethernet Label Switching" BoF in Vancouver. We are certain that the IETF will want to ensure that the OIF's requirements for Ethernet are adequately covered by GMPLS and would urge the OIF to document its requirements and to send them to the IETF for inclusion. In this instance you may send such requirements to us and we will ensure that they are passed on to the correct group that undertakes this work. Best regards, Adrian Farrel Kireeti Kompella From owner-ccamp@ops.ietf.org Tue Sep 20 22:45:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHubp-0008F7-LQ for ccamp-archive@megatron.ietf.org; Tue, 20 Sep 2005 22:45:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21839 for ; Tue, 20 Sep 2005 22:45:19 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHuhl-0002UE-Dm for ccamp-archive@ietf.org; Tue, 20 Sep 2005 22:51:30 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EHuVg-0006QA-Dp for ccamp-data@psg.com; Wed, 21 Sep 2005 02:39:00 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EHuVW-0006Ov-0R for ccamp@ops.ietf.org; Wed, 21 Sep 2005 02:38:50 +0000 Received: from du-069-0194.access.clara.net ([217.158.132.194] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EH79a-000455-FW for ccamp@ops.ietf.org; Sun, 18 Sep 2005 22:56:55 +0100 Message-ID: <0bdb01c5bc9c$4010f3a0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Informal pre-IANA registries for MPLS and GMPLS Date: Sun, 18 Sep 2005 22:25:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Just to remind folks that I maintain two informal pre-IANA registries that folk may want to make use of. You can find them on the alternative CCAMP pages at http://www.olddog.co.uk/ccamp.htm LSP-ATTRIBUTES bits are for use in the LSP-ATTRIBUTES and LSP-REQUIRED-ATTRIBUTES objects as defined in draft-ietf-mpls-rsvpte-attributes-05.txt. Hopefully this will reach IANA through the RFC Editor process quite soon. The ADMIN-STATUS object is defined in RFC3473 with bits defined in RFC3471. Other bits are being defined here and there but there is currently no IANA registry. Several drafts in the RFC Editor queue and in AD review make a request to create the registry, so we will have one one day. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Sep 22 01:28:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIJd2-00073w-0t for ccamp-archive@megatron.ietf.org; Thu, 22 Sep 2005 01:28:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24062 for ; Thu, 22 Sep 2005 01:28:15 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIJj2-0005XP-Gd for ccamp-archive@ietf.org; Thu, 22 Sep 2005 01:34:39 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIJPF-0009aX-T4 for ccamp-data@psg.com; Thu, 22 Sep 2005 05:14:01 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIJPC-0009XS-V8 for ccamp@ops.ietf.org; Thu, 22 Sep 2005 05:13:59 +0000 Received: from du-069-0223.access.clara.net ([217.158.132.223] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1EGyxN-0005Qk-GJ; Sun, 18 Sep 2005 14:11:46 +0100 Message-ID: <04f201c5bc52$93d57ff0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Working group last call on draft-ietf-ccamp-gmpls-ason-routing-eval Date: Sun, 18 Sep 2005 14:10:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Hi, As requested by the AD, I asked the mailing list to let me know if there were any objections to last calling this I-D. I received none. Therefore this email starts a two eek last call on draft-ietf-ccamp-gmpls-ason-routing-eval. The last call will end on 2nd October at 12 noon GMT. The draft is targeted as Informational. Please send your comments to the mailing list. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Sep 22 19:46:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIald-0001l4-I0 for ccamp-archive@megatron.ietf.org; Thu, 22 Sep 2005 19:46:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13712 for ; Thu, 22 Sep 2005 19:46:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIars-0003Bw-MP for ccamp-archive@ietf.org; Thu, 22 Sep 2005 19:52:50 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIabv-00019c-08 for ccamp-data@psg.com; Thu, 22 Sep 2005 23:36:15 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIabs-00019N-T9 for ccamp@ops.ietf.org; Thu, 22 Sep 2005 23:36:13 +0000 Received: from du-069-0058.access.clara.net ([217.158.132.58] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EIQeY-000I5J-DM; Thu, 22 Sep 2005 13:58:23 +0100 Message-ID: <11aa01c5bf75$b2750720$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , References: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Thu, 22 Sep 2005 13:59:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 439b8e44c906b144bce6744ebb966e60 Content-Transfer-Encoding: 7bit Hi Joan, Last but not least, the GMPLS TE MIB module. > Here are some comments on draft-ietf-ccamp-gmpls-te-mib-09.txt. > All 3 docs show a good deal of work. Yes, but fortunatley most of the work appears to be editorial with only very minor changes to the basis of the module. Please find acks and nacks in line below. We will also include the comments made by David and Tom Petch. Cheers, Adrian > Section 1.1 Migration Strategy > ------------------------------ > > 1) Please remove "and OBJECT-IDENTIFIERS" > > Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] > and [GMPLSTCMIB]. Ack > Section 5.4 gmplsTunnelCHoptable > --------------------------------- > > 2) Please capitalize Table in the Section's title. Ack > Section 8. GMPLS Traffic Engineering MIB Module > ----------------------------------------------- > > smicngPRO gives the following: > > W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should have > SIZE specified Ack Understood this to be optional, but planning to add size as per David's comments > W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is > identical > W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is > identical > W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is > identical > W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax is > identical > W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", syntax > is identical Nack Meaningless warning message. Cannot fix without explanation. > Disconnect of numbering in the Conformance Section > \-3 gmplsTeConformance > \-v-1 gmplsTeGroups > | \-v-1 gmplsTunnelGroup > > 2 is missing Ack > 3) gmplsTunnelsConfigured OBJECT-TYPE > SYNTAX Unsigned32 > > SYNTAX should be Gauge32 Ack > 4) gmplsTunnelsActive OBJECT-TYPE > SYNTAX Unsigned32 > > SYNTAX should be Gauge32 Ack > 5) gmplsTunnelTable > > DESCRIPTION > > "The row status of an entry in this table is controlled by > mplsTunnelRowStatus in the corresponding entry in > mplsTunnelTable. That is, it is not permitted to create a row in > this table, nor to modify an existing row, when the > corresponding mplsTunnelRowStatus has value active(1).... > > The sentence beginning with "That is," is awkward. Could you say > something like: A row in this table is created when a row is created > in the mplsTunnelTable. Entries in this table cannot be modified > when the corresponding mplsTunnelRowStatus has a value of active(1). > The exception.... > > Please also update this other places in this MIB (e.g gmplsTunnelHopTable). Nack "A row in this table is created when a row is created in the mplsTunnelTable" is false. Will attempt to reword to make this clearer. > 6) gmplsTunnelEntry > DESCRIPTION: > "... > An entry can be created by a network administrator or by an SNMP > agent as instructed by a signaling protocol." > > Please change the above to: > > "An entry can be created by a network administrator via SNMP SET commands, or > by the network management entity as instructed by a signaling > protocol." Nack "network management entity" implies a remote entity such as an NMS. Will change to: "An entry can be created by a network administrator via SNMP SET commands, or in response to signaling protocol events." > 7) gmplsTunnelUnnumIf > > What IF-MIB object are referring to in the DESCRIPTION? > Could you state which object in the description? Ack An entry in ifTable. > 8) gmplsTunnelAttributes > Could you specify what happens when the bit is set (i.e. 1) > vs. 0? Ack Don't want to restate the protocol I-D, so this text will simply replace "This flag indicates that" with "This flag is set to indicate that" > 9) gmplsTunnelLSPEncoding > > The DESCRIPTION states: > ...A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling is > not in use. Some objects in this MIB module may be of use for > MPLS signaling extensions that do not use GMPLS signaling. By > setting this object to 'tunnelLspNotGmpls', an application may > indicate that only those objects meaningful in MPLS should be > examined.... > > I believe that such objects should be put in to an MPLS MIB module > and not included in this GMPLS MIB module. This is also true with > the gmplsTunnelErrorTable. Nack We strongly disagree with any implication that MPLS and GMPLS should be separated in this way. GMPLS protocol extensions are likely to be moved into MPLS implementations piecemeal and there is no clear separation that you imply. The G in GMPLS stands for "generalized". Can you please indicate whether this is a sticking point for you. > 10) gmplsTunnelLinkProtection > Same comment as with gmplsTunnelAttributes. Ack Same answer. > 11) gmplsTunnelPathComp > > DESCRIPTION states: > This object deprecates mplsTunnelHopEntryPathComp." > > The term "deprecates" is loaded. Perhaps something like, > this object takes precedence over mplsTunnelHopEntryPathComp. > In other words, for GMPLS tunnels, the value of > mplsTunnelHopEntryPathComp is meaningless. Ack > 12) gmplsTunnelUpNotRecip > > Need to use InetAddressType and InetAddress. IpAddress > is not used in MIBs anymore. Please be sure to support > both v4 and v6 IP address Types. If you can't support > v6 for some reason, that should be stated clearly. Ack per exchange with David. > Please change the name of this object to: > gmplsTunnelUpstreamRecipientForNotify Nack We are trying to keep to the (mythical?) 32 character limit. How about: gmplsTunnelUpNotifyRecipient > 13) gmplsTunnelDownNotRecip > Same comment as above wrt to IpAddress. Ack > Please change the name to gmplsTunnelDownstreamRecipientForNotify Nack as above How about: gmplsTunnelDownNotifyRecipient > 14) gmplsTunnelAdminStatusFlags (please see comments > regarding the name of this TC and make adjustments > to the name and DESCRIPTION of this object as appropriate). Ack > 15) gmplsTunnelExtraParamsPtr OBJECT-TYPE > > This object does not seem appropriate for this MIB. > It would seem an enterprise MIB could do something > like this (and possibly not use a RowPointer) so > please explain what the intention is. Nack See discussions of rowPointer in the LSR MIB. We need to be easily extensible to standard MIB modules that will provide additional parameters as described in the DESCRIPTION clause. Such MIB modules will contain tables the entries of which will each be used by multiple tunnels. In this context a row pointer is appropriate. > 16) gmplsTunnelHopTable OBJECT-TYPE > The storage type for an entry in this table is inherited from > mplsTunnelHopStorageType in the corresponding entry in > mplsTunnelHopTable. > > Please change to: > > The storage type for this entry is given by the value > of mplsTunnelHopStorageType in the corresponding entry in the > mplsTunnelHopTable. Ack > 17) gmplsTunnelHopExpLabel OBJECT-TYPE > > DESCRIPTION > "If gmplsTunnelHopLabelStatuses object indicates that a forward > label is present and gmplsTunnelHopExpLabelPtr contains the > value zeroDotZero, then the label to use on this hop is found in > object encoded within a 32-bit integer." > > Think the last part of this sentence is awkward: > > ...to use on this hop is represented by the value of this object. Ack > 18) gmplsTunnelHopExpLabel and gmplsTunnelHopExpLabelPtr > > Need to add the word "Forward" in here as in > gmplsTunnelHopExpForwardLabel and gmplsTunnelHopExpForwardLabelPtr > > That way it will be consistent with the Reverse counterparts. Nack Please see point 21 about name lengths. We will insert "Fwd" > 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpReverseLabelPtr > > Please change Rvrs to Reverse. Nack Please see point 21 about name lengths > 20) gmplsTunnelHopLabelStatuses and gmplsTunnelARHopLabelStatuses > > Please change Statuses to State. Nack Status is the correct word. State would be incorrect. > 21) gmplsTunnelARHopExpLable and gmplsTunnelARHopExpLabelPtr > > Need to add the word "Forward" in here as in > gmplsTunnelARHopExpForwardLabel and gmplsTunnelARHopExpForwardLabelPtr Nack Would excede 32 characters. Will use "Fwd" > 22) gmplsTunnelARHopExpRvrsLabel and gmplsTunnelARHopExpRvrsLabelPtr > > Please change Rvrs to Reverse Nack See point 21 > 23) gmplsTunnelARHopProtection OBJECT-TYPE > > Please add what the BIT set (i.e. 1) vs. 0 means in the > DESCRIPTION. Ack Limited change as before. > 24) gmplsTunnelCHopLabelTable objects > > Similar comments regarding the objects in this table > to those above with regard to naming > conventions (Forward and Reverse) and DESCRIPTIONs. Will not repeat the > details, please refer to above comments on the > prior 2 tables. Nack Same answers as before. Will use "Fwd" > 25) gmplsTunnelReversePerfTable > Please add to the DESCRIPTION how a user knows if > this is a bidirectional tunnel (i.e. what object > or objects in the gmplsTunnelTable need to have > what values?). Ack > 26) gmplsTunnelReversePerfPackets > > Does this object represent the 32-bit > value of the least significant part of the > 64-bit value (which is contained in gmplsTunnelReversePerfHCPackets)? Ack > 27) gmplsTunnelReversePerfBytes > > Does this object represent the 32-bit > value of the least significant part of the > 64-bit value (which is contained in gmplsTunnelReversePerfHCBytes)? Ack > 28) gmplsTunnelErrorTable OBJECT-TYPE > > Since this table applies to MPLS, it should be > put in a separate MIB module which is MPLS specific. The > prefix of gmpls could be confusing. Nack This is applicable across MPLS and GMPLS. Error TLVs are not present in MPLS RSVP-TE at this time. They may be added later. > 29) gmplsTunnelErrorTLVs OBJECT-TYPE > > Need to add a variable size to this string. When the string > size is 0 that would indicate that no TLVs are present, so > the DESCRIPTION should be modified to reflect this. Ack As per discussion with David. > 30) gmplsTunnelErrorHelpString OBJECT-TYPE > SYNTAX DisplayString > > DisplayString is not used in newer MIBs because it does not > meet internationalization standards, better to use > SnmpAdminString or something which meets internationalization > standards. Ack > 31) Compliance > > Please move some of the following comment in the > DESCRIPTION of gmplsTeModuleFullCompliance > > -- The mandatory group has to be implemented by all LSRs that > -- originate, terminate or act as transit for TE-LSPs/tunnels. > -- In addition, depending on the type of tunnels supported, other > -- groups become mandatory as explained below. Ack > 32) gmplsTunnelUnnumIf does not appear in the ReadOnly compliance > and it probably should. Ack > Section 11.2.1. IANA-GMPLS-MIB Definition > ----------------------------------------- > 33) Please change the name of this MIB to > IANA-GMPLS-TC-MIB > > and instead of: ianaGmpls MODULE-IDENTITY > please use: ianaGmplsTcMIB MODULE-IDENTITY Ack > 34) Please add the following to the DESCRIPTION: > "Copyright (C) The Internet Society (2005). The initial version > of this MIB module was published in RFC XXXX. For full legal > notices see the RFC itself. Supplementary information > may be available on: > http://www.ietf.org/copyrights/ianamib.html Ack > 35) Please change GMPLS-TE-MIB's to GMPLS-TE-STD-MIB's [RFCXXX] (RFC-Editor > please fill in the XXX based on the RFC number for > draft-ietf-ccamp-gmpls-te-mib > and remove this note) in the > DESCRIPTION clauses of ALL TCs. Ack > 36) Please change the name IANAGmplsLSPEncoding to > IANAGmplsLSPEncodingType. (more closely matches what's on > IANA's website now) Ack > 37) Please change the name IANAGmplsGPid to > IANAGmplsGeneralizedPid Ack > 38) I believe that the TC > > IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION > > should be put in the GMPLS-TC-STD-MIB or should just > remain in the GMPLS-TE-STD-MIB. The reason is that this > is not an assigned numbers list maintained by IANA, so > should not be in the IANA GMPLS MIB. If I am incorrect > about this please let me know, but I didn't see an IANA > maintained Administrative Status Information enum. Nack There are no fewer than three requests in CCAMP I-Ds that have passed WG last call for this space to be managed by IANA. > Additionally, this should be renamed to > GmplsAdminStatusInformation which more closely matches rfc3471. Ack > 39) Several comments on the SYNTAX clause: > > 40a) smicngPRO gives the error > > E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS > must be in contiguous positions > > SYNTAX BITS { > delInProgress (0), > adminDown (1), > testing (2), > reflect (31) > } > > > RFC2578 specifies that BITS should be contiguous > (although there are exceptions to this, but this > object does not seem to be an exception). Nack To quote the DESCRIPTION... The relationship between the assignment of gmplsTunnelAdminStatusFlags values and of the bit flags in the Admin Status object or TLV within the GMPLS signaling protocols is solely the purview of IANA and is subject to change without notice." However, it seems to us that making the bits match the flags in the Admin Status object is a Good Idea (TM). > Could delInProgress, be renamed to deleteInProgress ? > Could adminDown be renamed to administrativelyDown? > These names more closely match 3471. Ack > 40b) Please put in the specific section number on this > reference (section 8?). Ack From owner-ccamp@ops.ietf.org Thu Sep 22 19:46:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIam9-00022x-Fn for ccamp-archive@megatron.ietf.org; Thu, 22 Sep 2005 19:46:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13727 for ; Thu, 22 Sep 2005 19:46:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIasS-0003Cu-Db for ccamp-archive@ietf.org; Thu, 22 Sep 2005 19:53:21 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIae1-0001JO-Dx for ccamp-data@psg.com; Thu, 22 Sep 2005 23:38:25 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIady-0001J9-KH for ccamp@ops.ietf.org; Thu, 22 Sep 2005 23:38:23 +0000 Received: from du-069-0058.access.clara.net ([217.158.132.58] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EIQYi-000GNO-En; Thu, 22 Sep 2005 13:52:28 +0100 Message-ID: <119b01c5bf74$daed3f20$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , References: <3.0.1.32.20050908114852.0147664c@pop.mindspring.com> Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Thu, 22 Sep 2005 13:55:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 52005c17383d4e3f609075a067e11971 Content-Transfer-Encoding: 7bit Hi again Joan, This is the response to your excellent review of the GMPLS LSR MIB module. As before, I have indicated Ack or Nack for each point you raised. Where there is a Nack I have indicated either our reasoning or a proposed alternate solution. Feel free to snip in any response you send. Once we have closure on a few remaining issues we will respin applying David's comments on the TE MIB here as well. Cheers, Adrian >Section 1.1 Migration Strategy >-------------------------------- > >1) Does the following statement refer to the >GMPLS LSR MIB module? > > "The GMPLS Label MIB module may be referenced using a row pointer from > objects within the LSR MIB module." > ^^^^ >As previously mentioned, using the entire MIB module name >would be clearer. Ack >Section 4. Outline >--------------------- > >2) Need to clarify the phrase "this MIB module" because >there are 2 MIB modules in this document. > > > "- Enabling GMPLS on GMPLS capable interfaces using this MIB module." > >(which is referring to the GMPLS-LSR-STD-MIB module??) > >... > > "- Optionally setting up labels in the label table in this MIB module > if the textual convention MplsLabel is not capable of holding the > required label (for example, if the label requires more than 32 > bits to encode it), or if the operator wishes to disambiguate > GMPLS label types." > >The phrase, "in this MIB module", needs to be clarified since there >are 2 mib modules in this document. Here, I think you are >referring to the GMPLS-LABEL-STD-MIB, but prior to this you use >a similar phrase and are referring the the GMPLS-LSR-STD-MIB. >Please consistently specify the MIB modules by using their >names. Ack. >3) Please move section, 4.1 MIB Modules to section 1.1, Migration >Strategy. There is much overlap in these 2 sections so please >combine them. Ack >Section 4.1.2 Summary of GMPLS Label MIB Module >------------------------------------------------- > >4) "Generalized Labels can be of variable length and have distinct > bit-by-bit interpretations according to the use that is made of > them." > >Please change the above to: > > "Generalized Labels can be of variable length and have distinct > bit-by-bit interpretations depending upon how they are defined > by the specific service provider." Nack. Nothing to do with the service provider. Will change to: "Generalized Labels can be of variable length and have distinct bit-by-bit interpretations depending upon how they are defined for the specific technology in which they are used. For example, labels used for MPLS packet switching are different in length and content from labels used in TDM timeslot switching." >5) Same section, 4.1.2 Summary of GMPLS Label MIB Module > >Please remove this last sentence: > > These tables are described in the subsequent sections. Ack. >6) "This MIB module..." > >Please clarify which MIB module, i.e. The GMPLS-LSR-STD-MIB module Ack >7) Please specifically call out which term you will be using in >this document. Beginning with the 3rd paragraph, there is much >terminology, so please add some statement such as: > >"In this document, the terms 'forward' and 'reverse' will be used. Ack >Section 6. Example of LSP Setup >------------------------------- > >8) First and second sentences: > "In this section we provide a brief example of using the MIB objects > described in sections 7 and 8 to set up an LSP. While this example is > not meant to illustrate every nuance of the MIB, it is intended as an > aid to understanding some of the key concepts..." > >The phrase, "every nuance of the MIB" should probably be >"every nuance of the MIB modules" since you are referring to both >of the MIB modules (sections 7 and 8). Ack >9) Typo: gmplsLableTable Ack >10) Typo: accesible (in several places) Ack >Section 7. GMPLS-LSR-STD-MIB >====================== > >11) smicngpro gives the following: > >E: f(GMPLS-LSR-STD-MIB), (315,8) Item "ifGeneralInformationGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (316,8) Item "ifCounterDiscontinuityGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (322,8) Item "mplsInterfaceGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (323,8) Item "mplsInSegmentGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (324,8) Item "mplsOutSegmentGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (325,8) Item "mplsXCGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (326,8) Item "mplsPerfGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (327,8) Item "mplsLsrNotificationGroup" should be IMPORTed >W: f(GMPLS-LSR-STD-MIB), (358,18) For "gmplsOutSegmentTTLDecrement", syntax is identical >E: f(GMPLS-LSR-STD-MIB), (378,8) Item "ifGeneralInformationGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (379,8) Item "ifCounterDiscontinuityGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (385,8) Item "mplsInterfaceGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (386,8) Item "mplsInSegmentGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (387,8) Item "mplsOutSegmentGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (388,8) Item "mplsXCGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (389,8) Item "mplsPerfGroup" should be IMPORTed >W: f(GMPLS-LSR-STD-MIB), (404,14) For "gmplsInterfaceSignalingCaps", syntax is identical >W: f(GMPLS-LSR-STD-MIB), (415,18) For "gmplsInterfaceRsvpHelloPeriod", syntax is identical >W: f(GMPLS-LSR-STD-MIB), (431,18) For "gmplsInSegmentExtraParamsPtr", syntax is identical >W: f(GMPLS-LSR-STD-MIB), (447,18) For "gmplsOutSegmentTTLDecrement", syntax is identical >W: f(GMPLS-LSR-STD-MIB), (454,18) For "gmplsOutSegmentExtraParamsPtr", syntax is identical > > >Please correct the above. > >Also, please change the following 2 statements (which appear twice) >to remove the SYNTAX, since this is redundant, unless there is >a reason why you prefer to leave it. > > OBJECT gmplsInSegmentDirection > SYNTAX GmplsSegmentDirection > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required. Only forward(1) needs to be > supported by implementations that only support unidirectional > LSPs." > > > OBJECT gmplsOutSegmentDirection > SYNTAX GmplsSegmentDirection > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required. Only forward(1) needs to be > supported by implementations that only support unidirectional > LSPs." > >Compiles cleanly with smilint. Ack. (I wish smilint caught the other errors.) >12) DESCRIPTION > Please change the first paragraph to (this comment applies to > the other MIB modules also.) > > Copyright (C) The Internet Society (2005). This version of > this MIB module is part of RFC XXX; see the RFC itself for > full legal notices. Ack >13) Change the following: > > GmplsSegmentDirection > FROM GMPLS-TC-STD-MIB -- GMPLSTCMIB > -- RFC-Editor please resolve the reference above > >TO: > > GmplsSegmentDirection > FROM GMPLS-TC-STD-MIB -- RFCXXXX > -- RFC-Editor please resolve the reference above > -- and remove this note. Ack >14) Please remove: > > -- Notifications > -- no notifications are currently defined. > gmplsLsrNotifications OBJECT IDENTIFIER ::= { gmplsLsrStdMIB 0 } > >(You don't need to change any numbering, but no sense defining >a number you don't need). Ack >15) Please remove comments such as (this request is made > for all MIB modules in all 3 documents): > -- Top level components of this MIB module. > -- Tables, Scalars > -- Conformance > -- GMPLS Interface Table. > > -- End of gmplsInterfaceTable > > -- In-segment table. > >etc. Ack >16) gmplsInterfaceEntry OBJECT-TYPE > > "A conceptual row in this table is created automatically by an > LSR for every interface capable of supporting GMPLS and which > is configured to do so." > >Please change first sentence: > > "A conceptual row in this table is created automatically by an > LSR when the interface is capable of supporting GMPLS and is > correctly configured to do so." Nack Agree original is not perfect, but replacement says "the interface" without specifying which interface. Will change to: "A conceptual row in this table is created automatically by an LSR for each interface that is both capable of supporting GMPLS and that is configured to support GMPLS." > .... > >Please change the first sentence of the last paragraph: > > "The indexing is the same as that for mplsInterfaceTable." > >to: > > "The indexing is the same as the mplsInterfaceTable." Nack. Will change to: "The indexes are the same as for the mplsInterfaceTable." >17) object: gmplsInterfaceSignalingCaps OBJECT-TYPE > > SYNTAX BITS { > unknown (0), > rsvpGmpls (1), > crldpGmpls (2), -- note the use of CR-LDP is deprecated > otherGmpls (3) > } > > >What is otherGmpls(3)?? Nack I'm embarrassed to say that there are other "GMPLS" signaling protocol variants that have been developed outside the IETF. This was added in response to a WG request. >Also, this description is confusing. How can unknown(0) and >rsvpGmpls(1) be set simultaneously? Ack Will add: ...but if unknown(0) is set, no other bit may be set. >Additionally, how can no bits be set? If this is a GMPLS interface, >then doesn't one of these bits HAVE to be set? Ack As it says... Setting no bits implies that GMPLS signaling cannot be performed on this interface and all LSPs must be manually provisioned or that this table entry is only present to supplement an entry in the mplsInterfaceTable by providing the information carried in other objects in this row. This means that we should change gmplsInterfaceEntry to read: "A conceptual row in this table is created automatically by an LSR for each interface that is both capable of supporting GMPLS and that is configured to support GMPLS. Note that support of GMPLS is not limited to control plane signaling, but may include data-plane only function configured through SNMP SET commands performed on this MIB module. A conceptual row in this table may also be created via SNMP SET commands or automatically by the LSR to supplement a conceptual row in the mplsInterfaceTable where the interface is not capable of GMPLS but where the other objects carried in this row provide useful additional information for an MPLS interface." >18) gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE > "Period, in milliseconds, between sending RSVP Hello messages on > this interface. A value of 0 indicates that no Hello messages > should be sent on this interface." > >This object is only valid if the gmplsInterfaceSignalingCaps >object is set to rsvpGmpls. Please update the description >to reflect that. Nack It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB). We can add: This object is not valid if gmplsInterfaceSignalingCaps is set to crldpGmpls (2) >19) gmplsInSegmentEntry OBJECT-TYPE > "An entry in this table extends the representation of an incoming > segment represented by an entry in mplsInSegmentTable. An entry > can be created by a network administrator or an SNMP agent, or a > GMPLS signaling protocol. > >Please use the phrase: "via SNMP SET commands to create an entry" >in place of "SNMP agent". Ack >20) same entry, gmplsInSegmentEntry > > Note that the storage type for this entry SHOULD be inherited > from the corresponding entry in the mplsInSegmentTable given by > the value of the mplsInSegmentStorageType object." > >Please change to: > >Note that the storage type for this entry is given by the value >of mplsInSegmentStorageType in the corresponding entry of the >mplsInSegmentTable. Ack >21) gmplsInSegmentDirection OBJECT-TYPE > >Please use "corresponding" instead of "associated" Ack >22) gmplsInSegmentExtraParamsPtr OBJECT-TYPE > SYNTAX RowPointer > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Some Tunnels will run over transports that can usefully support > technology-specific additional parameters (for example, SONET > resource usage). Such can be supplied from an external table and > referenced from here. A value of zeroDotzero in this attribute > indicates that there is no such additional information." > DEFVAL { zeroDotZero } > ::= { gmplsInSegmentEntry 2 } > >What is meant by "external table"? If this is an enterprise-specific >table, then is it necessary to have this object in the MIB. In other >words, why is this MIB dictating that a row-pointer be used when >an enterprise-specific MIB may which to simply use indices. > >I think this object is unnecessary, but maybe I don't understand >something. Nack rowPointers are typically used when there may be a many-to-one mapping. This is appropriate for traffic parameters because there may be a few service categories defined in a traffic parameters table, and multiple LSPs may use those parameters. Compare with mplsInSegmentTrafficParamPtr in RFC3813. Now, in this case no such traffic parameters table has been supplied. To some extent we are guilty of future-proofing. We are aware that such tables will need to be added for TDM (quite soon), for lambda (possibly), and for Ethernet (almost certainly). Although it would be possible to leave this out, we feel that the necessary single-object extension that would need to be created later would be messy. >23) gmplsOutSegmentEntry OBJECT-TYPE >Same comments as with gmplsInSegmentEntry Nack Same answer >24) gmplsOutSegmentDirection OBJECT-TYPE >Same comment as with gmplsInSegmentDirection Ack >25) gmplsOutSegmentTTLDecrement OBJECT-TYPE > > "This object indicates the amount by which to decrement the TTL > of any payload packets forwarded on this segment if per-hop > decrementing is being done. > >Please change above to: > >This object indicates the amount to decrement the TTL... Nack If we want to be picky, even Webster doesn't recognise "decrement" as a verb. But this is a particularly useful verbization that is is common usage. But I also believe in the use of prepositions. So no change. >26) same object's gmplsOutSegmentTTLDecrement OBJECT-TYPE > > A value of zero indicates that no decrement should be made or > that per-hop decrementing is not in force. > >Please change: in force to enforced. Nack Will change to "in use" >27) gmplsOutSegmentExtraParamsPtr OBJECT-TYPE > >Same comment as with gmplsInSegmentExtraParamsPtr Nack Same answer >28) Compliance Statements > >I believe that gmplsInSegmentExtraParamsPtr and >gmplsOutSegmentExtraParamsPtr do not need to be >supported, so these maybe should be optional. Ack >Section 8. GMPLS-LABEL-STD-MIB >=================================== >smicngPRO gives the following: > >E: f(GMPLS-LABEL-STD-MIB), (21,13) Module "MPLS-TC-STD-MIB" has already been specified in IMPORTS clause Ack >E: f(GMPLS-LABEL-STD-MIB), (481,12) Group "gmplsLabelTableGroup" is both a MANDATORY and conditional group for module "GMPLS-LABEL-STD-MIB" Ack >Compiles cleanly with smilint. > >Also, disconnect in the numbering of the >gmplsLabelTable: > > | \-v-1 gmplsLabelInterface, name "InterfaceIndexOrZero", na, current > | |-2 gmplsLabelIndex, Unsigned32(0..4294967295), na, current > | |-3 gmplsLabelSubindex, Unsigned32(0..4294967295), na, current > | |-4 gmplsLabelType, name "GmplsGeneralizedLabelTypes", rc, current > >---> 5 is missing Ack >29) DESCRIPTION > Please change the first paragraph to (this comment applies to > the other MIB modules also.) > > Copyright (C) The Internet Society (2005). This version of > this MIB module is part of RFC XXX; see the RFC itself for > full legal notices. Ack >30) Please remove these statements (don't need to change any numbers). > > -- Notifications > -- no notifications are currently defined. > gmplsLabelNotifications OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 0 } Ack >31) gmplsLabelTable OBJECT-TYPE > >The last part of the last paragraph is awkward: > > "... Labels in the tables in other MIBs are referred to using > row pointer into this table. The indexing of this table provides > for arbitrary indexing and also for concatenation of labels." > >Are you saying that other MIBs can use a row pointer to point to >this table? Why would they do that if they could just use the >indices directly? Also, I don't follow the comment about >concatenation of labels. Could you explain this? Nack Yes we are saying that other MIB modules can use a row pointer to point to this table. Yes they could use indices. This was the subject of a very lengthy discussion between the co-authors, etc., but in the end we observed that mplsInSegmentLabelPtr and mplsOutSegmentLabelPtr (RFC3813) are rowPointers so we had better support being pointed to. We could soften the language here by replacing "are" with "may". Note, we should change this to say "MIB modules" For an example of label concatenation see RFC3945 section 7.1. In essence, a GMPLS label may be composite in order to identify a set of resources in the data plane. Practial examples are timeslots and wavelength sets (which are not contiguous like wavebands). The indexing mechanism allows multiple entries in this table to be seen as a sequence of labels that should be concatenated. Ordering is potentially very sensitive for concatenation. I don't believe we need to add text or references for concatenated labels since they are part of the architecture. >32) gmplsLabelEntry OBJECT-TYPE > >The last sentence of the DESCRIPTION, please remove >the word "more" from the phrase "is more persistent." Nack. The Textual Convention gives us degrees. That is, 'readOnly' is more durable than 'permanent' which is more durable than 'nonNolatile' which is more durable than 'volatile'. We need to convey that there is a ranked inheritance. "Persistence" is acceptable in a comparative. >I still don't understand how the subindex provides a way >to concatenate the labels. Could you give an example? Nack If you are asking for an example in the I-D, I don't think it is necessary. For your information, the composite label {{A}, {B}, {C}} might be constructed as... gmplsLabelInterface = 1 gmplsLabelIndex = 1 gmplsLabelSubindex = 1 gmplsLabelFreeform = A gmplsLabelInterface = 1 gmplsLabelIndex = 1 gmplsLabelSubindex = 2 gmplsLabelFreeform = B gmplsLabelInterface = 1 gmplsLabelIndex = 1 gmplsLabelSubindex = 3 gmplsLabelFreeform = C >33) please switch RowStatus and StorageType (this will >more closely match the other MPLS MIBs). Ack >34) gmplsLabelInterface OBJECT-TYPE > >DESCRIPTION also needs to specify that zero may be >used to indicate that the InterfaceIndex is not known >or that an InterfaceIndex exists but it is not important >wrt this implementation so zero is used. Nack The use of zero is very precisely specified at the moment. The reasons for setting zero that you cite are: - the InterfaceIndex is not known You cannot have a per-interface label space without knowing the interface to which it applies. - InterfaceIndex exists but it is not important wrt this implementation That is exactly the case of the global label space, and is already stated. >35) gmplsLabelIndex OBJECT-TYPE > SYNTAX Unsigned32 (0..4294967295) > >36a) I was expecting the SYNTAX to be IndexInteger due >to the gmplsLabelIndexNext in the DESCRIPTION. >Please explain why the use of zero is needed. You >explain the use of zero in the gmplsLabelInterface >and gmplsLabelSubindex indices. Nack This is explained by the paragraph: Note that implementations that are representing 32 bit labels within this table MAY choose to align this index with the value of the label, but should be aware of the implications of sparsely populated tables. We believe it would be inappropriate to use IndexInteger to have greater meaning than just an index. But anyway, IndexInteger is Unsigned32 (1..4294967295) and the quoted paragraph must allow zero as well. >36b)Please change the "may" to "should" in this statement: > A management application may read the gmplsLabelIndexNext > object to find a suitable value for this object." Nack Why "should" it do this? This is a convenience offered to it. It may use any mechanism it chooses including the one suggested in the quoted paragraph above. >37) gmplsLabelType OBJECT-TYPE > > of gmplsMplsLabel (1) denotes that a 23 bit MPLS packet label is > present, but does not describe whether this is signaled using > MPLS or GMPLS. > >Is this 23 bit value correct? Is this a FrameRelay DLCI label? Ack This is terrible text! Yes. 23 bits is FrameRelay. This text should be much more expansive allowing a 20 bit MPLS label, a 10 or 23 bit FR label, or a 28 bit ATM label. It should also refer to the gmplsLabelMplsLabel object. >38) gmplsLabelRowStatus OBJECT-TYPE >MUST explain which columns must be properly configured >before the row can be made active (as per RFC2579) Ack >39) Please clarify in the DESCRIPTION of each of >the following groups, if the group is optional >or needs to be supported by such implementations: > GROUP gmplsLabelPacketGroup > DESCRIPTION > "This group extends gmplsLabelTableGroup for implementations that > support packet labels." > > GROUP gmplsLabelPortWavelengthGroup > DESCRIPTION > "This group extends gmplsLabelTableGroup for implementations that > support port and wavelength labels." > > GROUP gmplsLabelFreeformGroup > DESCRIPTION > "This group extends gmplsLabelTableGroup for implementations that > support freeform labels." > > GROUP gmplsLabelSonetSdhGroup > DESCRIPTION > "This group extends gmplsLabelTableGroup for implementations that > support SONET or SDH labels." > > GROUP gmplsLabelWavebandGroup > DESCRIPTION > "This group extends gmplsLabelTableGroup for implementations that > support Waveband labels." Ack >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > >Please change the name to: gmplsLabelModuleReadOnlyCompliance >to be consistent with the other MPLS and GMPLS MIB modules. Nack I thought we tried to keep names down to 32 characters. I recall this conversation before. Not mandatory, but desirable. A choice between two desires? >41) The ReadOnly compliance for gmplsLabelRowStatus >does NOT have a MIN-ACCESS of read-only. Is this >intentional? ??? Not sure about this. I thought the present of a WRITE-SYNTAX made some difference. >42) Also, (related to the above) > OBJECT gmplsLabelRowStatus > SYNTAX RowStatus { > active(1), > notInService(2) > } > > WRITE-SYNTAX RowStatus { > active(1), > notInService(2), > createAndGo(4), > destroy(6) > } > DESCRIPTION > "Support for notInService, createAndWait and notReady is not > required." > >The DESCRIPTION clause conflicts with the WRITE-SYNTAX. >Please clarify the intentions for this ReadOnly compliance >object. Ack There is an error here. >Section 12.2 Informational References >--------------------------------------- > >43a) The title of this section should be >Informative. Ack/Nack I am aware of the RFC Editor's preferences. Unfortunately these references are only informative if you read an understand them (and even then not always :-), but they are informational even if you don't read or understand them. >43b) Please move the following from >Informative to Normative. > > [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol > Label Switching (GMPLS) Signaling Functional > Description", RFC 3471, January 2003. > > [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), > "Generalized MPLS Signaling - CR-LDP Extensions", > RFC 3472, January 2003. > > [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - > RSVP-TE Extensions", RFC 3473 January 2003. > > [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), > "Generalized Multi-Protocol Label Switching > Extensions for SONET and SDH Control", > draft-ietf-ccamp-gmpls-sonet-sdh, work in progress. Ack. >43c) The above reference now appears to be RFC 3946. > >Please change the above (NOTE also the changes in the >reference itself, more on the Reference format next): > > [GMPLS-SONET] Mannie, E. and D. Papadimitriou, "Generalized Multi- > Protocol Label Switching (GMPLS) Extensions for > Synchronous Optical Network (SONET) and Synchronous > Digital Hierarchy (SDH) Control", RFC 3946, October > 2004. Ack. My how time flies. >44) There are a number of references (as discovered by >Bert) that aren't in the RFC expected format. >Please review all the references in this document and >the other GMPLS MIB docs. > >Here are some to change. One suggestion is to copy a reference >(if possible) from an existing RFC. Sometimes a date is missing >and sometimes the authors/editors names do not appear as >expected. Also, titles need to appear exactly as on >the RFC. Please check the other GMPLS docs also. >(NOTE: see also draft-rfc-editor-rfc2223bis-08.txt) Ack >Please change: > [RFC2026] S. Bradner, "The Internet Standards Process -- > Revision 3", RFC 2026, October 1996. > >to: > > [RFC2026] Bradner, S., "The Internet Standards Process -- > Revision 3," BCP 9, RFC 2026, October 1996. > >Please change: > > [RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces > Group MIB", RFC 2863, June 2000. > >to (author name misspelled): > > [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group > MIB", RFC 2863, June 2000. > >Please change: > > [RFC3032] Rosen, E. et al, "MPLS Label Stack Encoding", > RFC 3032, January 2001. > >to: > > [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., > Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack > Encoding", RFC 3032, January 2001. > > >Please change: > > [RFC3212] Jamoussi, B., Aboul-Magd, O., Andersson, L., > Ashwood-Smith, P., Hellstrand, F., Sundell, K., > Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, > T., Feldman, N., Fredette, A., Girish, M., Gray, > E., Halpern, J., Heinanen, J., Kilty, T., Malis, > A., and P. Vaananen, "Constraint-Based LSP Setup > using LDP", RFC 3212, December 2001." > >to: > > [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., > Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., > Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. > Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, > January 2002. > > >Please change: > > [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An > Architecture for Describing Simple Network > Management Protocol (SNMP) Management Frameworks", > RFC 3411, December 2002. > >to: > [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An > Architecture for Describing Simple Network > Management Protocol (SNMP) Management > Frameworks", STD 62, RFC 3411, December 2002. > >Please change: > > [RFC3413] Levi, D., Meyer, P., Stewart, B., "SNMP > Applications", RFC 3413, December 2002. >to: > [RFC3413] Levi, D., Meyers, P. and B. Stewart, "Simple Network > Management Protocol (SNMP) Applications", STD 62, RFC > 3413, December 2002. > > >Please change: > [RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) > Processing in Multi-Protocol Label Switching > (MPLS) Networks", RFC 3443, January 2003. > >to: > [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) > Processing in Multi-Protocol Label Switching > (MPLS) Networks", RFC 3443, January 2003. > > >Please change: > [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol > Label Switching (GMPLS) Signaling Functional > Description", RFC 3471, January 2003. > > >to: > [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol > Label Switching (GMPLS) Signaling Functional > Description", RFC 3471, January 2003. > > >Please change: > > [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), > "Generalized MPLS Signaling - CR-LDP Extensions", > RFC 3472, January 2003. > >to: > [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, > "Generalized Multi-Protocol Label > Switching (GMPLS) Signaling Constraint-based > Routed Label Distribution Protocol (CR-LDP) > Extensions", RFC 3472, January 2003. > >Please change: > > [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - > RSVP-TE Extensions", RFC 3473 January 2003. > >to: > [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol > Label Switching (GMPLS) Signaling - Resource > ReserVation Protocol-Traffic Engineering (RSVP-TE) > Extensions", RFC 3473, January 2003. Ack From owner-ccamp@ops.ietf.org Thu Sep 22 19:53:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIasU-00047k-70 for ccamp-archive@megatron.ietf.org; Thu, 22 Sep 2005 19:53:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13964 for ; Thu, 22 Sep 2005 19:53:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIayo-0003Ni-BP for ccamp-archive@ietf.org; Thu, 22 Sep 2005 19:59:55 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIanr-0002Mp-9Y for ccamp-data@psg.com; Thu, 22 Sep 2005 23:48:35 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIano-0002MX-Ia for ccamp@ops.ietf.org; Thu, 22 Sep 2005 23:48:33 +0000 Received: from du-069-0058.access.clara.net ([217.158.132.58] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EIQT3-000FNc-Dw; Thu, 22 Sep 2005 13:46:29 +0100 Message-ID: <119a01c5bf74$096235f0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , References: <3.0.1.32.20050908213717.014708c8@pop.mindspring.com> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Thu, 22 Sep 2005 13:49:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Content-Transfer-Encoding: 7bit Hi Joan, Thanks again for the thorough review. Please see below our responses on the general comments and the TC MIB module. I have indicated Ack or Nack for each point you raised. Where there is a Nack I have indicated either our reasoning or a proposed alternate solution. Cheers, Adrian > General comments for all 3 drafts: > ================================================ > 1*) Suggestion only: > When submitting these 3 GMPLS MIBs > you may want to ask RFC-editor > to give the GMPLS-TC-STD-MIB document the first > RFC number, and that all 3 GMPLS MIB docs appear > contiguously numbered. > > If you would like to incorporate this suggestion > then you'd need to add a paragraph to the > IANA Considerations section and put the usual > RFC-editor disclaimers around your request, such > as: > > > (Note to RFC-Editor:) > We request that you assign the first RFC number > to the draft-ietf-ccamp-gmpls-tc-mib, and also > assign contiguous numbers to all three GMPLS MIB > docs, i.e. draft-ietf-ccamp-gmpls-tc-mib, > draft-ietf-ccamp-gmpls-lsr-mib, and > draft-ietf-ccamp-gmpls-te-mib. > (Please remove this note prior to publication.) Ack > 2*) Table of Contents is incorrect, please > regenerate it, (e.g. The SNMP Management Framework > should be The Internet-Standard Management Framework). Ack > 3*) Question if these documents should have a > contributors section. It violates the guidelines > of "RFC Editorial Guidelines and Procedures" > http://www.rfc-editor.org/policy.html#policy.auth2 > > There are many people listed under > Authors but not listed on the front page, > so how about adding a Contributors Section? Ack We will change the title of "Authors' Addresses" section to be "Contact Details". That covers all > 4*) Tom's Contact info needs to be updated to > Boxborough. Ack > 5*) would be clearer to be consistent about > referring to MIB modules and always use the entire MIB name > and site the reference: > e.g. MPLS LSR MIB module or LSR MIB module, > should be MPLS-LSR-STD-MIB module [RFC3813] > > e.g. GMPLS LSR MIB module, should be > GMPLS-LSR-STD-MIB module [RFCXXX] (NOTE to RFC-Editor: > please fill in XXX with the RFC name for > draft-ietf-ccamp-gmpls-lsr-mib and remove this note.) Ack > 6*) The term "extends" is used and since this term is applied > to GMPLS interfaces, the more appropriate phrase is > 'sparse augments'. Please change this in the text. Ack > 7*) ORGANIZATION, please add IETF > as in "IETF Common Control and ...." Ack > 8*) DESCRIPTION > Please change the first paragraph to: > > Copyright (C) The Internet Society (2005). This version of > this MIB module is part of RFC XXX; see the RFC itself for > full legal notices. > > The exception to this is the IANA-GMPLS-MIB module, which should > include: > > "Copyright (C) The Internet Society (2005). The initial version > of this MIB module was published in RFC XXXX. For full legal > notices see the RFC itself. Supplementary information > may be available on: > http://www.ietf.org/copyrights/ianamib.html Ack > 9*) Please make sure to ask RFC-Editor to remove comments > prior to publication, e.g. > > -- RFC Editor's Note (to be removed prior to publication): > > "Initial version published as part of RFC XXXX." > -- replace XXX with actual RFC number & remove this note. Ack > 10*) Acknowledgements Section > Please start off this section with: > > This document is a product of the CCAMP Working Group. > > and remove: > > This draft is the work of the five authors listed in the next > section. Ack > 11*) Please change "Informational References" > to "Informative References" Bleagh Ack > 12*) There are a number of references (as discovered by > Bert) that aren't in the RFC expected format. > Please review all the references in this document and > the other GMPLS MIB docs. > Please see comments in the review of the > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > examples of references in the RFC format. Ack > draft-ietf-ccamp-gmpls-tc-mib-07.txt > ====================================== > > Section 3. GMPLS Textual Conventions MIB Definitions > --------------------------------------------------- > > 1) GmplsFreeformLabel TC > > 1a) Could the REFERENCE include section(s)? > I suspect that this is referring to the Generalized Label > described in section 3.2.1, is this correct? Ack All of the labels are Generalized Labels! > 1b) Please explain why this is 0..64 ? > RFC3471 states that the Generalized label can be > variable length, so wondering if this should be made > larger? Nack 64 is safely larger than will ever be used. > 1c) The DESCRIPTION needs a little work: > DESCRIPTION > "This value represents a freeform generalized MPLS Label. This > can be used to represent label types which are not standard in > the drafts. It may also be used by systems that do not wish to > represent the labels using the specific label types." > > Please reword to something like: > > "This value represents a freeform GMPLS label. A freeform GMPLS > label is specified by the system which uses it. In other words, > the freeform GMPLS label is not a standard GMPLS label type, > but is created by the system which uses it." Nack The text as originally stated is correct and your revision is wrong. That is, the freeform label MAY also be used to represent standard labels as octet strings. This is a popular way to handle the management of multiple different types of labels. Will change to: "This value represents a freeform GMPLS Label. This can be used to represent label that have label types which are not standardised. It may also be used by systems that do not wish to represent labels that have standardised label types using the type-specific objects in this table." > 2) GmplsGeneralizedLabelTypes TC > > 2a) Could you change the name of the TC > GmplsGeneralizedLabelTypes to > > GmplsLabelType > > It is more appropriate to have it singular when > Imported and used in other MIBs, and dropping the > word Generalized, because you already have the > prefix Gmpls. Ack > 2b) Could the SYNTAX order be changed? > > Currently: > > SYNTAX INTEGER { > gmplsMplsLabel(1), > gmplsPortWavelengthLabel(2), > gmplsFreeformGeneralizedLabel(3), > gmplsSonetLabel(4), > gmplsSdhLabel(5), > gmplsWavebandLabel(6) > } > > Proposed (NOTE also some of the names have been changed): > > SYNTAX INTEGER { > gmplsFreeformLabelOrOther(1), > gmplsMplsLabel(2), > gmplsPortAndWavelengthLabel(3), > gmplsSonetLabel(4), > gmplsSdhLabel(5), > gmplsWavebandLabel(6) > } Nack i. "FreeformOrOther" What other? There is just freeform. ii. Why re-order? The new order seems to have no more logic than the old order. > Section 4. Security Considerations > ------------------------------------- > > 3) Change MPLS to GMPLS in the following statement: > > "This module does not define any management objects. Instead, it > defines a set of textual conventions which may be used by other MPLS > MIB modules to define management objects." Ack > Section 5. IANA Considerations > ------------------------------------- > > 4) Section 5. IANA Considerations > RFC Editor's Note (to be removed prior to publication): > the IANA is requested to assign a value for "XXX" under > the mib-2/mplsStdMIB subtree and to record the assignment > in the SMI Numbers registry. > When the assignment has been made, the RFC Editor is > asked to replace the "XXX" (here and in the MIB module) with > the assigned value and to remove this note. Ack > 5) Section 5. IANA Considerations > > Please remove the last sentence of this section: > > "The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB." Ack > Section 6.2 Informational References. > --------------------------------------- > > 6) Section 6.2 Informational References. > Please change to "Informative". Grrrrrr. Ack > 7) I believe the following references should be moved > to the Normative section: > > [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), > "Generalized MPLS Signaling - CR-LDP Extensions", > RFC 3472, January 2003. Nack In fact not referenced and should be deleted. > [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - > RSVP-TE Extensions", RFC 3473 January 2003. Nack In fact not referenced and should be deleted. > [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual > Conventions and for Multiprotocol Label Switching > (MPLS) Management", RFC 3811, June 2004. Ack > [RFC3945] Mannie, E. (Editor), "Generalized Multiprotocol > Label Switching (GMPLS) Architecture", RFC 3945, > October 2004. Ack > [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), > "Generalized Multi-Protocol Label Switching > Extensions for SONET and SDH Control", > draft-ietf-ccamp-gmpls-sonet-sdh, work in progress. > > (the above is now RFC 3946) > [GMPLS-SONET] Mannie, E. and D. Papadimitriou, "Generalized Multi- > Protocol Label Switching (GMPLS) Extensions for > Synchronous Optical Network (SONET) and Synchronous > Digital Hierarchy (SDH) Control", RFC 3946, October > 2004. Nack In fact not referenced and should be deleted. > Also, as previously mentioned, need to check > on the format of these References. > Please see comments in the review of the > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > examples of references in the RFC format. Ack From info@mail.hdyfg.com Thu Sep 22 20:16:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIbEg-0001IQ-1L for ccamp-archive@megatron.ietf.org; Thu, 22 Sep 2005 20:16:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15054 for ; Thu, 22 Sep 2005 20:16:16 -0400 (EDT) Received: from [220.230.106.167] (helo=mail.hdyfg.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIbKy-0003wq-F1 for ccamp-archive@ietf.org; Thu, 22 Sep 2005 20:22:50 -0400 Received: (qmail 24196 invoked by uid 509); 23 Sep 2005 00:22:09 +0900 Date: 23 Sep 2005 00:22:09 +0900 Message-ID: <20050922152209.24195.qmail@mail.hdyfg.com> From: info@hdyfg.com To: ccamp-archive@ietf.org Subject: $B=iF|>7BT7t(B X-Spam-Score: 4.8 (++++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d $B!!5.J}MM$N40A4L5NAEPO?$K4X$7$FA4$F$NG'>Z$,ITMW$H$J$C$F$*$j$^$9!#2<5-%j%s%/$h$j0FFb2hLL$K=>$$!"4JC1$JuBV$G$9!#Aa$$J*>!$A!*!*(B $B!y?7%*!<%W%sFCE5!y(B $B-!?75,2q0w$,L5NA$G$4MxMQ$G$-$k0Y$K!"BgNL$NL5NA>CHq%]%$%s%H(B($B:GDc(B5,500$B1_AjEv(B)$B$b"((B24$B;~4V"($GDI2C2DG=!JEEOCG'>ZMW!K$G$9!#"(EEOCG'>Z$O5.J}K\?M$r3NG'$9$k0Y$N4JC1$J@\0FFbCW$7$^$9$N$G!"9%$_$N=w@-$r<+M3$K$*A*$Y$k$h$&$K$J$C$F$*$j$^$9!#$b$A$m$s; Fri, 23 Sep 2005 04:08:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIib1-0006fq-Og for ccamp-archive@ietf.org; Fri, 23 Sep 2005 04:07:57 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIiK7-000OPN-OH for ccamp-data@psg.com; Fri, 23 Sep 2005 07:50:23 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIiK6-000OOm-MH for ccamp@ops.ietf.org; Fri, 23 Sep 2005 07:50:22 +0000 Received: from du-069-0038.access.clara.net ([217.158.132.38] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1EH5aT-000JRD-Ij; Sun, 18 Sep 2005 21:16:34 +0100 Message-ID: <051e01c5bc8e$3d00aec0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: Implementations for draft-ietf-ccamp-gmpls-segment-recovery and draft-ietf-ccamp-gmpls-recovery-e2e-signaling Date: Sun, 18 Sep 2005 14:38:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 3.5 (+++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Hi, The AD is asking Kireeti and me to supply an informal report on the status of implementations of these two I-Ds. So, please send me/Kireeti private email that will allow us to answer Alex's questions. Which features in the drafts have you implemented? Have you done any interop work? Thanks, Adrian [Alex] > > >> >> what's the implementation status for these? [Adrian] > > >> > For certain I know of two implementations of segment recovery and one of > > >> > e2e recovery. I suspect another one of each. > > >> > > > >> > Is that enough or would you like me to pursue this a bit further? [Alex] > > >> What we need at this point is that all features in the doc have been > > >> implemented and whether the implementations are known to interop. [Kireeti] > > > Do you want a formal implementation report? Or a "verbal" statement > > > from the relevant parties? [Alex] > > An e-mail from you guys would suffice. From owner-ccamp@ops.ietf.org Fri Sep 23 07:54:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIm8Q-0005f1-4K for ccamp-archive@megatron.ietf.org; Fri, 23 Sep 2005 07:54:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09540 for ; Fri, 23 Sep 2005 07:54:32 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EImEo-0004K7-Hp for ccamp-archive@ietf.org; Fri, 23 Sep 2005 08:01:12 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIm1E-000Mhs-70 for ccamp-data@psg.com; Fri, 23 Sep 2005 11:47:08 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIm1D-000Mhe-7P for ccamp@ops.ietf.org; Fri, 23 Sep 2005 11:47:07 +0000 Received: from du-069-0165.access.clara.net ([217.158.132.165] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1EIm1B-000IO8-8F for ccamp@ops.ietf.org; Fri, 23 Sep 2005 12:47:06 +0100 Message-ID: <130f01c5c034$ead335f0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada Date: Fri, 23 Sep 2005 12:44:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit FYI ----- Original Message ----- From: To: Sent: Friday, September 23, 2005 5:00 AM Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada > > There are two (2) Internet-Draft cutoff dates for the 64th > IETF Meeting in Vancouver, British Columbia, Canada: > > October 17th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > October 17th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > October 10th at 9:00 AM ET. > > October 24th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, October 24th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, November 7th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 64th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_64.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > From owner-ccamp@ops.ietf.org Fri Sep 23 08:59:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIn9C-0004bD-JA for ccamp-archive@megatron.ietf.org; Fri, 23 Sep 2005 08:59:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12612 for ; Fri, 23 Sep 2005 08:59:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EInFa-0005tB-Ir for ccamp-archive@ietf.org; Fri, 23 Sep 2005 09:06:06 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIn3U-00048c-NG for ccamp-data@psg.com; Fri, 23 Sep 2005 12:53:32 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIn3U-00048L-33 for ccamp@ops.ietf.org; Fri, 23 Sep 2005 12:53:32 +0000 Received: from du-069-0408.access.clara.net ([217.158.145.154] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1EIn3S-000FRg-IX for ccamp@ops.ietf.org; Fri, 23 Sep 2005 13:53:31 +0100 Message-ID: <133f01c5c03e$32bd2890$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: New temporary registry Date: Fri, 23 Sep 2005 13:56:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi, Arthi pointed out that there were some conflicts in the early assignments of Error Values for the Error Code "Routing Problem". In order to make this a bit smoother I have set up a temporary registry of pre-IANA allocations of Error Values for this Error Code at http://www.olddog.co.uk/ccamp.htm Please let me know if you see any problems or want any additions made. Cheers, Adrian From owner-ccamp@ops.ietf.org Fri Sep 23 08:59:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIn9C-0004bE-Ni for ccamp-archive@megatron.ietf.org; Fri, 23 Sep 2005 08:59:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12613 for ; Fri, 23 Sep 2005 08:59:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EInFZ-0005sr-GC for ccamp-archive@ietf.org; Fri, 23 Sep 2005 09:06:06 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIn0P-0003h0-J9 for ccamp-data@psg.com; Fri, 23 Sep 2005 12:50:21 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIn0N-0003gN-6V; Fri, 23 Sep 2005 12:50:19 +0000 Received: from du-069-0408.access.clara.net ([217.158.145.154] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1EIn0J-000ESt-Iw; Fri, 23 Sep 2005 13:50:18 +0100 Message-ID: <133501c5c03d$ba40e3c0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Bill Fenner" , "'Kireeti Kompella'" References: <046701c5b3ed$8271e310$93849ed9@Puppy> Subject: draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt now back with AD Date: Fri, 23 Sep 2005 13:29:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Hi Alex, We held a further WG last call on this I-D after updating it to Proposed Standard as you requested. No-one objected to this change, so the I-D is now back with you for approval. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, September 07, 2005 9:48 PM Subject: Short further last call on draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > Hi, > > Alex has reviewed this I-D as AD and says it is fine, but he thinks we > should take it down the standards track as Proposed Standard not BCP as it > was previously marked. > > This revision changes: > - proposed status > - IPR boilerplate > - IANA clause to be a little more (about 10 words) detailed > > Since we have changed the proposed status, we need to check back with you > guys. > > Let's have a two week last call on this change. > > If you do spot other issues as you go, then I guess we can handle them > too. > > Last call will end 12 noon GMT on Thursday 22nd September. > > Thanks, > Adrian > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Wednesday, September 07, 2005 8:50 PM > Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > > > > 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 : Node ID based RSVP Hello: A Clarification Statement > > Author(s) : Z. Ali, et al. > > Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > > Pages : 7 > > Date : 2005-9-7 > > > > Use of Node-ID based RSVP Hello messages is implied in a number of > > cases, e.g., when data and control plan are separated, when TE links > > are unnumbered. Furthermore, when link level failure detection is > > performed by some means other than exchanging RSVP Hello messages, > > use of Node-ID based Hello session is optimal for detecting signaling > > adjacency failure for Resource reSerVation Protocol-Traffic > > Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear > > and this document formalizes use of Node-ID based RSVP Hello session > > as a best current practice (BCP) in some scenarios. The procedure > > described in this document applies to both Multi-Protocol Label > > Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > 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-rsvp-node-id-based-hello-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-rsvp-node-id-based-hello-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. > > > > > ------------------------------------------------------------------------ -- > ------ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > From owner-ccamp@ops.ietf.org Fri Sep 23 12:19:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqGq-0005FW-IP for ccamp-archive@megatron.ietf.org; Fri, 23 Sep 2005 12:19:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23518 for ; Fri, 23 Sep 2005 12:19:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EIqNF-0002LK-Ff for ccamp-archive@ietf.org; Fri, 23 Sep 2005 12:26:14 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EIqA8-0001L0-10 for ccamp-data@psg.com; Fri, 23 Sep 2005 16:12:36 +0000 Received: from [207.69.200.40] (helo=pop06.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EIqA6-0001Ki-9U for ccamp@ops.ietf.org; Fri, 23 Sep 2005 16:12:34 +0000 Received: from h-67-100-203-75.cmbrmaor.dynamic.covad.net ([67.100.203.75] helo=jluciani-laptop) by pop06.mail.atl.earthlink.net with smtp (Exim 3.36 #10) id 1EIqA2-00059Y-00; Fri, 23 Sep 2005 12:12:30 -0400 Message-Id: <3.0.1.32.20050923120504.01564e90@pop.mindspring.com> X-Sender: jcucchiara@pop.mindspring.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 23 Sep 2005 12:05:04 -0400 To: adrian@olddog.co.uk, tnadeau@cisco.com, ccamp@ops.ietf.org From: jcucchiara@mindspring.com Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Cc: bwijnen@lucent.com, jcucchiara@mindspring.com In-Reply-To: <119a01c5bf74$096235f0$28849ed9@Puppy> References: <3.0.1.32.20050908213717.014708c8@pop.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Adrian, Thank you for the quick turn around. I have removed issues where we are in agreement (both the ack'd and nack'd) and will comment only on those ones which might need further discussion (both ack'd and nack'd). Please see comments inline. thanks, Joan At 01:49 PM 9/22/05 +0100, Adrian Farrel wrote: >Hi Joan, > >Thanks again for the thorough review. > >Please see below our responses on the general comments and the TC MIB >module. > >I have indicated Ack or Nack for each point you raised. Where there is a >Nack I have indicated either our reasoning or a proposed alternate >solution. > >Cheers, >Adrian > >> General comments for all 3 drafts: >> ================================================ > >> 3*) Question if these documents should have a >> contributors section. It violates the guidelines >> of "RFC Editorial Guidelines and Procedures" >> http://www.rfc-editor.org/policy.html#policy.auth2 >> >> There are many people listed under >> Authors but not listed on the front page, >> so how about adding a Contributors Section? > >Ack >We will change the title of "Authors' Addresses" section to be "Contact >Details". >That covers all According to the rfc-editor website above, this should be "Contact Information", is this what you mean? > > >> draft-ietf-ccamp-gmpls-tc-mib-07.txt >> ====================================== >> >> Section 3. GMPLS Textual Conventions MIB Definitions >> --------------------------------------------------- >> 1) GmplsFreeformLabel TC >> >> 1c) The DESCRIPTION needs a little work: >> DESCRIPTION >> "This value represents a freeform generalized MPLS Label. This >> can be used to represent label types which are not standard in >> the drafts. It may also be used by systems that do not wish to >> represent the labels using the specific label types." >> >> Please reword to something like: >> >> "This value represents a freeform GMPLS label. A freeform GMPLS >> label is specified by the system which uses it. In other words, >> the freeform GMPLS label is not a standard GMPLS label type, >> but is created by the system which uses it." > >Nack >The text as originally stated is correct and your revision is wrong. That >is, >the freeform label MAY also be used to represent standard labels as octet >strings. >This is a popular way to handle the management of multiple different types >of >labels. > >Will change to: > "This value represents a freeform GMPLS Label. This can be used > to represent label that have label types which are not >standardised. > It may also be used by systems that do not wish to represent >labels > that have standardised label types using the type-specific >objects > in this table." > Sorry, I'm still a little foggy on what this TC is, partly because the description is referring to "objects in this table" which is confusing in a TC DESCRIPTION, and also the definition of the freeform label used here and used in the GmplsGeneralizedLabelType enum seems be defined slightly differently. A freeform label as described in the DESCRIPTION clause could contain the value of any GMPLS/MPLS labels, right? >> 2) GmplsGeneralizedLabelTypes TC >> 2b) Could the SYNTAX order be changed? >> >> Currently: >> >> SYNTAX INTEGER { >> gmplsMplsLabel(1), >> gmplsPortWavelengthLabel(2), >> gmplsFreeformGeneralizedLabel(3), >> gmplsSonetLabel(4), >> gmplsSdhLabel(5), >> gmplsWavebandLabel(6) >> } >> >> Proposed (NOTE also some of the names have been changed): >> >> SYNTAX INTEGER { >> gmplsFreeformLabelOrOther(1), >> gmplsMplsLabel(2), >> gmplsPortAndWavelengthLabel(3), >> gmplsSonetLabel(4), >> gmplsSdhLabel(5), >> gmplsWavebandLabel(6) >> } > >Nack >i. "FreeformOrOther" What other? There is just freeform. Aren't the label types: gmplsMplsLabel(2), gmplsPortAndWavelengthLabel(3), gmplsSonetLabel(4), gmplsSdhLabel(5), gmplsWavebandLabel(6) also a kind of freeform GMPLS label (as indicated by the DESCRIPTION clause in GmplsFreeformLabel)? >ii. Why re-order? The new order seems to have no more logic than the > old order. Partly depends on the answer to above i. question. If the labels are a kind of freeform label, then a better style would be to list gmplsFreeformLabel first. Admittedly, this is a NIT. Also, please add into the DESCRIPTION clause a definition for each enum (an example would be MplsLspType in RFC3811). From owner-ccamp@ops.ietf.org Fri Sep 23 16:01:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EItjH-0006K2-78 for ccamp-archive@megatron.ietf.org; Fri, 23 Sep 2005 16:01:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05042 for ; Fri, 23 Sep 2005 16:01:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EItpl-0007uJ-9S for ccamp-archive@ietf.org; Fri, 23 Sep 2005 16:07:50 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EItYi-0001ya-JQ for ccamp-data@psg.com; Fri, 23 Sep 2005 19:50:12 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EItYh-0001yL-Th for ccamp@ops.ietf.org; Fri, 23 Sep 2005 19:50:12 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EItYX-0002ha-MK; Fri, 23 Sep 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt Message-Id: Date: Fri, 23 Sep 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --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 : Label Switched Path Stitching with Generalized MPLS Traffic Engineering Author(s) : A. Ayyangar, J. Vasseur Filename : draft-ietf-ccamp-lsp-stitching-02.txt Pages : 19 Date : 2005-9-23 In certain scenarios, there may be a need to combine together different Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that in the data plane, a single end-to- end (e2e) LSP is realized and all traffic from one LSP is switched onto the other LSP. We will refer to this as "LSP stitching". This document covers cases where: a) the node performing the stitching does not require configuration of every LSP pair to be stitched together b) the node performing the stitching is not the egress of any of the LSPs c) LSP stitching not only results in an end-to-end LSP in the data plane, but there is also a corresponding end-to-end LSP (RSVP session) in the control plane. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever, completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lsp-stitching-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-lsp-stitching-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: <2005-9-23111314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lsp-stitching-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-23111314.I-D@ietf.org> --OtherAccess-- --NextPart-- From 7dequin@a1.net Fri Sep 23 22:13:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIzXT-0003qC-Gz for ccamp-archive@megatron.ietf.org; Fri, 23 Sep 2005 22:13:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28117 for ; Fri, 23 Sep 2005 22:13:17 -0400 (EDT) Received: from [221.228.238.247] (helo=221.228.238.247) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIzdy-0001Oe-8v for ccamp-archive@ietf.org; Fri, 23 Sep 2005 22:20:05 -0400 Message-ID: <1de501c5c0ac$bb9cde7e$6bb78119@a1.net> From: "Jennifer A. Clark" <7dequin@a1.net> To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?QWRvYmUgQ3JlYXRpdmUgU3VpdGUgKDUgQ0QpIC0gdmVyeSBsb3cgcHJpY2U=?= Date: Sat, 24 Sep 2005 02:05:07 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_55CC7DB7.6E7E697A" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.9 (+++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b This is a multi-part message in MIME format. ------=_NextPart_000_0000_55CC7DB7.6E7E697A Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_F07DDA40.A865715D" ------=_NextPart_001_0001_F07DDA40.A865715D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get all the popular software possible for prices substantially lower than in stores! Our software is 2-10 times cheaper than sold by our competitors. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX $149.95 Adobe Creative Suite Premium (5 CD) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special offers: $89.95 Windows XP Pro + Office XP Pro $129.95 Photoshop 7 + Premiere 7 + Illustrator 10 $109.95 Dreamweaver MX 2004 + Flash MX 2004 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... Go visit us at: http://www.cds-for-you.com Best, Jennifer Clark ________________________________ To be taken out, go here ________________________________ ------=_NextPart_001_0001_F07DDA40.A865715D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get all the popular software possible for prices substantially lower than in stores!
Our software is 2-10 times cheaper than sold by our competitors.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX
$149.95 Adobe Creative Suite Premium (5 CD)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special offers:
$89.95 Windows XP Pro + Office XP Pro
$129.95 Photoshop 7 + Premiere 7 + Illustrator 10
$109.95 Dreamweaver MX 2004 + Flash MX 2004

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... Go visit us at:

http://www.cds-for-you.com

Best,
Jennifer Clark


________________________________
To be taken out, go here
________________________________

------=_NextPart_001_0001_F07DDA40.A865715D-- ------=_NextPart_000_0000_55CC7DB7.6E7E697A-- From owner-ccamp@ops.ietf.org Sat Sep 24 06:45:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ7XV-0003Qj-4y for ccamp-archive@megatron.ietf.org; Sat, 24 Sep 2005 06:45:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29658 for ; Sat, 24 Sep 2005 06:45:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJ7dw-0003Tn-BH for ccamp-archive@ietf.org; Sat, 24 Sep 2005 06:52:44 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EJ7K6-0005my-VP for ccamp-data@psg.com; Sat, 24 Sep 2005 10:32:02 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EJ7K3-0005mg-27 for ccamp@ops.ietf.org; Sat, 24 Sep 2005 10:31:59 +0000 Received: from du-069-0171.access.clara.net ([217.158.132.171] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1EJ7Jt-00025A-6l; Sat, 24 Sep 2005 11:31:57 +0100 Message-ID: <141f01c5c0f3$90e2b650$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , References: <3.0.1.32.20050908213717.014708c8@pop.mindspring.com> <3.0.1.32.20050923120504.01564e90@pop.mindspring.com> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Sat, 24 Sep 2005 11:02:24 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_13F6_01C5C0F7.717C8C10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.9 (/) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 This is a multi-part message in MIME format. ------=_NextPart_000_13F6_01C5C0F7.717C8C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joan, Thanks for the rapid convergence. In-line... Cheers, Adrian > >> 3*) Question if these documents should have a > >> contributors section. It violates the guidelines > >> of "RFC Editorial Guidelines and Procedures" > >> http://www.rfc-editor.org/policy.html#policy.auth2 > >> > >> There are many people listed under > >> Authors but not listed on the front page, > >> so how about adding a Contributors Section? > > > >Ack > >We will change the title of "Authors' Addresses" section to be = "Contact > >Details". >=20 > According to the rfc-editor website above, > this should be "Contact Information", is this what you mean? Yes, in deed. And Henrick's little tool catches this admirably. > >> draft-ietf-ccamp-gmpls-tc-mib-07.txt > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> Section 3. GMPLS Textual Conventions MIB Definitions > >> --------------------------------------------------- >=20 > >> 1) GmplsFreeformLabel TC >=20 > >> 1c) The DESCRIPTION needs a little work: > >> DESCRIPTION > >> "This value represents a freeform generalized MPLS Label. = This > >> can be used to represent label types which are not standard = in > >> the drafts. It may also be used by systems that do not wish = to > >> represent the labels using the specific label types." > >> > >> Please reword to something like: > >> > >> "This value represents a freeform GMPLS label. A freeform = GMPLS > >> label is specified by the system which uses it. In other = words, > >> the freeform GMPLS label is not a standard GMPLS label type, > >> but is created by the system which uses it." > > > >Nack > >The text as originally stated is correct and your revision is wrong. = That > >is, the freeform label MAY also be used to represent standard labels > >as octet strings. > >This is a popular way to handle the management of multiple different = types > >of labels. > > > >Will change to: > > "This value represents a freeform GMPLS Label. This can be = used > > to represent label that have label types which are not > > standardised. It may also be used by systems that do not = wish to=20 > > represent labels that have standardised label types using = the=20 > > type-specific objects in this table." >=20 > Sorry, I'm still a little foggy on what this TC is, partly because the > description is referring to "objects in this table" which is confusing > in a TC DESCRIPTION, and also the definition of the freeform label > used here and used in the GmplsGeneralizedLabelType enum seems be > defined slightly differently.=20 Good point about "objects in this table." That needs to be removed. So, the description of GmplsGeneralizedLabelTypes should be changed to = read... Determines the interpretation that should be applied to an object that encodes a label. But I don't see anything else in the GmplsGeneralizedLabelType enum that = presents any interpretation of the freeform object. > A freeform label as described in the DESCRIPTION clause > could contain the value of any GMPLS/MPLS labels,=20 > right? Right. How about... "This Textual Convention can be used as the syntax of an object that contains any GMPLS label. Objects with this syntax can be used to represent labels that have label types that are not standardised. The freeform GMPLS Label may also be used by=20 systems that do not wish to represent labels that have standardised label types using type-specific syntaxes." > >> 2) GmplsGeneralizedLabelTypes TC >=20 > >> 2b) Could the SYNTAX order be changed? > >> > >> Currently: > >> > >> SYNTAX INTEGER { > >> gmplsMplsLabel(1), > >> gmplsPortWavelengthLabel(2), > >> gmplsFreeformGeneralizedLabel(3), > >> gmplsSonetLabel(4), > >> gmplsSdhLabel(5), > >> gmplsWavebandLabel(6) > >> } > >> > >> Proposed (NOTE also some of the names have been changed): > >> > >> SYNTAX INTEGER { > >> gmplsFreeformLabelOrOther(1), > >> gmplsMplsLabel(2), > >> gmplsPortAndWavelengthLabel(3), > >> gmplsSonetLabel(4), > >> gmplsSdhLabel(5), > >> gmplsWavebandLabel(6) > >> } > > > >Nack > >i. "FreeformOrOther" What other? There is just freeform. >=20 > Aren't the label types: gmplsMplsLabel(2), > gmplsPortAndWavelengthLabel(3), > gmplsSonetLabel(4), > gmplsSdhLabel(5), > gmplsWavebandLabel(6) > also a kind of freeform GMPLS label (as indicated by the DESCRIPTION > clause in GmplsFreeformLabel)? It is all to do with the encodings of objects (i.e. the syntaxes) not = the use to which the labels can be put. Thus, a normal 20-bit MPLS label = an be encoded in an object with syntax MPLSLabel or in an object with = syntax GMPLSFreeformLabel. In the former case it is presented as an = Unsigned32. In the latter case it is presented as an OCTET STRING. > >ii. Why re-order? The new order seems to have no more logic than the > > old order. >=20 > Partly depends on the answer to above i. question. =20 > If the labels are a kind of freeform label,=20 > then a better style would be to list=20 > gmplsFreeformLabel first. Admittedly, this is a NIT. >=20 > Also, please add into the DESCRIPTION clause > a definition for each enum (an example would > be MplsLspType in RFC3811). =20 Yes. That is a good idea. Description will now read... DESCRIPTION "Determines the interpretation that should be applied to an object that encodes a label. The possible types are: gmplsMplsLabel(1) - The label is an MPLS packet, = cell, or frame label and is encoded as=20 described for the Textual = Convention MPLSLabel defined in RFC 3811. gmplsPortWavelengthLabel(2) - The label is a port or wavelength label as defined in RFC 3741. gmplsFreeformGeneralizedLabel(3) - The label is any form of label = encoded as an OCTET STRING using the = Textual Convention GMPLSFreeformLabel. gmplsSonetLabel(4) - The label is a SONET label as = defined in RFC 3946. gmplsSdhLabel(5) - The label is an SDH label as = defined in RFC 3946. gmplsWavebandLabel(6) - The label is a waveband label as = defined in RFC 3471." ------=_NextPart_000_13F6_01C5C0F7.717C8C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Joan,
 
Thanks for the rapid = convergence.
 
In-line...
 
Cheers,
Adrian
 
> >> 3*) Question if these = documents=20 should have a
> >>    contributors = section.  It=20 violates the guidelines
> >>    of "RFC = Editorial=20 Guidelines and Procedures"
> >>    http://www.rfc-editor.org/policy.html#policy.auth2> >>
> >>    = There are=20 many people listed under
> >>    Authors but = not=20 listed on the front page,
> >>    so how = about adding=20 a Contributors Section?
> >
> >Ack
> >We will = change=20 the title of "Authors' Addresses" section to be "Contact
>=20 >Details".
>
> According to the rfc-editor website=20 above,
> this should be "Contact Information", is this what you=20 mean?
 
Yes, in deed. And Henrick's little = tool catches=20 this admirably.

>=20 >> draft-ietf-ccamp-gmpls-tc-mib-07.txt
> >>=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>
> = >> Section=20 3. GMPLS Textual Conventions MIB Definitions
> >>=20 ---------------------------------------------------
>
> = >> 1)=20 GmplsFreeformLabel TC
>
> >> 1c) The DESCRIPTION = needs a=20 little work:
> >>     = DESCRIPTION
>=20 >>        "This value = represents a=20 freeform generalized MPLS Label. This
>=20 >>         can be used to=20 represent label types which are not standard in
>=20 >>         the drafts. It = may also=20 be used by systems that do not wish to
>=20 >>         represent the = labels=20 using the specific label types."
> >>
>=20 >>      Please reword to something = like:
>=20 >>
> >>       "This = value=20 represents a freeform GMPLS label.  A freeform GMPLS
>=20 >>        label is specified by = the=20 system which uses it.  In other words,
>=20 >>        the freeform GMPLS = label is=20 not a standard GMPLS label type,
>=20 >>        but is created by the = system=20 which uses it."
> >
> >Nack
> >The text as = originally=20 stated is correct and your revision is wrong. That
> = >is, the=20 freeform label MAY also be used to represent standard = labels
> >as octet strings.
> = >This is a=20 popular way to handle the management of multiple different types
> = >of labels.
> >
> >Will change to:
>=20 >        "This value represents a = freeform=20 GMPLS Label. This can be used
>=20 >         to represent label = that=20 have label types which are not
>=20 >         standardised. It = may also=20 be used by systems that do not wish to
>=20 >         represent labels = that have=20 standardised label types using the
>=20 >         type-specific = objects in=20 this table."
>
> Sorry, I'm still a little foggy on what = this TC=20 is, partly because the
> description is referring to "objects in = this=20 table" which is confusing
> in a TC DESCRIPTION, and also the = definition=20 of the freeform label
> used here and used in the=20 GmplsGeneralizedLabelType enum seems be
> defined slightly = differently.=20
 
Good point about "objects in this = table." That=20 needs to be removed.
 
So, the description of = GmplsGeneralizedLabelTypes=20 should be changed to read...
       =20 Determines the interpretation that should be applied to=20 an
        object that encodes a=20 label.
 
But I don't see anything else in the=20 GmplsGeneralizedLabelType enum that presents any interpretation of the = freeform=20 object.

> A freeform label as described in the = DESCRIPTION=20 clause
> could contain the value of any GMPLS/MPLS labels, =
>=20 right?
 
Right.
 
How about...
  "This Textual Convention can = be used as=20 the syntax of an object
   that contains any = GMPLS label.=20 Objects with this syntax can be
   used to represent labels = that have=20 label types that are not
   standardised. The freeform = GMPLS=20 Label may also be used by
   systems that do not wish = to represent labels that = have
   standardised label types = using type-specific=20 syntaxes."
> >> 2) = GmplsGeneralizedLabelTypes =20 TC
>
> >> 2b)  Could the SYNTAX order be=20 changed?
> >>
> >>    =20 Currently:
> >>
> >>     = SYNTAX=20 INTEGER {
> >>       =20 gmplsMplsLabel(1),
> = >>       =20 gmplsPortWavelengthLabel(2),
>=20 >>       =20 gmplsFreeformGeneralizedLabel(3),
>=20 >>        = gmplsSonetLabel(4),
>=20 >>        = gmplsSdhLabel(5),
>=20 >>        = gmplsWavebandLabel(6)
>=20 >>      }
> >>
>=20 >>     Proposed (NOTE also some of the names = have been=20 changed):
> >>
> >>    SYNTAX = INTEGER=20 {
> >>       =20 gmplsFreeformLabelOrOther(1),
>=20 >>        = gmplsMplsLabel(2),
>=20 >>       =20 gmplsPortAndWavelengthLabel(3),
>=20 >>        = gmplsSonetLabel(4),
>=20 >>        = gmplsSdhLabel(5),
>=20 >>        = gmplsWavebandLabel(6)
>=20 >>      }
> >
> = >Nack
>=20 >i.  "FreeformOrOther" What other? There is just = freeform.
>=20
> Aren't the label types: gmplsMplsLabel(2),
>=20 gmplsPortAndWavelengthLabel(3),
> gmplsSonetLabel(4),
>=20 gmplsSdhLabel(5),
> gmplsWavebandLabel(6)
> also a kind of = freeform=20 GMPLS label (as indicated by the DESCRIPTION
> clause in=20 GmplsFreeformLabel)?
 
It is all to do with the encodings of = objects=20 (i.e. the syntaxes) not the use to which the labels can be put. Thus, a = normal=20 20-bit MPLS label an be encoded in an object with syntax MPLSLabel or in = an=20 object with syntax GMPLSFreeformLabel. In the former case it is = presented as an=20 Unsigned32. In the latter case it is presented as an OCTET = STRING.
 
> >ii. Why re-order? The new = order seems to=20 have no more logic than the
> >    old = order.
>=20
> Partly depends on the answer to above i. question.  =
> If=20 the labels are a kind of freeform label,
> then a better style = would be=20 to list
> gmplsFreeformLabel first.  Admittedly, this is a=20 NIT.
>
> Also, please add into the DESCRIPTION = clause
> a=20 definition for each enum (an example would
> be MplsLspType in=20 RFC3811). 
 
Yes. That is a good = idea.
 
Description will now = read...
 
 DESCRIPTION
   "Determines the = interpretation=20 that should be applied to an
    object that = encodes a=20 label. The possible types are:
 
      =20     gmplsMplsLabel(1)    =20     - The label is an MPLS packet, cell,
           &n= bsp;           &nb= sp;           &nbs= p; =20  or frame label and is encoded as
           &n= bsp;           &nb= sp;           &nbs= p;  =20 described for the Textual Convention
           &n= bsp;           &nb= sp;           &nbs= p; =20  MPLSLabel defined in RFC 3811.

   =20 gmplsPortWavelengthLabel(2)      - The label is = a port=20 or wavelength
           &n= bsp;           &nb= sp;           &nbs= p; =20  label as defined in RFC 3741.
 
    gmplsFreeformGeneralizedLabel(3) - The label is = any form=20 of label encoded
           &n= bsp;           &nb= sp;           &nbs= p;   as=20 an OCTET STRING using the Textual
           &n= bsp;           &nb= sp;           &nbs= p;  =20 Convention GMPLSFreeformLabel.

   =20 gmplsSonetLabel(4)         &= nbsp;    =20 - The label is a SONET label as defined
           &n= bsp;           &nb= sp;           &nbs= p;   in=20 RFC 3946.
   =20 gmplsSdhLabel(5)         &nb= sp;      =20 - The label is an SDH label as defined in
           &n= bsp;           &nb= sp;           &nbs= p;  =20 RFC 3946.

   =20 gmplsWavebandLabel(6)        &nbs= p;  =20 - The label is a waveband label as defined
           &n= bsp;           &nb= sp;           &nbs= p;  =20 in RFC 3471."
 
------=_NextPart_000_13F6_01C5C0F7.717C8C10-- From NicolePadilla@cable-descramblers-rftplus.com Sun Sep 25 02:43:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJQEd-0005YF-Fz for ccamp-archive@megatron.ietf.org; Sun, 25 Sep 2005 02:43:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26072 for ; Sun, 25 Sep 2005 02:43:37 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJQLP-0001Ny-Dj for ccamp-archive@ietf.org; Sun, 25 Sep 2005 02:50:41 -0400 Received: from cm45.theta6.maxonline.com.sg ([222.165.6.45]) by mx2.foretec.com with smtp (Exim 4.24) id 1EJQE7-00068p-HD for ccamp-archive@ietf.org; Sun, 25 Sep 2005 02:43:11 -0400 Received: from 9MNV@localhost by SW5g.int (8.11.6/8.11.6); Sun, 25 Sep 2005 02:58:05 -0400 Message-ID: From: "Erica Nguyen" Reply-To: "Erica Nguyen" To: ccamp-archive@ietf.org Subject: Out of this WoRLD $aving$ on all MS 2003 titles Date: Sun, 25 Sep 2005 08:57:05 +0200 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: NicolePadilla@cable-descramblers-rftplus.com Content-Type: multipart/mixed; boundary="--Bx3KI8V37mvoPTVtcj" X-Spam-Score: 0.3 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 CMD ----Bx3KI8V37mvoPTVtcj Content-Type: text/html; Content-Transfer-Encoding: quoted-printable g
Opt-in Email Special Offer   = ;  unsubscribe me
SEARCH

TOP 10 NEW TITLES

  

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Ad= obe Photoshop 9.0
 3 Wi= ndows XP Pro
 4 Adobe= Acrobat 7 Pro
 5 Flash= MX 2004
 6 Corel Dr= aw 12
 7 Norton Antiv= irus 2005
 <= font face=3DVerdana size=3D1>8 Windows= 2003 Server
 9 Alias= Maya 6 Wavefrt
 10 = Adobe Illustrator 11
  See more by this manufacturer
   Microsoft
  = Symantec
   Adobe
  Custom= ers also bought
  these other items...

Micro= soft Office Professional Edition *2003*
Microsoft

= <= tr>
Choose:
 

You Save:



Availability: Available for INSTANT down= load!
Coupon Code: OgrSETY
 

Sales Rank: #1
System requirements  |  Other Versions
Date= Coupon Expires: August 31st, 2005
Av= erage Customer Review:3D"5 Based on 18117 reviews. Write a review.

=
List Price:$499.00
Price:$69.99
$429.01 (86%)

Adobe Photoshop CS2 V = 9.0
Adobe

Choose:<= td width=3D126>
 

<= td height=3D18 width=3D11>
List Price:$599.00
Price:<= b class=3Dprice>$69.99
You Save:$529.01 (90%)



Av= ailability: Available for INSTANT download!
Coupon Code: qr= ZOU5
 

Sales Rank: #2
= System requi= rements  |  Other Version= s
Date Coupon Expires: August 31s= t, 2005
Average Customer Review:3D"5 Based on 16816 reviews. Write a revi= ew.

Microsoft Windows XP Professional or Lo= nghorn Edition
Microsoft

Choose:
 

=

List Price:$279.00
Price:$49.99
You Save= :$229.01 (85%)



Availability: Available for INSTANT download!
<= b>Coupon Code: 5m0ec
 

Sal= es Rank: #3
System requirements  |  Other Versions
Date Coupon Exp= ires: August 31st, 2005
Average Custo= mer Review:3D"5 Based on 1296 reviews. Write a review.

Adobe Acrobat Profe= ssional V 7.0
Adobe
Choose:
 

List Price:$499.00
Price:$69.99
You Save:$429.01 (85%)



A= vailability: Available for INSTANT download!
Coupon Code: e= BHHsUuM
 

Sales Rank: #4
System re= quirements  |  Other Vers= ions
Date Coupon Expires: August = 31st, 2005
Average Customer Review: Based on 134158 reviews. Write a= review.

----Bx3KI8V37mvoPTVtcj-- From owner-ccamp@ops.ietf.org Sun Sep 25 17:25:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJdzc-0007r3-Sf for ccamp-archive@megatron.ietf.org; Sun, 25 Sep 2005 17:25:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03867 for ; Sun, 25 Sep 2005 17:25:02 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJe6T-0000FS-Ny for ccamp-archive@ietf.org; Sun, 25 Sep 2005 17:32:14 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EJdpP-000Ors-Ea for ccamp-data@psg.com; Sun, 25 Sep 2005 21:14:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EJdpO-000OrG-Jn for ccamp@ops.ietf.org; Sun, 25 Sep 2005 21:14:30 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8PLDdxp009995; Sun, 25 Sep 2005 16:13:40 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sun, 25 Sep 2005 23:13:38 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508234609@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Adrian Farrel , tnadeau@cisco.com, ccamp@ops.ietf.org, jcucchiara@mindspring.com Subject: RE: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Sun, 25 Sep 2005 23:13:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db W.r.t. > >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > > > >Please change the name to: gmplsLabelModuleReadOnlyCompliance > >to be consistent with the other MPLS and GMPLS MIB modules. > > Nack > I thought we tried to keep names down to 32 characters. I recall this > conversation before. Not mandatory, but desirable. > The "rule" of less than 32 has long ago been relaxed. I personally feel it is more important to be consistent in naming than having less than 32 chars. See RFC4181 sect 4.2 But I agree it is not a fatal flaw, so we won't block on it. > A choice between two desires? > > >41) The ReadOnly compliance for gmplsLabelRowStatus > >does NOT have a MIN-ACCESS of read-only. Is this > >intentional? > > ??? > Not sure about this. > I thought the present of a WRITE-SYNTAX made some difference. > If you have a MODULE-COMPLIANCE statement as you do: gmplsLabelModuleROCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for GMPLS-LABEL-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB modules." So both the descriptor and the DESCRIPTION state that this is for read-only support, then it feels VERY WEIRD to me (actually it feels BROKEN to me) to not have all RowStatus objects be listed with MIN-ACCESS read-only. And having a WRITE-SYNTAX feels similarly weird. > >42) Also, (related to the above) > > OBJECT gmplsLabelRowStatus > > SYNTAX RowStatus { > > active(1), > > notInService(2) > > } > > > > WRITE-SYNTAX RowStatus { > > active(1), > > notInService(2), > > createAndGo(4), > > destroy(6) > > } > > DESCRIPTION > > "Support for notInService, createAndWait and notReady is not > > required." > > > >The DESCRIPTION clause conflicts with the WRITE-SYNTAX. > >Please clarify the intentions for this ReadOnly compliance > >object. > > Ack > There is an error here. > See my comment above. I think it should be MIN-ACCESS read-only and SYNTAX { active }. I do not see any other status to make sense. > >Section 12.2 Informational References > >--------------------------------------- > > > >43a) The title of this section should be > >Informative. > > Ack/Nack > > I am aware of the RFC Editor's preferences. > Unfortunately these references are only informative if you read an > understand them (and > even then not always :-), but they are informational even if you don't > read or > understand them. > I know that RFC-editor uses a tool that prefers "informative". But it is probably not mandatory. Bert From owner-ccamp@ops.ietf.org Sun Sep 25 19:16:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJfiV-000588-Qr for ccamp-archive@megatron.ietf.org; Sun, 25 Sep 2005 19:16:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08983 for ; Sun, 25 Sep 2005 19:15:20 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJfpG-0002Sw-9r for ccamp-archive@ietf.org; Sun, 25 Sep 2005 19:22:33 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EJfZL-0006iv-4e for ccamp-data@psg.com; Sun, 25 Sep 2005 23:06:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-5.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EJfZE-0006hl-Dy; Sun, 25 Sep 2005 23:05:58 +0000 Message-ID: <43372D62.5010501@psg.com> Date: Mon, 26 Sep 2005 01:06:10 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: inter-domain framework Content-Type: multipart/mixed; boundary="------------020900020408000800080201" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ad5310d4a40550521c18cacd3b6e7111 This is a multi-part message in MIME format. --------------020900020408000800080201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian scanning section 2.3 on LSP stitching and in particular the following part of it "LSP stitching can be used in support of inter-domain TE LSPs. In particular, an LSP segment may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the LSP segment could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain." i came with the following question why the LSP tail-end can not terminate on a node outside of the head-end domain ? the definition as it reads to me precludes to stitch an inter-area LSP segment (starting/ ending at the ingress/egress node of an AS) as part of an inter-AS LSP segment for instance; this case does not seem to be covered and i fail to see what specifically forbids such construction ... in case of agreement, i would be please to provide the appropriate piece of text note: modelling LSP segment as TE link is a consequence of establishing them (as currently stated) within a single TE domain but there is no apparent reason why further use of LSP segment must be restricted now on to such construction --------------020900020408000800080201 Content-Type: text/plain; charset=UTF-8; name="www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-04.txt" Content-Disposition: inline; filename="www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-04.txt" Content-Transfer-Encoding: 7bit Network Working Group Adrian Farrel IETF Internet Draft Olddog Consulting Proposed Status: Informational Expires: January 2006 Jean-Philippe Vasseur Cisco Systems, Inc. Arthi Ayyangar Juniper Networks July 2005 A Framework for Inter-Domain MPLS Traffic Engineering draft-ietf-ccamp-inter-domain-framework-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Farrel, Vasseur and Ayyangar Page 1 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 Contents 1. Introduction ............................................... 3 1.1. Nested Domains ......................................... 3 1.2. Conventions used in this document ...................... 4 2. Signaling Options .......................................... 4 2.1. LSP Nesting ............................................ 4 2.2. Contiguous LSP ......................................... 5 2.3. LSP Stitching .......................................... 5 2.4. Hybrid Methods ......................................... 6 2.5. Control of Downstream Choice of Signaling Method ....... 6 3. Path Computation Techniques ................................ 6 3.1. Management Configuration ............................... 7 3.2. Head End Computation ................................... 7 3.2.1. Multi-Domain Visibility Computation ................ 7 3.2.2. Partial Visibility Computation ..................... 7 3.2.3. Local Domain Visibility Computation ................ 8 3.3. Domain Boundary Computation ............................ 8 3.4. Path Computation Element ............................... 9 3.4.1. Multi-Domain Visibility Computation ................ 9 3.4.2. Path Computation Use of PCE When Preserving Confidentiality ................................... 10 3.4.3. Per-Domain Computation Servers .................... 10 3.5. Optimal Path Computation .............................. 10 4. Distributing Reachability and TE Information .............. 11 5. Comments on Advanced Functions ............................ 12 5.1. LSP Re-Optimization ................................... 12 5.2. LSP Setup Failure ..................................... 13 5.3. LSP Repair ............................................ 13 5.4. Fast Reroute .......................................... 14 5.5. Comments on Path Diversity ............................ 15 5.6. Domain-Specific Constraints ........................... 15 5.7. Policy Control ........................................ 16 5.8. Inter-domain OAM ...................................... 16 5.9. Point-to-Multipoint ................................... 16 5.10. Applicability to Non-Packet Technologies ............. 17 6. Security Considerations ................................... 17 7. IANA Considerations ....................................... 17 8. Acknowledgements .......................................... 17 9. Intellectual Property Considerations ...................... 17 10. Normative References ..................................... 18 11. Informational References ................................. 18 12. Authors' Addresses ....................................... 20 13. Full Copyright Statement ................................. 20 Farrel, Vasseur and Ayyangar Page 2 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 1. Introduction The Traffic Engineering Working Group has developed requirements for inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and [INTER-AS]. Various proposals have subsequently been made to address some or all of these requirements through extensions to the RSVP-TE and IGP (ISIS, OSPF) protocols and procedures. This document introduces the techniques for establishing Traffic Engineered (TE) Label Switched Paths (LSPs) across multiple domains. In this context and within the remainder of this document, we consider all source-based and constraint-based routed LSPs and refer to them interchangeably as "TE LSPs" or "LSPs". The functional components of these techniques are separated into the mechanisms for discovering reachability and TE information, for computing the paths of LSPs, and for signaling the LSPs. Note that the aim of this document is not to detail each of those techniques which are covered in separate documents referenced from the sections of this document that introduce the techniques, but rather to propose a framework for inter-domain MPLS Traffic Engineering. Note that in the remainder of this document, the term "MPLS Traffic Engineering" is used equally to apply to MPLS and GMPLS traffic. Specific issues pertaining to the use of GMPLS in inter-domain environments (for example, policy implications of the use of the Link Management Protocol [LMP] on inter-domain links) these are covered in separate documents such as [GMPLS-AS]. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Wholly or partially overlapping domains (e.g. path computation sub-domains of areas or ASs) are not within the scope of this document. 1.1. Nested Domains Nested domains are outside the scope of this document. It may be that some domains that are nested administratively or for the purposes of address space management can be considered as adjacent domains for the purposes of this document, however the fact that the domains are nested is then immaterial. In the context of MPLS TE, domain A is considered to be nested within domain B if domain A is wholly contained in Domain B, and domain B is fully or partially aware of the TE characteristics and topology of domain A. Farrel, Vasseur and Ayyangar Page 3 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 1.2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Signaling Options Three distinct options for signaling TE LSPs across multiple domains are identified. The choice of which options to use may be influenced by the path computation technique used (see section 3), although some path computation techniques may apply to multiple signaling options. The choice may further depend on the application to which the TE LSPs are put and the nature, topology and switching capabilities of the network. A comparison of the usages of the different signaling options is beyond the scope of this document and should be the subject of a separate applicability statement. 2.1. LSP Nesting Hierarchical LSPs form a fundamental part of MPLS [RFC3031] and are discussed in further detail in [HIER]. Hierarchical LSPs may optionally be advertised as TE links. Note that a hierarchical LSP that spans multiple domains cannot be advertised in this way because there is no concept of TE information that spans domains. Hierarchical LSPs can be used in support of inter-domain TE LSPs. In particular, a hierarchical LSP may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the hierarchical LSP could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain. The technique of carrying one TE LSP within another is termed LSP nesting. A hierarchical LSP may provide a TE LSP tunnel to transport (i.e. nest) multiple TE LSPs along a common part of their paths. Alternatively, a TE LSP may carry (i.e. nest) a single LSP in a one-to-one mapping. The signaling trigger for the establishment of a hierarchical LSP may be the receipt of a signaling request for the TE LSP that it will carry, or may be a management action to "pre-engineer" a domain to be crossed by TE LSPs that would be used as hierarchical LSPs by the traffic that has to traverse the domain. Furthermore, the mapping (inheritance rules) between attributes of the nested and the hierarchical LSPs (including bandwidth) may be statically pre-configured or, for on-demand hierarchical LSPs, may be dynamic according to the properties of the nested LSPs. Even in the dynamic case inheritance from the properties of the nested LSP(s) can be Farrel, Vasseur and Ayyangar Page 4 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 complemented by local or domain-wide policy rules. Note that a hierarchical LSP may be constructed to span multiple domains or parts of domains. However, such an LSP cannot be advertised as a TE link that spans domains. The end points of a hierarchical LSP are not necessarily on domain boundaries, so nesting is not limited to domain boundaries. Note also that the IGP/EGP routing topology is maintained unaffected by the LSP connectivity and TE links introduced by hierarchical LSPs even if they are advertised as TE links. That is, the routing protocols do not exchange messages over the hierarchical LSPs, and LSPs are not used to create routing adjacencies between routers. During the operation of establishing a nested LSP that uses a hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain unchanged along the entire length of the nested LSP, as do all other objects that have end-to-end significance. 2.2. Contiguous LSP A single contiguous LSP is established from ingress to egress in a single signaling exchange. No further LSPs are required to be established to support this LSP so that hierarchical or stitched LSPs are not needed. A contiguous LSP uses the same Session/LSP ID along the whole of its path (that is, at each LSR). The notions of "splicing" together different LSPs, or of "shuffling" Session or LSP identifiers is not considered. 2.3. LSP Stitching LSP Stitching is described in [STITCH]. In the LSP stitching model separate LSPs (referred to as a TE LSP segments) are established and are "stitched" together in the data plane so that a single end-to-end label switched path is achieved. The distinction is that the component LSP segments are signaled as distinct TE LSPs in the control plane. Each signaled TE LSP segment has a different source and destination. LSP stitching can be used in support of inter-domain TE LSPs. In particular, an LSP segment may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the LSP segment could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain. Farrel, Vasseur and Ayyangar Page 5 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 The signaling trigger for the establishment of a TE LSP segment may be the establishment of the previous TE LSP segment, the receipt of a setup request for TE LSP that it plans to stitch to a local TE LSP segment, or may be a management action. LSP segments may be managed and advertised as TE links. 2.4. Hybrid Methods There is nothing to prevent the mixture of signaling methods described above when establishing a single, end-to-end, inter-domain TE LSP. It may be desirable in this case for the choice of the various methods to be reported along the path, perhaps through the RRO. If there is a desire to restrict which methods are used, this MUST be signaled as described in the next section. 2.5. Control of Downstream Choice of Signaling Method Notwithstanding the previous section, an ingress LSR MAY wish to restrict the signaling methods applied to a particular LSP at domain boundaries across the network. Such control, where it is required, may be achieved by the definition of appropriate new flags in the SESSION-ATTRIBUTE object or the Attributes Flags TLV of the LSP_ATTRIBUTES object [ATTRIB]. Before defining a mechanism to provide this level of control, the functional requirement to control the way in which the network delivers a service must be established and due consideration must be given to the impact on interoperability since new mechanisms must be backwards compatible, and care must be taken to avoid allowing standards-conformant implementations each supporting a different functional subset such that they are not capable of estbalishing LSPs. 3. Path Computation Techniques The discussion of path computation techniques within this document is limited significantly to the determination of where computation may take place and what components of the full path may be determined. The techniques used are closely tied to the signaling methodologies described in the previous section in that certain computation techniques may require the use of particular signaling approaches and vice versa. Any discussion of the appropriateness of a particular path computation technique in any given circumstance is beyond the scope of this document and should be described in a separate applicability statement. Path computation algorithms are firmly out of scope of this document. Farrel, Vasseur and Ayyangar Page 6 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 3.1. Management Configuration Path computation may be performed by offline tools or by a network planner. The resultant path may be supplied to the ingress LSR as part of the TE LSP or service request, and encoded by the ingress LSR as an ERO on the Path message that is sent out. There is no reason why the path provided by the operator should not span multiple domains if the relevant information is available to the planner or the offline tool. The definition of what information is needed to perform this operation and how that information is gathered, is outside the scope of this document. 3.2. Head End Computation The head end, or ingress, LSR may assume responsibility for path computation when the operator supplies part or none of the explicit path. The operator MUST, in any case, supply at least the destination address (egress) of the LSP. 3.2.1. Multi-Domain Visibility Computation If the ingress has sufficient visibility of the topology and TE information for all of the domains across which it will route the LSP to its destination then it may compute and provide the entire path. The quality of this path (that is, its optimality as discussed in section 3.5) can be better if the ingress has full visibility into all relevant domains rather than just sufficient visibility to provide some path to the destination. Extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4. 3.2.2. Partial Visibility Computation It may be that the ingress does not have full visibility of the topology of all domains, but does have information about the connectedness of the domains and the TE resource availability across the domains. In this case, the ingress is not able to provide a fully specified strict explicit path from ingress to egress. However, for example, the ingress might supply an explicit path that comprises: - explicit hops from ingress to the local domain boundary - loose hops representing the domain entry points across the network - a loose hop identifying the egress. Alternatively, the explicit path might be expressed as: - explicit hops from ingress to the local domain boundary - strict hops giving abstract nodes representing each domain in turn - a loose hop identifying the egress. Farrel, Vasseur and Ayyangar Page 7 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 These two explicit path formats could be mixed according to the information available resulting in different combinations of loose hops and abstract nodes. This form of explicit path relies on some further computation technique being applied at the domain boundaries. See section 3.3. As with the multi-domain visibility option, extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4. 3.2.3. Local Domain Visibility Computation A final possibility for ingress-based computation is that the ingress LSR has visibility only within its own domain, and connectivity information only as far as determining one or more domain exit points that may be suitable for carrying the LSP to its egress. In this case the ingress builds an explicit path that comprises just: - explicit hops from ingress to the local domain boundary - a loose hop identifying the egress. 3.3. Domain Boundary Computation If the partial explicit path methods described in sections 3.2.2 or 3.2.3 are applied then the LSR at each domain boundary is responsible for ensuring that there is sufficient path information added to the Path message to carry it at least to the next domain boundary (that is, out of the new domain). If the LSR at the domain boundary has full visibility to the egress then it can supply the entire explicit path. Note however, that the ERO processing rules of [RFC3209] state that it SHOULD only update the ERO as far as the next specified hop (that is, the next domain boundary if one was supplied in the original ERO) and, of course, MUST NOT insert ERO subobjects immediately before a strict hop. If the LSR at the domain boundary has only partial visibility (using the definitions of section 3.2.2) it will fill in the path as far as the next domain boundary, and will supply further domain/domain boundary information if not already present in the ERO. If the LSR at the domain boundary has only local visibility into the immediate domain it will simply add information to the ERO to carry the Path message as far as the next domain boundary. Domain boundary path computations are performed independently from each other. Domain boundary LSRs may have different computation capabilities, run different path computation algorithms, apply different sets of constraints and optimization criteria, and so forth, which might result in path segment quality which is Farrel, Vasseur and Ayyangar Page 8 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 unpredictable to and out of the control of the ingress LSR. A solution to this issue lies in enhancing the informaiton signaled during LSP setup to include a larger set of constraints and to include the paths of related LSPs (such as diverse protected LSPs) as described in [GMPLS-E2E]. It is also the case that paths generated on domain boundaries may produce loops. Specifically, the paths computed may loop back into a domain that has already been crossed by the LSP. This may, or may not be a problem, and might even be desirable, but could also give rise to real loops. This can be avoided by using the recorded route (RRO) to provide exclusions within the path computation algorithm, but in the case of lack of trust between domains it may be necessary for the RRO to indicate the previously visited domains. Even this solution is not available where the RRO is not available on a Path message. Note that when an RRO is used to provide exclusions, and a loop-free path is found to be not available by the computation at a downstream border node, crankback [CRANKBACK] may enable an upstream border node to select an alternate path. 3.4. Path Computation Element The computation techniques in sections 3.2 and 3.3 rely on topology and TE information being distributed to the ingress LSR and those LSRs at domain boundaries. These LSRs are responsible for computing paths. Note that there may be scaling concerns with distributing the required information - see section 4. An alternative technique places the responsibility for path computation with a Path Computation Element (PCE) [PCE]. There may be either a centralized PCE, or multiple PCEs (each having local visibility and collaborating in a distributed fashion to compute an end-to-end path) across the entire network and even within any one domain. The PCE may collect topology and TE information from the same sources as would be used by LSRs in the previous paragraph, or though other means. Each LSR called upon to perform path computation (and even the offline management tools described in section 3.1) may abdicate the task to a PCE of its choice. The selection of PCE(s) may be driven by static configuration or the dynamic discovery. 3.4.1. Multi-Domain Visibility Computation A PCE may have full visibility, perhaps through connectivity to multiple domains. In this case it is able to supply a full explicit path as in section 3.2.1. Farrel, Vasseur and Ayyangar Page 9 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 3.4.2. Path Computation Use of PCE When Preserving Confidentiality Note that although a centralized PCE or multiple collaborative PCEs may have full visibility into one or more domains, it may be desirable (e.g to preserve confidentiality) that the full path is not provided to the ingress LSR. Instead, a partial path is supplied (as in section 3.2.2 or 3.2.3) and the LSRs at each domain boundary are required to make further requests for each successive segment of the path. In this way an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute each leg of the path on each request or at regular intervals until requested by the LSRs establishing the LSP. It may be the case that the centralized PCE or the collaboration between PCEs may define a trust relationship greater than that normally operational between domains. 3.4.3. Per-Domain Computation Elements A third way that PCEs may be used is simply to have one (or more) per domain. Each LSR within a domain that wishes to derive a path across the domain may consult its local PCE. This mechanism could be used for all path computations within the domain, or specifically limited to computations for LSPs that will leave the domain where external connectivity information can then be restricted to just the PCE. 3.5. Optimal Path Computation There are many definitions of an optimal path depending on the constraints applied to the path computation. In a multi-domain environment the definitions are multiplied so that an optimal route might be defined as the route that would be computed in the absence of domain boundaries. Alternatively, another constraint might be applied to the path computation to reduce or limit the number of domains crossed by the LSP. It is easy to construct examples that show that partitioning a network into domains, and the resulting loss or aggregation of routing information may lead to the computation of routes that are other than optimal. It is impossible to guarantee optimal routing in the presence of aggregation / abstraction / summarization of routing information. It is beyond the scope of this document to define what is an optimum path for an inter-domain TE LSP. This debate is abdicated in favor of Farrel, Vasseur and Ayyangar Page 10 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 requirements documents and applicability statements for specific deployment scenarios. Note, however, that the meaning of certain computation metrics may differ between domains (see section 5.6). 4. Distributing Reachability and TE Information Traffic Engineering information is collected into a TE Database (TED) on which path computation algorithms operate either directly or by first constructing a network graph. The path computation techniques described in the previous section make certain demands upon the distribution of reachability information and the TE capabilities of nodes and links within domains as well as the TE connectivity across domains. Currently, TE information is distributed within domains by additions to IGPs [RFC3630], [RFC3784]. In cases where two domains are interconnected by one or more links (that is, the domain boundary falls on a link rather than on a node), there SHOULD be a mechanism to distribute the TE information associated with the inter-domain links to the corresponding domains. This would facilitate better path computation and reduce TE-related crankbacks on these links. Where a domain is a subset of an IGP area, filtering of TE information may be applied at the domain boundary. This filtering may be one way, or two way. Where information needs to reach a PCE that spans multiple domains, the PCE may snoop on the IGP traffic in each domain, or play an active part as an IGP-capable node in each domain. The PCE might also receive TED updates from a proxy within the domain. It could be possible that an LSR that performs path computation (for example, an ingress LSR) obtains the topology and TE information of not just its own domain, but other domains as well. This information may be subject to filtering applied by the advertising domain (for example, the information may be limited to FAs across other domains, or the information may be aggregated or abstracted). Before starting work on any protocols or protocol extensions to enable cross-domain reachability and TE advertisement in support of inter-domain TE, the requirements and and benefits must be clearly established. This has not been done to date. Where any cross-domain reachability and TE information needs to be advertised, consideration must be given to TE extensions to existing protocols such as BGP, and how the information advertised may be fed to the IGPs. It must be noted that any extensions that cause a significant increase in the amount of processing (such as aggregation computation) at domain boundaries, or a significant increase in the amount of information Farrel, Vasseur and Ayyangar Page 11 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 flooded (such as detailed TE information) need to be treated with extreme caution and compared carefully with the scaling requirements expressed in [INTER-AREA] and [INTER-AS]. 5. Comments on Advanced Functions This section provides some non-definitive comments on the constraints placed on advanced MPLS TE functions by inter-domain MPLS. It does not attempt to state the implications of using one inter-domain technique or another. Such material is deferred to appropriate applicability statements where statements about the capabilities of existing or future signaling, routing and computation techniques to deliver the functions listed should be made. 5.1. LSP Re-Optimization Re-optimization is the process of moving a TE LSP from one path to another, more preferable path (where no attempt is made in this document to define "preferable" as no attempt was made to define "optimal"). Make-before-break techniques are usually applied to ensure that traffic is disrupted as little as possible. The Shared Explicit style is usually used to avoid double booking of network resources. Re-optimization may be available within a single domain. Alternatively, re-optimization may involve a change in route across several domains or might involve a choice of different transit domains. Re-optimization requires that all or part of the path of the LSP be re-computed. The techniques used may be selected as described in section 3, and this will influence whether the whole or part of the path is re-optimized. The trigger for path computation and re-optimization may be an operator request, a timer, information about a change in availability of network resources, or a change in operational parameters (for example bandwidth) of an LSP. This trigger MUST be applied to the point in the network that requests re-computation and controls re-optimization and may require additional signaling. Note also that where multiple mutually-diverse paths are applied end-to-end (i.e. not simply within protection domains - see section 5.5) the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting re-optimization of any one path. Mutual diversity here means that a set of computed paths have no commonality. Such diversity might be link, node, SRLG or even domain disjointedness according to circumstances and the service being delivered. Farrel, Vasseur and Ayyangar Page 12 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 It may be the case that re-optimization is best achieved by recomputing the paths of multiple LSPs at once. Indeed, this can be shown to be most efficient when the paths of all LSPs are known, not simply those LSPs that originate at a particular ingress. While this problem is inherited from single domain re-optimization and is out of scope within this document, it should be noted that the problem grows in complexity when LSPs wholly within one domain affect the re-optimization path calculations performed in another domain. 5.2. LSP Setup Failure When an inter-domain LSP setup fails in some domain other than the first, various options are available for reporting and retrying the LSP. In the first instance, a retry may be attempted within the domain that contains the failure. That retry may be attempted by nodes wholly within the domain, or the failure may be referred back to the LSR at the domain boundary. If the failure cannot be bypassed within the domain where the failure occurred (perhaps there is no suitable alternate route, perhaps rerouting is not allowed by domain policy, or perhaps the Path message specifically bans such action), the error MUST be reported back to the previous or head-end domain. Subsequent repair attempts may be made by domains further upstream, but will only be properly effective if sufficient information about the failure and other failed repair attempts is also passed back upstream [CRANKBACK]. Note that there is a tension between this requirement and that of confidentiality although crankback aggregation may be applicable at domain boundaries. Further attempts to signal the failed LSP may apply the information about the failures as constraints to path computation, or may signal them as specific path exclusions [EXCLUDE]. When requested by signaling, the failure may also be systematically reported to the head-end LSR. 5.3. LSP Repair An LSP that fails after it has been established may be repaired dynamically by re-routing. The behavior in this case is either like that for re-optimization, or for handling setup failures (see previous two sections). Fast Reroute may also be used (see below). Farrel, Vasseur and Ayyangar Page 13 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 5.4. Fast Reroute MPLS Traffic Engineering Fast Reroute ([FRR]) defines local protection schemes intended to provide fast recovery (in 10s of msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node failure. A backup TE LSP is configured and signaled at each hop, and activated upon detecting or being informed of a network element failure. The node immediately upstream of the failure (called the PLR - Point of Local Repair) reroutes the set of protected TE LSPs onto the appropriate backup tunnel(s) and around the failed resource. In the context of inter-domain TE, there are several different failure scenarios that must be analyzed. Provision of suitable solutions may be further complicated by the fact that [FRR] specifies two distinct modes of operation referred to as the "one to one mode" and the "facility back-up mode". The failure scenarios specific to inter-domain TE are as follows: - Failure of a domain edge node that is present in both domains. There are two sub-cases: - The PLR and the MP are in the same domain - The PLR and the MP are in different domains. - Failure of a domain edge node that is only present in one of the domains. - Failure of an inter-domain link. Although it may be possible to apply the same techniques for FRR to the different methods of signaling inter-domain LSPs described in section 2, the results of protection may be different when it is the boundary nodes that need to be protected, and when they are the ingress and egress of a hierarchical LSP or stitched LSP segment. In particular, the choice of Point of Local Repair (PLR) and Merge Point (MP) may be different, and the length of the protection path may be greater. These use of FRR techniques should be explained further in applicability statements or, in the case of a change in base behavior, in implementation guidelines specific to the signaling techniques. Note that after local repair has been performed, it may be desirable to re-optimize the LSP (see section 5.1). If the point of re-optimization (for example the ingress LSR) lies in a different domain to the failure, it may rely on the delivery of a PathErr or Notify message to inform it of the local repair event. It is important to note that Fast Reroute techniques are only applicable to packet switching networks because other network Farrel, Vasseur and Ayyangar Page 14 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 technologies cannot apply label stacking within the same switching type. Segment protection [SEG-PROT] provides a suitable alternative that is applicable to packet and non-packet networks. 5.5. Comments on Path Diversity Diverse paths may be required in support of load sharing and/or protection. Such diverse paths may be required to be node diverse, link diverse, fully path diverse (that is, link and node diverse), or SRLG diverse. Diverse path computation is a classic problem familiar to all graph theory majors. The problem is compounded when there are areas of "private knowledge" such as when domains do not share topology information. The problem can be resolved more efficiently (e.g. avoiding the "trap problem") when mutually resource disjoint paths can be computed "simultaneously" on the fullest set of information. That being said, various techniques (out of the scope of this document) exist to ensure end-to-end path diversity across multiple domains. Many network technologies utilize "protection domains" because they fit well with the capabilities of the technology. As a result, many domains are operated as protection domains. In this model, protection paths converge at domain boundaries. Note that the question of SRLG identification is not yet fully answered. There are two classes of SRLG: - those that indicate resources that are all contained witin one domain - those that span domains. The former might be identified using a combination of a globally scoped domain ID, and an SRLG ID that is administered by the domain. The latter requires a global scope to the SRLG ID. Both schemes, therefore, require external administration. The former is able to leverage existing domain ID administration (for example, area and AS numbers), but the latter would require a new administrative policy. 5.6. Domain-Specific Constraints While the meaning of certain constraints, like bandwidth, can be assumed to be constant across different domains, other TE constraints (such as resource affinity, color, metric, priority, etc.) may have different meanings in different domains and this may impact the ability to support DiffServ-aware MPLS, or to manage pre-emption. Farrel, Vasseur and Ayyangar Page 15 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 In order to achieve consistent meaning and LSP establishment, this fact must be considered when performing constraint-based path computation or when signaling across domain boundaries. A mapping function can be derived for most constraints based on policy agreements between the Domain administrators. The details of such a mapping function are outside the scope of this document, but it is important to note that the default behavior MUST either be that a constant mapping is applied or that any requirement to apply these constraints across a domain boundary must fail in the absence of explicit mapping rules. 5.7. Policy Control Domain boundaries are natural points for policy control. There is little to add on this subject except to note that a TE LSP that cannot be established on a path through one domain because of a policy applied at the domain boundary, may be satisfactorily established using a path that avoids the demurring domain. In any case, when a TE LSP signaling attempt is rejected due to non-compliance with some policy constraint, this SHOULD be reflected to the ingress LSR. 5.8. Inter-domain OAM Some elements of OAM may be intentionally confined within a domain. Others (such as end-to-end liveness and connectivity testing) clearly need to span the entire multi-domain TE LSP. Where issues of confidentiality are strong, collaboration between PCEs or domain boundary nodes might be required in order to provide end-to-end OAM, and a significant issue to be resolved is to ensure that the end-points support the various OAM capabilities. The different signaling mechanisms described above may need refinements to [LSPPING], and [BFD-MPLS], etc., to gain full end-to-end visibility. These protocols should, however, be considered in the light of confidentiality requirements. Route recording is a commonly used feature of signaling that provides OAM information about the path of an established LSP. When an LSP traverses a domain boundary, the border node may remove or aggregate some of the recorded information for confidentiality or other policy reasons. 5.9. Point-to-Multipoint Inter-domain point-to-multipoint (P2MP) requirements are explicitly out of scope of this document. They may be covered by other documents dependent on the details of MPLS TE P2MP solutions. Farrel, Vasseur and Ayyangar Page 16 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 5.10. Applicability to Non-Packet Technologies Non-packet switching technologies may present particular issues for inter-domain LSPs. While packet switching networks may utilize control planes built on MPLS or GMPLS technology, non-packet networks are limited to GMPLS. On the other hand, some problems such as Fast Re-Route on domain boundaries (see section 5.4) may be handled by the GMPLS technique of segment protection [GMPLS-SEG] that is applicable to both packet and non-packet switching technologies. The specific architectural considerations and requirements for inter-domain LSP setup in non-packet networks are covered in a separate document [GMPLS-AS]. 6. Security Considerations Requirements for security within domains are unchanged from [RFC3209] and [RFC3473], but requirements for inter-domain security are, if anything, more significant. Authentication techniques identified for use with RSVP-TE can only operate across domain boundaries if there is coordination between the administrators of those domains. Confidentiality may also be considered to be security factors. Applicability statements for particular combinations of signaling, routing and path computation techniques are expected to contain detailed security sections. 7. IANA Considerations This document makes no requests for any IANA action. 8. Acknowledgements The authors would like to extend their warmest thanks to Kireeti Kompella for convincing them to expend effort on this document. Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani and Igor Bryskin for their review and suggestions on the text. 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has Farrel, Vasseur and Ayyangar Page 17 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 11. Informational References [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", RFC 3630, September 2003 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. Farrel, Vasseur and Ayyangar Page 18 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 [ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes, work in progress. [BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", work in progress. [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for MPLS Signaling", draft-ietf-ccamp-crankback, work in progress. [EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE, draft-ietf-ccamp-rsvp-te-exclude-route, work in progress. [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, work in progress. [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS Traffic Engineering Requirements", draft-otani-ccamp-interas-GMPLS-TE, work in progress. [GMPLS-E2E] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors, "RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery", draft-lang-ccamp-gmpls-recovery-e2e-signaling, work in progress. [HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in progress. [INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of Inter-Area and Inter-AS MPLS Traffic Engineering", draft-ietf-tewg-interarea-mpls-te-req, work in progress. [INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic Engineering requirements", draft-ietf-tewg-interas-mpls-te-req, work in progress. [LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness in MPLS", draft-ietf-mpls-lsp-ping, work in progress. [OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay Model", draft-ietf-ccamp-gmpls-overlay, work in progress. Farrel, Vasseur and Ayyangar Page 19 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 [PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture, work in progress. [SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel, A., "GMPLS Based Segment Recovery", draft-ietf-ccamp-gmpls-segment-recovery, work in progress. [STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching, work in progress. 12. Authors' Addresses Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Arthi Ayyangar Juniper Networks, Inc 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA Email: arthi@juniper.net 13. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Farrel, Vasseur and Ayyangar Page 20 --------------020900020408000800080201-- From owner-ccamp@ops.ietf.org Mon Sep 26 07:35:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJrGc-0005BO-Um for ccamp-archive@megatron.ietf.org; Mon, 26 Sep 2005 07:35:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19676 for ; Mon, 26 Sep 2005 07:35:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJrNf-0001bs-44 for ccamp-archive@ietf.org; Mon, 26 Sep 2005 07:42:47 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EJr5b-0005dV-Vo for ccamp-data@psg.com; Mon, 26 Sep 2005 11:24:07 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EJr5Y-0005d9-G4 for ccamp@ops.ietf.org; Mon, 26 Sep 2005 11:24:04 +0000 Received: from du-069-0045.access.clara.net ([217.158.132.45] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EJr5U-0005uE-G0; Mon, 26 Sep 2005 12:24:02 +0100 Message-ID: <15be01c5c28d$36fdff00$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Wijnen, Bert \(Bert\)" , , , References: <7D5D48D2CAA3D84C813F5B154F43B15508234609@nl0006exch001u.nl.lucent.com> Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Mon, 26 Sep 2005 12:17:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Hi Bert. Thanks. If 32 chars is no longer a limit, we should make the suggested change. I agree that consistency and comprehensibility of names are important. Wrt compliance statements etc. I will try to wrap my brain around this, but will probably need to bounce the resulting work off you and Joan. Cheers, Adrian ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "Adrian Farrel" ; ; ; Sent: Sunday, September 25, 2005 10:13 PM Subject: RE: review of draft-ietf-ccamp-lsr-mib-08.txt > W.r.t. > > >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > > > > > >Please change the name to: gmplsLabelModuleReadOnlyCompliance > > >to be consistent with the other MPLS and GMPLS MIB modules. > > > > Nack > > I thought we tried to keep names down to 32 characters. I recall this > > conversation before. Not mandatory, but desirable. > > > > The "rule" of less than 32 has long ago been relaxed. > I personally feel it is more important to be consistent in naming than > having less than 32 chars. > > See RFC4181 sect 4.2 > > But I agree it is not a fatal flaw, so we won't block on it. > > > A choice between two desires? > > > > >41) The ReadOnly compliance for gmplsLabelRowStatus > > >does NOT have a MIN-ACCESS of read-only. Is this > > >intentional? > > > > ??? > > Not sure about this. > > I thought the present of a WRITE-SYNTAX made some difference. > > > > If you have a MODULE-COMPLIANCE statement as you do: > > gmplsLabelModuleROCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Compliance requirement for implementations that only > provide read-only support for GMPLS-LABEL-STD-MIB. Such > devices can then be monitored but cannot be configured > using this MIB modules." > > So both the descriptor and the DESCRIPTION state that this is for > read-only support, then it feels VERY WEIRD to me (actually it > feels BROKEN to me) to not have all RowStatus objects be listed > with MIN-ACCESS read-only. And having a WRITE-SYNTAX feels > similarly weird. > > > >42) Also, (related to the above) > > > OBJECT gmplsLabelRowStatus > > > SYNTAX RowStatus { > > > active(1), > > > notInService(2) > > > } > > > > > > WRITE-SYNTAX RowStatus { > > > active(1), > > > notInService(2), > > > createAndGo(4), > > > destroy(6) > > > } > > > DESCRIPTION > > > "Support for notInService, createAndWait and notReady is not > > > required." > > > > > >The DESCRIPTION clause conflicts with the WRITE-SYNTAX. > > >Please clarify the intentions for this ReadOnly compliance > > >object. > > > > Ack > > There is an error here. > > > > See my comment above. I think it should be MIN-ACCESS read-only > and SYNTAX { active }. I do not see any other status to make sense. > > > > >Section 12.2 Informational References > > >--------------------------------------- > > > > > >43a) The title of this section should be > > >Informative. > > > > Ack/Nack > > > > I am aware of the RFC Editor's preferences. > > Unfortunately these references are only informative if you read an > > understand them (and > > even then not always :-), but they are informational even if you don't > > read or > > understand them. > > > > I know that RFC-editor uses a tool that prefers "informative". > But it is probably not mandatory. > > > Bert > > From owner-ccamp@ops.ietf.org Mon Sep 26 15:27:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJydV-0006tk-VS for ccamp-archive@megatron.ietf.org; Mon, 26 Sep 2005 15:27:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04174 for ; Mon, 26 Sep 2005 15:27:36 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJykY-0004Bt-9C for ccamp-archive@ietf.org; Mon, 26 Sep 2005 15:34:58 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EJyT2-000IQb-Op for ccamp-data@psg.com; Mon, 26 Sep 2005 19:16:48 +0000 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EJySr-000IPT-BN for ccamp@ops.ietf.org; Mon, 26 Sep 2005 19:16:37 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id 105801797 for ; Mon, 26 Sep 2005 15:16:36 -0400 (EDT) Message-ID: <015b01c5c2ce$d0242b50$7a1810ac@movaz.com> From: "Igor Bryskin" To: References: Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt Date: Mon, 26 Sep 2005 15:16:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Hi. I'd like to recognize the good effort by the authors to bring the document into its current shape. I have a few minor comments. 1. forwarding adjacency. The term is used in a sense of a data plane adjacency between two nodes that could be used to send data directly to each other, which literally means "forwarding adjacency" :=). Unfortunately the term is widely used in a different sense - as a certain control plane quality of a TE link. I'd recommend to use term "data plane adjacency" instead of "forwarding adjacency" in this document. 2. regular, basic TE link These terms are not clear and not defined anywhere. I'd suggest to use term " TE link associated with statically configured data link(s)" 3. " E.g. one suggested usage in case of P2MP RSVP LSPs ([7]) is the use of LSP stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP capable LSRs in the network. The LSP segment would traverse legacy LSRs that may be incapable of acting as P2MP branch points, thereby shielding them from the P2MP control and data path.This statement is not quite accurate. Stitching segments as well as H-LSPs help to use legacy non-P2MP capable (not branch incapable) nodes as intermediate nodes of P2MP tunnels. This is not about branching capability that legacy LSRs lack - this is about P2MP signaling capability. Igor ----- Original Message ----- From: To: Cc: Sent: Friday, September 23, 2005 3:50 PM Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt > 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 : Label Switched Path Stitching with Generalized MPLS Traffic Engineering > Author(s) : A. Ayyangar, J. Vasseur > Filename : draft-ietf-ccamp-lsp-stitching-02.txt > Pages : 19 > Date : 2005-9-23 > > In certain scenarios, there may be a need to combine together > different Generalized Multi-Protocol Label Switching (GMPLS) Label > Switched Paths (LSPs) such that in the data plane, a single end-to- > end (e2e) LSP is realized and all traffic from one LSP is switched > onto the other LSP. We will refer to this as "LSP stitching". This > document covers cases where: a) the node performing the stitching > does not require configuration of every LSP pair to be stitched > together b) the node performing the stitching is not the egress of > any of the LSPs c) LSP stitching not only results in an end-to-end > LSP in the data plane, but there is also a corresponding end-to-end > LSP (RSVP session) in the control plane. > > It may be possible to configure a GMPLS node to switch the traffic > from an LSP for which it is the egress, to another LSP for which it > is the ingress, without requiring any signaling or routing extensions > whatsoever, completely transparent to other nodes. This will also > result in LSP stitching in the data plane. However, this document > does not cover this scenario of LSP stitching. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-lsp-stitching-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-lsp-stitching-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. > From owner-ccamp@ops.ietf.org Tue Sep 27 13:46:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJXP-0007Kl-5n for ccamp-archive@megatron.ietf.org; Tue, 27 Sep 2005 13:46:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27304 for ; Tue, 27 Sep 2005 13:46:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKJeh-0004Ig-8D for ccamp-archive@ietf.org; Tue, 27 Sep 2005 13:54:15 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKJMX-0008yn-1p for ccamp-data@psg.com; Tue, 27 Sep 2005 17:35:29 +0000 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1EKJMT-0008yR-R0 for ccamp@ops.ietf.org; Tue, 27 Sep 2005 17:35:25 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j8RHXiBm041852; Tue, 27 Sep 2005 10:33:44 -0700 (PDT) (envelope-from arthi@juniper.net) Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j8RHXeG17781; Tue, 27 Sep 2005 10:33:40 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Tue, 27 Sep 2005 10:33:40 -0700 (PDT) From: Arthi Ayyangar To: Igor Bryskin cc: ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt In-Reply-To: <015b01c5c2ce$d0242b50$7a1810ac@movaz.com> Message-ID: <20050927101912.W4485@zircon.juniper.net> References: <015b01c5c2ce$d0242b50$7a1810ac@movaz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Hi Igor, Thanks for your comments. See my replies inline. > I have a few minor comments. > > 1. forwarding adjacency. > > The term is used in a sense of a data plane adjacency between two nodes > that could be used to send data directly to each other, which literally > means "forwarding adjacency" :=). Unfortunately the term is widely used in a > different sense - as a certain control plane quality of a TE link. I'd > recommend to use term "data plane adjacency" instead of "forwarding > adjacency" in this document. -----> I agree with your comment and in fact we started with the term data plane adjacency. But changed it to the well-established term of "forwarding adjacency". As you point out it also has a "well-established" control plane connotation...so to avoid any confusion we'll change this to data plane adjacency, where applicable. > 2. regular, basic TE link > > These terms are not clear and not defined anywhere. I'd suggest to use term > " TE link associated with statically configured data link(s)" ----> Okay. > 3. > > " > E.g. one suggested usage in case of P2MP RSVP > LSPs ([7]) is the use of LSP stitching to stitch a P2MP RSVP LSP to > an LSP segment between P2MP capable LSRs in the network. The LSP > segment would traverse legacy LSRs that may be incapable of acting as > P2MP branch points, thereby shielding them from the P2MP control and > data path.This statement is not quite accurate. Stitching segments as > well as H-LSPs help to use legacy non-P2MP capable (not branch incapable) > nodes as intermediate nodes of P2MP tunnels. This is not about branching > capability that legacy LSRs lack - this is about P2MP signaling capability. ---> Yes, this needs to be cleaned up. It was meant to deal with LSRs lacking P2MP control plane (signaling) capability. thanks, -arthi > Igor > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, September 23, 2005 3:50 PM > Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt > > >> 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 : Label Switched Path Stitching with Generalized MPLS Traffic > Engineering >> Author(s) : A. Ayyangar, J. Vasseur >> Filename : draft-ietf-ccamp-lsp-stitching-02.txt >> Pages : 19 >> Date : 2005-9-23 >> >> In certain scenarios, there may be a need to combine together >> different Generalized Multi-Protocol Label Switching (GMPLS) Label >> Switched Paths (LSPs) such that in the data plane, a single end-to- >> end (e2e) LSP is realized and all traffic from one LSP is switched >> onto the other LSP. We will refer to this as "LSP stitching". This >> document covers cases where: a) the node performing the stitching >> does not require configuration of every LSP pair to be stitched >> together b) the node performing the stitching is not the egress of >> any of the LSPs c) LSP stitching not only results in an end-to-end >> LSP in the data plane, but there is also a corresponding end-to-end >> LSP (RSVP session) in the control plane. >> >> It may be possible to configure a GMPLS node to switch the traffic >> from an LSP for which it is the egress, to another LSP for which it >> is the ingress, without requiring any signaling or routing extensions >> whatsoever, completely transparent to other nodes. This will also >> result in LSP stitching in the data plane. However, this document >> does not cover this scenario of LSP stitching. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-02.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> 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-lsp-stitching-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-lsp-stitching-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. >> > From owner-ccamp@ops.ietf.org Tue Sep 27 21:46:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKR1K-0007Dg-HG for ccamp-archive@megatron.ietf.org; Tue, 27 Sep 2005 21:46:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06375 for ; Tue, 27 Sep 2005 21:46:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKR8Y-0004HH-Fm for ccamp-archive@ietf.org; Tue, 27 Sep 2005 21:53:43 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKQrP-000OT5-EN for ccamp-data@psg.com; Wed, 28 Sep 2005 01:35:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.69] (helo=smtpauth09.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKQrO-000OOY-B9 for ccamp@ops.ietf.org; Wed, 28 Sep 2005 01:35:50 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MG8DpLez+THIpwfbkHxWc6mEl0ULGTrN5TFA4S3ZronH8lV8LUvaKs4hOlGsHm50; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.249.236] (helo=jlucianilaptop) by smtpauth09.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1EKQqa-0007j3-Qs; Tue, 27 Sep 2005 21:35:01 -0400 Message-ID: <009801c5c3cd$43d56e20$0500a8c0@jlucianilaptop> From: To: , , Cc: , References: <3.0.1.32.20050908213717.014708c8@pop.mindspring.com> <3.0.1.32.20050923120504.01564e90@pop.mindspring.com> <141f01c5c0f3$90e2b650$28849ed9@Puppy> <008801c5c3c7$71222ae0$0500a8c0@jlucianilaptop> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Tue, 27 Sep 2005 21:38:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265490532458044af9dbaddf279a1092531958ce75fe477930ad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.249.236 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Content-Transfer-Encoding: 7bit Hi Adrian, A couple of minor comments inline below. thanks, Joan > ----- Original Message ----- > From: Adrian Farrel > To: tnadeau@cisco.com ; ccamp@ops.ietf.org ; jcucchiara@mindspring.com > Cc: bwijnen@lucent.com ; jcucchiara@mindspring.com > Sent: Saturday, September 24, 2005 6:02 AM > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > > > Hi Joan, > > Thanks for the rapid convergence. > > In-line... > > Cheers, > Adrian > > > >> 3*) Question if these documents should have a > > >> contributors section. It violates the guidelines > > >> of "RFC Editorial Guidelines and Procedures" > > >> http://www.rfc-editor.org/policy.html#policy.auth2 > > >> > > >> There are many people listed under > > >> Authors but not listed on the front page, > > >> so how about adding a Contributors Section? > > > > > >Ack > > >We will change the title of "Authors' Addresses" section to be "Contact > > >Details". > > > > According to the rfc-editor website above, > > this should be "Contact Information", is this what you mean? > > Yes, in deed. And Henrick's little tool catches this admirably. > > > >> draft-ietf-ccamp-gmpls-tc-mib-07.txt > > >> ====================================== > > >> > > >> Section 3. GMPLS Textual Conventions MIB Definitions > > >> --------------------------------------------------- > > > > >> 1) GmplsFreeformLabel TC > > > > >> 1c) The DESCRIPTION needs a little work: > > >> DESCRIPTION > > >> "This value represents a freeform generalized MPLS Label. This > > >> can be used to represent label types which are not standard in > > >> the drafts. It may also be used by systems that do not wish to > > >> represent the labels using the specific label types." > > >> > > >> Please reword to something like: > > >> > > >> "This value represents a freeform GMPLS label. A freeform GMPLS > > >> label is specified by the system which uses it. In other words, > > >> the freeform GMPLS label is not a standard GMPLS label type, > > >> but is created by the system which uses it." > > > > > >Nack > > >The text as originally stated is correct and your revision is wrong. That > > >is, the freeform label MAY also be used to represent standard labels > > >as octet strings. > > >This is a popular way to handle the management of multiple different > types > > >of labels. > > > > > >Will change to: > > > "This value represents a freeform GMPLS Label. This can be used > > > to represent label that have label types which are not > > > standardised. It may also be used by systems that do not wish to > > > represent labels that have standardised label types using the > > > type-specific objects in this table." > > > > Sorry, I'm still a little foggy on what this TC is, partly because the > > description is referring to "objects in this table" which is confusing > > in a TC DESCRIPTION, and also the definition of the freeform label > > used here and used in the GmplsGeneralizedLabelType enum seems be > > defined slightly differently. > > Good point about "objects in this table." That needs to be removed. > > So, the description of GmplsGeneralizedLabelTypes should be changed to > read... > Determines the interpretation that should be applied to an > object that encodes a label. > > But I don't see anything else in the GmplsGeneralizedLabelType enum that > presents any interpretation of the freeform object. > > > A freeform label as described in the DESCRIPTION clause > > could contain the value of any GMPLS/MPLS labels, > > right? > > Right. > > How about... > "This Textual Convention can be used as the syntax of an object > that contains any GMPLS label. Objects with this syntax can be > used to represent labels that have label types that are not > standardised. The freeform GMPLS Label may also be used by > systems that do not wish to represent labels that have > standardised label types using type-specific syntaxes." > Instead of saying "not standardised" could you say "not defined in any RFCs"? This is a small point but not sure if a label in a "proposed standard" is considered "standardised" yet. Similarly, with the second use of "standarised" could you say "defined"? > > >> 2) GmplsGeneralizedLabelTypes TC > > > > >> 2b) Could the SYNTAX order be changed? > > >> > > >> Currently: > > >> > > >> SYNTAX INTEGER { > > >> gmplsMplsLabel(1), > > >> gmplsPortWavelengthLabel(2), > > >> gmplsFreeformGeneralizedLabel(3), > > >> gmplsSonetLabel(4), > > >> gmplsSdhLabel(5), > > >> gmplsWavebandLabel(6) > > >> } > > >> > > >> Proposed (NOTE also some of the names have been changed): > > >> > > >> SYNTAX INTEGER { > > >> gmplsFreeformLabelOrOther(1), > > >> gmplsMplsLabel(2), > > >> gmplsPortAndWavelengthLabel(3), > > >> gmplsSonetLabel(4), > > >> gmplsSdhLabel(5), > > >> gmplsWavebandLabel(6) > > >> } > > > > > >Nack > > >i. "FreeformOrOther" What other? There is just freeform. > > > > Aren't the label types: gmplsMplsLabel(2), > > gmplsPortAndWavelengthLabel(3), > > gmplsSonetLabel(4), > > gmplsSdhLabel(5), > > gmplsWavebandLabel(6) > > also a kind of freeform GMPLS label (as indicated by the DESCRIPTION > > clause in GmplsFreeformLabel)? > > It is all to do with the encodings of objects (i.e. the syntaxes) not the > use to which the labels can be put. Thus, a normal 20-bit MPLS label an be > encoded in an object with syntax MPLSLabel or in an object with syntax > GMPLSFreeformLabel. In the former case it is presented as an Unsigned32. In > the latter case it is presented as an OCTET STRING. > > > >ii. Why re-order? The new order seems to have no more logic than the > > > old order. > > > > Partly depends on the answer to above i. question. > > If the labels are a kind of freeform label, > > then a better style would be to list > > gmplsFreeformLabel first. Admittedly, this is a NIT. > > > > Also, please add into the DESCRIPTION clause > > a definition for each enum (an example would > > be MplsLspType in RFC3811). > > Yes. That is a good idea. > > Description will now read... > > DESCRIPTION > > "Determines the interpretation that should be applied to an > object that encodes a label. The possible types are: > > gmplsMplsLabel(1) - The label is an MPLS packet, cell, > or frame label and is encoded as > described for the Textual Convention > MPLSLabel defined in RFC 3811. Should be "MplsLabel" > > gmplsPortWavelengthLabel(2) - The label is a port or wavelength > label as defined in RFC 3741. > > gmplsFreeformGeneralizedLabel(3) - The label is any form of label > encoded > as an OCTET STRING using the Textual > Convention GMPLSFreeformLabel. Please rename this enum to: gmplsFreeformLabel which will match the GmplsFreeformLabel TC. (Also, GMPLSFreeformLabel should be GmplsFreeformLabel.) > > gmplsSonetLabel(4) - The label is a SONET label as defined > in RFC 3946. > > gmplsSdhLabel(5) - The label is an SDH label as defined > in > RFC 3946. > > gmplsWavebandLabel(6) - The label is a waveband label as > defined > in RFC 3471." > Please be sure to include all the above referenced RFCs in the REFERENCE Clause of this object (and also in the Normative References Section of this draft). From owner-ccamp@ops.ietf.org Tue Sep 27 23:17:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKSS9-0005Dc-C5 for ccamp-archive@megatron.ietf.org; Tue, 27 Sep 2005 23:17:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10195 for ; Tue, 27 Sep 2005 23:17:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKSZU-0006Kf-KR for ccamp-archive@ietf.org; Tue, 27 Sep 2005 23:25:29 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKSLs-0006hs-St for ccamp-data@psg.com; Wed, 28 Sep 2005 03:11:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.69] (helo=smtpauth09.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKSLp-0006hW-AF for ccamp@ops.ietf.org; Wed, 28 Sep 2005 03:11:21 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=feDTD4SLz+yj4gL19HS/YRQCg8JIHaAgR3kPNHwJ/B0U60eJLbvMlhV0B3u5z/QT; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.249.236] (helo=jlucianilaptop) by smtpauth09.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1EKSLi-0001ID-Iz; Tue, 27 Sep 2005 23:11:15 -0400 Message-ID: <012601c5c3da$b3441ec0$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , , Cc: , References: <3.0.1.32.20050908114852.0147664c@pop.mindspring.com> <119b01c5bf74$daed3f20$28849ed9@Puppy> Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Tue, 27 Sep 2005 23:14:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265490532458044af9db1a96a8f94bc8476da2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.249.236 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: b612707e1a3f67df80ae89cdab1ba981 Content-Transfer-Encoding: 7bit Hi Adrian, I have snipped parts where we are in agreement. Please see inline comments. thanks, Joan ----- Original Message ----- From: Adrian Farrel To: ; ; Cc: ; Sent: Thursday, September 22, 2005 8:55 AM Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt > Hi again Joan, > > This is the response to your excellent review of the GMPLS LSR MIB module. > > As before, I have indicated Ack or Nack for each point you raised. Where > there is a Nack I have indicated either our reasoning or a proposed > alternate solution. > > Feel free to snip in any response you send. > > Once we have closure on a few remaining issues we will respin applying > David's > comments on the TE MIB here as well. > > Cheers, > Adrian > > >Section 4.1.2 Summary of GMPLS Label MIB Module > >------------------------------------------------- > > > >4) "Generalized Labels can be of variable length and have distinct > > bit-by-bit interpretations according to the use that is made of > > them." > > > >Please change the above to: > > > > "Generalized Labels can be of variable length and have distinct > > bit-by-bit interpretations depending upon how they are defined > > by the specific service provider." > > Nack. > Nothing to do with the service provider. > Will change to: > > "Generalized Labels can be of variable length and have distinct > bit-by-bit interpretations depending upon how they are defined > for the specific technology in which they are used. For example, > labels used for MPLS packet switching are different in length > and content from labels used in TDM timeslot switching." Good. Thanks. > >17) object: gmplsInterfaceSignalingCaps OBJECT-TYPE > > > > SYNTAX BITS { > > unknown (0), > > rsvpGmpls (1), > > crldpGmpls (2), -- note the use of CR-LDP is deprecated > > otherGmpls (3) > > } > > > > > >What is otherGmpls(3)?? > > Nack > > I'm embarrassed to say that there are other "GMPLS" signaling protocol > variants that have been developed outside the IETF. This was added in > response to a WG request. > > >Also, this description is confusing. How can unknown(0) and > >rsvpGmpls(1) be set simultaneously? > > Ack > Will add: > > ...but if unknown(0) is set, no other bit may be set. > > >Additionally, how can no bits be set? If this is a GMPLS interface, > >then doesn't one of these bits HAVE to be set? > > Ack > > As it says... > > Setting no bits implies > that GMPLS signaling cannot be performed on this interface and > all LSPs must be manually provisioned or that this table entry > is only present to supplement an entry in the mplsInterfaceTable > by providing the information carried in other objects in this > row. > > This means that we should change gmplsInterfaceEntry to read: > > "A conceptual row in this table is created automatically by an > LSR for each interface that is both capable of supporting > GMPLS and that is configured to support GMPLS. Note that > support of GMPLS is not limited to control plane signaling, > but may include data-plane only function configured through > SNMP SET commands performed on this MIB module. > > A conceptual row in this table may also be created via SNMP > SET commands or automatically by the LSR to supplement a > conceptual row in the mplsInterfaceTable where the interface > is not capable of GMPLS but where the other objects carried > in this row provide useful additional information for an > MPLS interface." If I could ask you to put your chair hat on for a minute, what are the co-authors doing to get feedback from the MPLS working group on objects which may apply to MPLS? Additionally, is this draft going to have a last call in the MPLS working group? (maybe this is a question for the ADs). Also, it seems this object would be more appropriate in the GMPLS-TE-STD-MIB. Is there a reason for choosing the GMPLS-LSR-STD-MIB for this object? > > >18) gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE > > "Period, in milliseconds, between sending RSVP Hello messages on > > this interface. A value of 0 indicates that no Hello messages > > should be sent on this interface." > > > >This object is only valid if the gmplsInterfaceSignalingCaps > >object is set to rsvpGmpls. Please update the description > >to reflect that. > > Nack > It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB). Why is this object in this MIB as opposed to the GMPLS-TE-STD-MIB? I thought that GMPLS-TE-STD-MIB augmented the MPLS-TE-STD-MIB, is that not the case? > > We can add: > This object is not valid if gmplsInterfaceSignalingCaps is > set to crldpGmpls (2) > > > > >22) gmplsInSegmentExtraParamsPtr OBJECT-TYPE > > SYNTAX RowPointer > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Some Tunnels will run over transports that can usefully support > > technology-specific additional parameters (for example, SONET > > resource usage). Such can be supplied from an external table and > > referenced from here. A value of zeroDotzero in this attribute > > indicates that there is no such additional information." > > DEFVAL { zeroDotZero } > > ::= { gmplsInSegmentEntry 2 } > > > >What is meant by "external table"? If this is an enterprise-specific > >table, then is it necessary to have this object in the MIB. In other > >words, why is this MIB dictating that a row-pointer be used when > >an enterprise-specific MIB may which to simply use indices. > > > >I think this object is unnecessary, but maybe I don't understand > >something. > > Nack > > rowPointers are typically used when there may be a many-to-one mapping. > This is appropriate for traffic parameters because there may be a few > service > categories defined in a traffic parameters table, and multiple LSPs may > use > those parameters. > > Compare with mplsInSegmentTrafficParamPtr in RFC3813. > > Now, in this case no such traffic parameters table has been supplied. To > some extent > we are guilty of future-proofing. We are aware that such tables will need > to be > added for TDM (quite soon), for lambda (possibly), and for Ethernet > (almost certainly). > > Although it would be possible to leave this out, we feel that the > necessary single-object > extension that would need to be created later would be messy. okay. > > >23) gmplsOutSegmentEntry OBJECT-TYPE > >Same comments as with gmplsInSegmentEntry > > Nack > Same answer Think you mean ack here? > > >24) gmplsOutSegmentDirection OBJECT-TYPE > >Same comment as with gmplsInSegmentDirection > > Ack > > >27) gmplsOutSegmentExtraParamsPtr OBJECT-TYPE > > > >Same comment as with gmplsInSegmentExtraParamsPtr > > Nack > Same answer > okay. > >28) Compliance Statements > > > >I believe that gmplsInSegmentExtraParamsPtr and > >gmplsOutSegmentExtraParamsPtr do not need to be > >supported, so these maybe should be optional. > > Ack > > >Section 8. GMPLS-LABEL-STD-MIB > >=================================== > >31) gmplsLabelTable OBJECT-TYPE > > > >The last part of the last paragraph is awkward: > > > > "... Labels in the tables in other MIBs are referred to using > > row pointer into this table. The indexing of this table provides > > for arbitrary indexing and also for concatenation of labels." > > > >Are you saying that other MIBs can use a row pointer to point to > >this table? Why would they do that if they could just use the > >indices directly? Also, I don't follow the comment about > >concatenation of labels. Could you explain this? > > Nack > Yes we are saying that other MIB modules can use a row pointer to > point to this table. > Yes they could use indices. This was the subject of a very lengthy > discussion between the co-authors, etc., but in the end we > observed that mplsInSegmentLabelPtr and mplsOutSegmentLabelPtr > (RFC3813) are rowPointers so we had better support being pointed to. > > We could soften the language here by replacing "are" with "may". > Yes, please. > Note, we should change this to say "MIB modules" > good. > For an example of label concatenation see RFC3945 section 7.1. In essence, > a GMPLS label may be composite in order to identify a set of resources in > the data plane. Practial examples are timeslots and wavelength sets (which > are not contiguous like wavebands). > > The indexing mechanism allows multiple entries in this table to be seen > as a sequence of labels that should be concatenated. Ordering is > potentially > very sensitive for concatenation. > It would be nice if you could add the above 2 paragraphs to the DESCRIPTION. > I don't believe we need to add text or references for concatenated labels > since they are part of the architecture. > > >32) gmplsLabelEntry OBJECT-TYPE > > > >The last sentence of the DESCRIPTION, please remove > >the word "more" from the phrase "is more persistent." > > Nack. > The Textual Convention gives us degrees. That is, 'readOnly' is more > durable than 'permanent' which is more durable than 'nonNolatile' which > is more durable than 'volatile'. > We need to convey that there is a ranked inheritance. > "Persistence" is acceptable in a comparative. > > >I still don't understand how the subindex provides a way > >to concatenate the labels. Could you give an example? > > Nack > If you are asking for an example in the I-D, I don't think it is > necessary. > > For your information, the composite label {{A}, {B}, {C}} might be > constructed > as... > > gmplsLabelInterface = 1 > gmplsLabelIndex = 1 > gmplsLabelSubindex = 1 > gmplsLabelFreeform = A > > gmplsLabelInterface = 1 > gmplsLabelIndex = 1 > gmplsLabelSubindex = 2 > gmplsLabelFreeform = B > > gmplsLabelInterface = 1 > gmplsLabelIndex = 1 > gmplsLabelSubindex = 3 > gmplsLabelFreeform = C > This is a good example and would, I think, be helpful someplace in the document. This is only a suggestion however, and not a blocking issue. > >33) please switch RowStatus and StorageType (this will > >more closely match the other MPLS MIBs). > > Ack > > >34) gmplsLabelInterface OBJECT-TYPE > > > >DESCRIPTION also needs to specify that zero may be > >used to indicate that the InterfaceIndex is not known > >or that an InterfaceIndex exists but it is not important > >wrt this implementation so zero is used. > > Nack > The use of zero is very precisely specified at the moment. > The reasons for setting zero that you cite are: > - the InterfaceIndex is not known > You cannot have a per-interface label space without knowing the > interface to which it applies. > - InterfaceIndex exists but it is not important wrt this implementation > That is exactly the case of the global label space, and is already > stated. > I think you need to list all the reasons under which zero could be a valid value for this index. You have listed more above which are not specified in the description. > >35) gmplsLabelIndex OBJECT-TYPE > > SYNTAX Unsigned32 (0..4294967295) > > > >36a) I was expecting the SYNTAX to be IndexInteger due > >to the gmplsLabelIndexNext in the DESCRIPTION. > >Please explain why the use of zero is needed. You > >explain the use of zero in the gmplsLabelInterface > >and gmplsLabelSubindex indices. > > Nack > > This is explained by the paragraph: > > Note that implementations that are representing 32 bit labels > within this table MAY choose to align this index with the value > of the label, but should be aware of the implications of > sparsely populated tables. > > We believe it would be inappropriate to use IndexInteger to have greater > meaning than just an index. > > But anyway, IndexInteger is Unsigned32 (1..4294967295) and the quoted > paragraph > must allow zero as well. Yes, it is fine to allow zero, I was just trying to understand when it should be zero (under what conditions)? > > >36b)Please change the "may" to "should" in this statement: > > A management application may read the gmplsLabelIndexNext > > object to find a suitable value for this object." > > Nack > Why "should" it do this? This is a convenience offered to it. It may use > any > mechanism it chooses including the one suggested in the quoted paragraph > above. Without getting into a debate about tables and indexing, the should is extremely appropriate. Think of the case where you have a large number of rows in this table, do you expect a user to try a bunch of numbers to create a row even if he/she has access to a CLI, it will certainly be annoying to have to page through this table and get to an available number. If a user consults the gmplsLabelIndexNext object then creating an entry should be easier than not getting the gmplsLabelIndexNext object. > > >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > > > >Please change the name to: gmplsLabelModuleReadOnlyCompliance > >to be consistent with the other MPLS and GMPLS MIB modules. > > Nack > I thought we tried to keep names down to 32 characters. I recall this > conversation before. Not mandatory, but desirable. > > A choice between two desires? > Please refer to Bert's comments on this. > >41) The ReadOnly compliance for gmplsLabelRowStatus > >does NOT have a MIN-ACCESS of read-only. Is this > >intentional? > > ??? > Not sure about this. > I thought the present of a WRITE-SYNTAX made some difference. > Please refer to Bert's comments on this. > >42) Also, (related to the above) > > OBJECT gmplsLabelRowStatus > > SYNTAX RowStatus { > > active(1), > > notInService(2) > > } > > > > WRITE-SYNTAX RowStatus { > > active(1), > > notInService(2), > > createAndGo(4), > > destroy(6) > > } > > DESCRIPTION > > "Support for notInService, createAndWait and notReady is not > > required." > > > >The DESCRIPTION clause conflicts with the WRITE-SYNTAX. > >Please clarify the intentions for this ReadOnly compliance > >object. > > Ack > There is an error here. > From owner-ccamp@ops.ietf.org Wed Sep 28 08:37:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKbBF-0005lx-9d for ccamp-archive@megatron.ietf.org; Wed, 28 Sep 2005 08:37:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03080 for ; Wed, 28 Sep 2005 08:37:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKbIX-0003Ra-39 for ccamp-archive@ietf.org; Wed, 28 Sep 2005 08:44:43 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKayY-000PVd-Mr for ccamp-data@psg.com; Wed, 28 Sep 2005 12:23:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKayX-000PVM-5k for ccamp@ops.ietf.org; Wed, 28 Sep 2005 12:23:53 +0000 Received: from du-069-0384.access.clara.net ([217.158.145.130] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1EKayP-0006AK-GW; Wed, 28 Sep 2005 13:23:51 +0100 Message-ID: <01d601c5c427$e012e330$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , References: <3.0.1.32.20050908213717.014708c8@pop.mindspring.com> <3.0.1.32.20050923120504.01564e90@pop.mindspring.com> <141f01c5c0f3$90e2b650$28849ed9@Puppy> <008801c5c3c7$71222ae0$0500a8c0@jlucianilaptop> <009801c5c3cd$43d56e20$0500a8c0@jlucianilaptop> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Wed, 28 Sep 2005 13:22:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: 7bit Thanks for your thoroughness, Joan. All points agreed. Adrian ----- Original Message ----- From: To: ; ; Cc: ; Sent: Wednesday, September 28, 2005 2:38 AM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > Hi Adrian, > > A couple of minor comments inline below. > > thanks, > Joan > > > > > ----- Original Message ----- > > From: Adrian Farrel > > To: tnadeau@cisco.com ; ccamp@ops.ietf.org ; jcucchiara@mindspring.com > > Cc: bwijnen@lucent.com ; jcucchiara@mindspring.com > > Sent: Saturday, September 24, 2005 6:02 AM > > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > > > > > > Hi Joan, > > > > Thanks for the rapid convergence. > > > > In-line... > > > > Cheers, > > Adrian > > > > > >> 3*) Question if these documents should have a > > > >> contributors section. It violates the guidelines > > > >> of "RFC Editorial Guidelines and Procedures" > > > >> http://www.rfc-editor.org/policy.html#policy.auth2 > > > >> > > > >> There are many people listed under > > > >> Authors but not listed on the front page, > > > >> so how about adding a Contributors Section? > > > > > > > >Ack > > > >We will change the title of "Authors' Addresses" section to be "Contact > > > >Details". > > > > > > According to the rfc-editor website above, > > > this should be "Contact Information", is this what you mean? > > > > Yes, in deed. And Henrick's little tool catches this admirably. > > > > > >> draft-ietf-ccamp-gmpls-tc-mib-07.txt > > > >> ====================================== > > > >> > > > >> Section 3. GMPLS Textual Conventions MIB Definitions > > > >> --------------------------------------------------- > > > > > > >> 1) GmplsFreeformLabel TC > > > > > > >> 1c) The DESCRIPTION needs a little work: > > > >> DESCRIPTION > > > >> "This value represents a freeform generalized MPLS Label. This > > > >> can be used to represent label types which are not standard > in > > > >> the drafts. It may also be used by systems that do not wish > to > > > >> represent the labels using the specific label types." > > > >> > > > >> Please reword to something like: > > > >> > > > >> "This value represents a freeform GMPLS label. A freeform > GMPLS > > > >> label is specified by the system which uses it. In other > words, > > > >> the freeform GMPLS label is not a standard GMPLS label type, > > > >> but is created by the system which uses it." > > > > > > > >Nack > > > >The text as originally stated is correct and your revision is wrong. > That > > > >is, the freeform label MAY also be used to represent standard labels > > > >as octet strings. > > > >This is a popular way to handle the management of multiple different > > types > > > >of labels. > > > > > > > >Will change to: > > > > "This value represents a freeform GMPLS Label. This can be used > > > > to represent label that have label types which are not > > > > standardised. It may also be used by systems that do not wish > to > > > > represent labels that have standardised label types using the > > > > type-specific objects in this table." > > > > > > Sorry, I'm still a little foggy on what this TC is, partly because the > > > description is referring to "objects in this table" which is confusing > > > in a TC DESCRIPTION, and also the definition of the freeform label > > > used here and used in the GmplsGeneralizedLabelType enum seems be > > > defined slightly differently. > > > > Good point about "objects in this table." That needs to be removed. > > > > So, the description of GmplsGeneralizedLabelTypes should be changed to > > read... > > Determines the interpretation that should be applied to an > > object that encodes a label. > > > > But I don't see anything else in the GmplsGeneralizedLabelType enum that > > presents any interpretation of the freeform object. > > > > > A freeform label as described in the DESCRIPTION clause > > > could contain the value of any GMPLS/MPLS labels, > > > right? > > > > Right. > > > > How about... > > "This Textual Convention can be used as the syntax of an object > > that contains any GMPLS label. Objects with this syntax can be > > used to represent labels that have label types that are not > > standardised. The freeform GMPLS Label may also be used by > > systems that do not wish to represent labels that have > > standardised label types using type-specific syntaxes." > > > > Instead of saying "not standardised" could you say "not defined in any > RFCs"? > This is a small point but not sure if a label in a "proposed standard" > is considered "standardised" yet. > > Similarly, with the second use of "standarised" could you say "defined"? > > > > > > > >> 2) GmplsGeneralizedLabelTypes TC > > > > > > >> 2b) Could the SYNTAX order be changed? > > > >> > > > >> Currently: > > > >> > > > >> SYNTAX INTEGER { > > > >> gmplsMplsLabel(1), > > > >> gmplsPortWavelengthLabel(2), > > > >> gmplsFreeformGeneralizedLabel(3), > > > >> gmplsSonetLabel(4), > > > >> gmplsSdhLabel(5), > > > >> gmplsWavebandLabel(6) > > > >> } > > > >> > > > >> Proposed (NOTE also some of the names have been changed): > > > >> > > > >> SYNTAX INTEGER { > > > >> gmplsFreeformLabelOrOther(1), > > > >> gmplsMplsLabel(2), > > > >> gmplsPortAndWavelengthLabel(3), > > > >> gmplsSonetLabel(4), > > > >> gmplsSdhLabel(5), > > > >> gmplsWavebandLabel(6) > > > >> } > > > > > > > >Nack > > > >i. "FreeformOrOther" What other? There is just freeform. > > > > > > Aren't the label types: gmplsMplsLabel(2), > > > gmplsPortAndWavelengthLabel(3), > > > gmplsSonetLabel(4), > > > gmplsSdhLabel(5), > > > gmplsWavebandLabel(6) > > > also a kind of freeform GMPLS label (as indicated by the DESCRIPTION > > > clause in GmplsFreeformLabel)? > > > > It is all to do with the encodings of objects (i.e. the syntaxes) not the > > use to which the labels can be put. Thus, a normal 20-bit MPLS label an be > > encoded in an object with syntax MPLSLabel or in an object with syntax > > GMPLSFreeformLabel. In the former case it is presented as an Unsigned32. > In > > the latter case it is presented as an OCTET STRING. > > > > > >ii. Why re-order? The new order seems to have no more logic than the > > > > old order. > > > > > > Partly depends on the answer to above i. question. > > > If the labels are a kind of freeform label, > > > then a better style would be to list > > > gmplsFreeformLabel first. Admittedly, this is a NIT. > > > > > > Also, please add into the DESCRIPTION clause > > > a definition for each enum (an example would > > > be MplsLspType in RFC3811). > > > > Yes. That is a good idea. > > > > Description will now read... > > > > DESCRIPTION > > > > "Determines the interpretation that should be applied to an > > object that encodes a label. The possible types are: > > > > gmplsMplsLabel(1) - The label is an MPLS packet, cell, > > or frame label and is encoded as > > described for the Textual > Convention > > MPLSLabel defined in RFC 3811. > > Should be "MplsLabel" > > > > > > gmplsPortWavelengthLabel(2) - The label is a port or wavelength > > label as defined in RFC 3741. > > > > gmplsFreeformGeneralizedLabel(3) - The label is any form of label > > encoded > > as an OCTET STRING using the > Textual > > Convention GMPLSFreeformLabel. > > Please rename this enum to: gmplsFreeformLabel > which will match the GmplsFreeformLabel TC. (Also, GMPLSFreeformLabel > should be GmplsFreeformLabel.) > > > > > gmplsSonetLabel(4) - The label is a SONET label as > defined > > in RFC 3946. > > > > gmplsSdhLabel(5) - The label is an SDH label as > defined > > in > > RFC 3946. > > > > gmplsWavebandLabel(6) - The label is a waveband label as > > defined > > in RFC 3471." > > > > Please be sure to include all the above referenced RFCs in the > REFERENCE Clause of this object (and also in the Normative References > Section of this draft). > > > > > From owner-ccamp@ops.ietf.org Wed Sep 28 09:53:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKcNc-0003VF-9G for ccamp-archive@megatron.ietf.org; Wed, 28 Sep 2005 09:53:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08221 for ; Wed, 28 Sep 2005 09:53:50 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKcV3-0005ot-Bu for ccamp-archive@ietf.org; Wed, 28 Sep 2005 10:01:35 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKcEt-0006ry-IG for ccamp-data@psg.com; Wed, 28 Sep 2005 13:44:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKcEs-0006rk-Nv for ccamp@ops.ietf.org; Wed, 28 Sep 2005 13:44:50 +0000 Received: from du-069-0014.access.clara.net ([217.158.132.14] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EKcEr-000BBN-DQ; Wed, 28 Sep 2005 14:44:50 +0100 Message-ID: <020801c5c433$3358f010$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: GMPLS MIBs are related to MPLS-TE Date: Wed, 28 Sep 2005 13:45:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi, During MIB Doctor review of the GMPLS MIB modules it was pointed out that we have introduced new objects that may be useful extensions to the management of MPLS-TE systems that used the existing MPLS MIB modules (RFC3811 onwards). For example, we have the ability to configure/examine the Hello interval on a per-interface basis in an extension to the LSR MIB's mplsInterfaceTable. Since there will be a brief hiatus while the I-Ds are updated after MIB Doctor review, now would be a good opportunity for members of the MPLS community who have not been following the development of the GMPLS MIB modules within the CCAMP working group to comment on the documents. Of particular interest to the authors are two questions: - Are the MPLS-TE features that we have covered handled correctly? - Are there any MPLS-TE features that we have not included that you feel should be included? You can see the three GMPLS MIB documents at: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-08.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-09.txt You can see the MIB Doctor's comments in the CCAMP mailing list archive. Many thanks, Adrian From owner-ccamp@ops.ietf.org Wed Sep 28 09:53:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKcNc-0003VR-OC for ccamp-archive@megatron.ietf.org; Wed, 28 Sep 2005 09:53:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08224 for ; Wed, 28 Sep 2005 09:53:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKcV3-0005ou-CY for ccamp-archive@ietf.org; Wed, 28 Sep 2005 10:01:36 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKcF3-0006ta-Ec for ccamp-data@psg.com; Wed, 28 Sep 2005 13:45:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKcF1-0006tG-Ue for ccamp@ops.ietf.org; Wed, 28 Sep 2005 13:45:00 +0000 Received: from du-069-0014.access.clara.net ([217.158.132.14] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EKcEt-000BBN-G1; Wed, 28 Sep 2005 14:44:57 +0100 Message-ID: <020901c5c433$35234fd0$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Thomas D. Nadeau" , Cc: "Wijnen, Bert \(Bert\)" , References: <3.0.1.32.20050908114852.0147664c@pop.mindspring.com> <119b01c5bf74$daed3f20$28849ed9@Puppy> <012601c5c3da$b3441ec0$0500a8c0@jlucianilaptop> Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Wed, 28 Sep 2005 14:16:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Content-Transfer-Encoding: 7bit Again, thanks Joan. I think we are converging quickly. A few responses in the snipped email below. Cheers, Adrian > > >17) object: gmplsInterfaceSignalingCaps OBJECT-TYPE > > > > > > SYNTAX BITS { > > > unknown (0), > > > rsvpGmpls (1), > > > crldpGmpls (2), -- note the use of CR-LDP is deprecated > > > otherGmpls (3) > > > } > > > > > > > > >What is otherGmpls(3)?? > > > > Nack > > > > I'm embarrassed to say that there are other "GMPLS" signaling protocol > > variants that have been developed outside the IETF. This was added in > > response to a WG request. > > > > >Also, this description is confusing. How can unknown(0) and > > >rsvpGmpls(1) be set simultaneously? > > > > Ack > > Will add: > > > > ...but if unknown(0) is set, no other bit may be set. > > > > >Additionally, how can no bits be set? If this is a GMPLS interface, > > >then doesn't one of these bits HAVE to be set? > > > > Ack > > > > As it says... > > > > Setting no bits implies > > that GMPLS signaling cannot be performed on this interface and > > all LSPs must be manually provisioned or that this table entry > > is only present to supplement an entry in the > > mplsInterfaceTable > > by providing the information carried in other objects in this > > row. > > > > This means that we should change gmplsInterfaceEntry to read: > > > > "A conceptual row in this table is created automatically by an > > LSR for each interface that is both capable of supporting > > GMPLS and that is configured to support GMPLS. Note that > > support of GMPLS is not limited to control plane signaling, > > but may include data-plane only function configured through > > SNMP SET commands performed on this MIB module. > > > > A conceptual row in this table may also be created via SNMP > > SET commands or automatically by the LSR to supplement a > > conceptual row in the mplsInterfaceTable where the interface > > is not capable of GMPLS but where the other objects carried > > in this row provide useful additional information for an > > MPLS interface." > > If I could ask you to put your chair hat on for a minute, what are the > co-authors doing to get feedback from the MPLS working group on > objects which may apply to MPLS? > > Additionally, is this draft going to have a last call in the MPLS > working group? (maybe this is a question for the ADs). We can certainly poll the MPLS WG to see: a. if there are other attributes that need to be controlled and could be added to these modules b. if there are any further review comments Since the work form MPLS-TE is split between the MPLS and CCAMP working groups, it is usually assumed that anyone with an interest in MPLS-TE is following both working groups. Further, since GMPLS is a superset of MPLS-TE we can assume that anything that is needed for MPLS-TE is needed for GMPLS. But I will send mail, not as a formal last call, but to see if we can catch any more isues at this time. > Also, it seems this object would be more appropriate in the > GMPLS-TE-STD-MIB. Is there a reason for choosing the > GMPLS-LSR-STD-MIB for this object? The main reason is that this object desribes the capabilities of an LSR's interface. Included in this is the possilibity that the LSR does not support any signaling protocols on the interface but still supports LSPs (a la PVC). This makes this an LSR-related thing. Lastly, this object is part of the gmplsInterfaceTable which is an extension of the mplsInterfaceTable that appears in RFC3813, the MPLS-LSR-STD-MIB. > > >18) gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE > > > "Period, in milliseconds, between sending RSVP Hello messages > > > on > > > this interface. A value of 0 indicates that no Hello messages > > > should be sent on this interface." > > > > > >This object is only valid if the gmplsInterfaceSignalingCaps > > >object is set to rsvpGmpls. Please update the description > > >to reflect that. > > > > Nack > > It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB). > > Why is this object in this MIB as opposed to the GMPLS-TE-STD-MIB? > > I thought that GMPLS-TE-STD-MIB augmented the MPLS-TE-STD-MIB, > is that not the case? Exactly the point. RFC3812 does not contain per-interface objects. These are in RFC3813 in the MPLS-LSR-STD-MIB. You are correct that this object is protocol dependent and would not be used unless a TE protocol was in use (specifically RSVP-TE) unlike the previous object. Thus, we could introduce a per-interface table within the GMPLS-TE-STD-MIB to contain only this object, or we could leave it where it is with all of the other per-interface objects. Had there been more similar objects, I think we might have opted for this approach, but for one object it did not seem worth it. Do you feel strongly? > > >23) gmplsOutSegmentEntry OBJECT-TYPE > > >Same comments as with gmplsInSegmentEntry > > > > Nack > > Same answer > > Think you mean ack here? Oops, yes. > > >Section 8. GMPLS-LABEL-STD-MIB > > >=================================== > > > >31) gmplsLabelTable OBJECT-TYPE > > > > > >The last part of the last paragraph is awkward: > > > > > > "... Labels in the tables in other MIBs are referred to using > > > row pointer into this table. The indexing of this table > > > provides > > > for arbitrary indexing and also for concatenation of labels." > > > > > >Are you saying that other MIBs can use a row pointer to point to > > >this table? Why would they do that if they could just use the > > >indices directly? Also, I don't follow the comment about > > >concatenation of labels. Could you explain this? > > > > Nack > > Yes we are saying that other MIB modules can use a row pointer to > > point to this table. > > Yes they could use indices. This was the subject of a very lengthy > > discussion between the co-authors, etc., but in the end we > > observed that mplsInSegmentLabelPtr and mplsOutSegmentLabelPtr > > (RFC3813) are rowPointers so we had better support being pointed to. > > > > We could soften the language here by replacing "are" with "may". > > Yes, please. > > > Note, we should change this to say "MIB modules" > > > > good. > > > For an example of label concatenation see RFC3945 section 7.1. In > > essence, a GMPLS label may be composite in order to identify a set > > of resources in the data plane. Practial examples are timeslots > > and wavelength sets (which are not contiguous like wavebands). > > > > The indexing mechanism allows multiple entries in this table to be > > seen as a sequence of labels that should be concatenated. Ordering > > is potentially very sensitive for concatenation. > > > > It would be nice if you could add the above 2 paragraphs to the > DESCRIPTION. OK, will do. > > >32) gmplsLabelEntry OBJECT-TYPE > > > > > >The last sentence of the DESCRIPTION, please remove > > >the word "more" from the phrase "is more persistent." > > > > >I still don't understand how the subindex provides a way > > >to concatenate the labels. Could you give an example? > > > > Nack > > If you are asking for an example in the I-D, I don't think it is > > necessary. > > > > For your information, the composite label {{A}, {B}, {C}} might be > > constructed as... > > > > gmplsLabelInterface = 1 > > gmplsLabelIndex = 1 > > gmplsLabelSubindex = 1 > > gmplsLabelFreeform = A > > > > gmplsLabelInterface = 1 > > gmplsLabelIndex = 1 > > gmplsLabelSubindex = 2 > > gmplsLabelFreeform = B > > > > gmplsLabelInterface = 1 > > gmplsLabelIndex = 1 > > gmplsLabelSubindex = 3 > > gmplsLabelFreeform = C > > This is a good example and would, I think, be helpful someplace in the > document. This is only a suggestion however, and not a blocking issue. OK. We'll look at how to include an example in the pre-amble text (not the Description clasue). > > >34) gmplsLabelInterface OBJECT-TYPE > > > > > >DESCRIPTION also needs to specify that zero may be > > >used to indicate that the InterfaceIndex is not known > > >or that an InterfaceIndex exists but it is not important > > >wrt this implementation so zero is used. > > > > Nack > > The use of zero is very precisely specified at the moment. > > The reasons for setting zero that you cite are: > > - the InterfaceIndex is not known > > You cannot have a per-interface label space without knowing the > > interface to which it applies. > > - InterfaceIndex exists but it is not important wrt this > > implementation > > That is exactly the case of the global label space, and is already > > stated. > > I think you need to list all the reasons under which zero could be a > valid value for this index. You have listed more above which are not > specified in the description. Erm, but of the two reasons given above I have refuted one, and the other is specified in the descritpion. I can't think of a meaningful way to change the existing text. DESCRIPTION "The interface on which this label is used. If the label has or could have applicability across the whole system, this object SHOULD be set to zero." Perhaps we can re-order the words... DESCRIPTION "The interface on which this label is used. If this object is set to zero, the label has or could have applicability across the whole system and is not limited to a single interface." Does that help? > > > 35) gmplsLabelIndex OBJECT-TYPE > > > SYNTAX Unsigned32 (0..4294967295) > > > >36b)Please change the "may" to "should" in this statement: > > > A management application may read the gmplsLabelIndexNext > > > object to find a suitable value for this object." > > > > Nack > > Why "should" it do this? This is a convenience offered to it. It may > > use any mechanism it chooses including the one suggested in the > > quoted paragraph above. > > Without getting into a debate about tables and indexing, the > should is extremely appropriate. Think of the case where you have a > large number of rows in this table, do you expect a user to try a > bunch of numbers to create a row even if he/she has access to a CLI, > it will certainly be annoying to have to page through this table > and get to an available number. > > If a user consults the gmplsLabelIndexNext object then creating an > entry should be easier than not getting the gmplsLabelIndexNext > object. And if the implementation is using correlation of gmplsLabelIndex with the actual label ("Note that implementations that are representing 32 bit labels within this table MAY choose to align this index with the value of the label, but should be aware of the implications of sparsely populated tables.") then the use of gmplsLabelIndexNext would be completely inapproproriate because the correct value (dependent on the label actually assigned in hardware) comes from a different source. The use of "should" would curtail (a.k.a. break :-) this function. > > >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > > > > > >Please change the name to: gmplsLabelModuleReadOnlyCompliance > > >to be consistent with the other MPLS and GMPLS MIB modules. > > > > Nack > > I thought we tried to keep names down to 32 characters. I recall this > > conversation before. Not mandatory, but desirable. > > > > A choice between two desires? > > > > Please refer to Bert's comments on this. Agreed. > > >41) The ReadOnly compliance for gmplsLabelRowStatus > > >does NOT have a MIN-ACCESS of read-only. Is this > > >intentional? > > > > ??? > > Not sure about this. > > I thought the present of a WRITE-SYNTAX made some difference. > > Please refer to Bert's comments on this. Tom says he understands this, and will fix it. From owner-ccamp@ops.ietf.org Wed Sep 28 14:47:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKgxl-0007gM-SU for ccamp-archive@megatron.ietf.org; Wed, 28 Sep 2005 14:47:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28493 for ; Wed, 28 Sep 2005 14:47:28 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKh5H-0006Mk-92 for ccamp-archive@ietf.org; Wed, 28 Sep 2005 14:55:15 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKgoO-0009MB-1H for ccamp-data@psg.com; Wed, 28 Sep 2005 18:37:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [169.144.68.6] (helo=mailgate.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKgoM-0009Ly-U6 for ccamp@ops.ietf.org; Wed, 28 Sep 2005 18:37:47 +0000 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j8SIbBUk004699; Wed, 28 Sep 2005 14:37:11 -0400 (EDT) Received: from [169.144.136.107] (usvisdad104641.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20627; Wed, 28 Sep 2005 14:37:10 -0400 (EDT) Message-ID: <433AE2D5.5060405@marconi.com> Date: Wed, 28 Sep 2005 14:37:09 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MPLS List , IETF CCAMP List Subject: Graceful restart - inter-protocol dependencies Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Is there any point to implementing RSVP-TE's graceful restart without also implementing graceful restart for routing protocols? On the one hand, RSVP doesn't require routing to recover LSPs. It knows the next-hop interface, because of the preserved data-plane connection. Whatever other information it may need, the switch can either preserve this information or recover it from a neighbor using the RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03). On the other hand, nodes more than one hop upstream of the failure will detect the loss of routing-connectivity to the failed node if IGP graceful restart is not also implemented. They may reroute the LSP away from the failed node, or tear it down altogether, even though the data plane is still active and RSVP graceful restart is recovering the control-plane state. An originating node may consider the destination unreachable, as a result of losing the routes even though the data-plane for the LSP is still up (which can be confirmed via OAM.) A transit node, when processing an loose ERO-hop, may choose to reroute or fail the LSP if its local topology information says that the failed (and restarting) node is not available. It might even choose to do this for an established LSP, as a result of Path refresh processing. My questions are: 1: Does this mean it's pointless to use RSVP graceful restart without also using IGP graceful restart (for whatever IGP is active). 2: Is IGP graceful restart sufficient to prevent this problem? For instance, OSPF's restart procedure requires all preserved state to be thrown away if a topology change is detected. 3: An originating node can use OAM to validate the data plane of an LSP, and choose to ignore what routing tells it about the destination's reachability. But what about transit nodes? As far as I know, MPLS doesn't support segment-OAM, and it would be prohibitive for every transit node to run its own OAM streams to detect self-to-end connectivity. 4: Are there other solutions to this problem? One possible solution might be route-pinning, but RSVP doesn't have a built-in mechanism for this. The usual workaround (signal the LSP, requesting route-recording, then turn the RRO into an ERO for subsequent refreshes) can work, but are there situations where even this would be insufficient to prevent a transit node from rerouting/tearing the connection in this particular situation (where RSVP is doing a graceful restart but the IGP is not)? -- David From owner-ccamp@ops.ietf.org Wed Sep 28 16:39:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKihy-0004dg-BR for ccamp-archive@megatron.ietf.org; Wed, 28 Sep 2005 16:39:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11058 for ; Wed, 28 Sep 2005 16:39:16 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKipO-0002yU-2x for ccamp-archive@ietf.org; Wed, 28 Sep 2005 16:47:05 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKiZG-000K09-Hl for ccamp-data@psg.com; Wed, 28 Sep 2005 20:30:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.1.0 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKiZF-000Jzt-Bd for ccamp@ops.ietf.org; Wed, 28 Sep 2005 20:30:17 +0000 Received: from du-069-0342.access.clara.net ([217.158.145.88] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EKiZA-000Kzl-En for ccamp@ops.ietf.org; Wed, 28 Sep 2005 21:30:16 +0100 Message-ID: <032001c5c46b$d5867230$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Copy of a liaison from ITU-T SG15 to OIF Date: Wed, 28 Sep 2005 21:24:29 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_031B_01C5C473.02837560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 This is a multi-part message in MIME format. ------=_NextPart_000_031B_01C5C473.02837560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We have been copied on a liaison from ITU-T SG15 Q12 and Q14 to the OIF. The text is below. I will put a copy on the web at http://www.olddog.co.uk/ccamp.htm No action appears to be required from CCAMP at this stage. Thanks, Adrian =3D=3D=3D=3D=3D=3D=3D Source: ITU-T SG15 Q12, 14/15 Title: Response Liaison Statement to OIF on OIF Demo Finding To: Jim Jones, OIF Technical Committee Chair Cc: IETF CCAMP WG Co-chairs Approval:ITU-T SG15 Q14/15 Interim Meeting, Stuttgart (Germany), 18-22 = July 2005 For: Action Deadline:14 November 2005 Contact:Hing-Kam Lam (hklam@lucent.com) Contact:Malcolm Betts (betts01@nortel.com) =20 Thank you for sharing OIF UNI 2.0 work with SG15. For the Ethernet = feature, we note the alignment with the Ethernet series Recommendations = developed in SG15. We also appreciate the significant effort required = to accomplish the recent OIF Interoperability Demo, and some of the = issues that were identified in your liaison. As requested, please find our replies to the issues below. 1. Call identifier format sent by an originating UNI client. (Q14 only) Q14 agrees that the issue exists in G.7713.2 and accepts the OIF = recommendation to define that message for C-Type=3D0 in a future = G.7713.2 update. It should be noted that while G.7713.2 and RFC3474 = already specify the use C-type=3D0, a request to IANA for C-Type=3D0 was = accidentally neglected when processing RFC3474. This oversight needs to = be resolved. =20 2. Use of the NVC field for VCAT connections (Q14 only) There are two issues that have to be considered in this question. = First, in what order the VCAT vs server layer calls are created, and = second, if the server connections should be co-routed or not. When creating a VCAT call, the request could start from the client layer = which then results in the creation of server layer calls. In this case = when the server layer connections are created, it is known that they = will participate in a VCAT group (VCG). The opposite can also occur = where there are server layer connections are already in place and VCAT = call obtains them for the VCG. Here, no signalling in the server layer = is needed for the server layer calls. In the first case, setting the = NVC field could be done in the server layer calls as it is known that = they will be part of a VCAT call. In the second case, the original = signalling used did not know that the call would be part of a future = VCAT call and hence the NVC field remains zeroed. To accommodate the = case where existing connections are added to a VCG, it appears that the = NVC field is not relevant. In the SONET/SDH TSPEC where NVC is defined, the implied purpose is to = create LSP signalling state for single session that may have multiple = SONET/SDH connections that are in parallel. That is, when NVC is set to = >1, the expectation is that the connections are co-routed and they = follow the same link(s) and tandem switching points. To be able to use = more available bandwidth in the server layer, it is desirable to not = limit the connections in a VCG to be co-routed. In this scenario, each = connection is separately routed and a separate connection state is = needed per connection. To accommodate this degree of freedom, the NVC = field itself does not appear to be relevant to server layer signalling. Regarding H4 byte usage, note that it is the VCAT function that uses = this byte but only after the connection(s) is(are) created. So from a = signalling point of view, the server layer has no need to be aware that = the H4 byte is going to be used. Only the client layer (VCAT) needs to = be aware and trigger the use of the H4 byte. =20 3. TSPEC format to be used for Ethernet connections (Q12 and Q14) Q14 and Q12 think that a new Ethernet Traffic Parameters TSPEC in = RSVP-TE is the best long-term solution for specifying Ethernet bandwidth = service parameters and will request that CCAMP considers the = Q.8011/MEF.6 Ethernet service parameters and construct a suitable TSPEC = for it that can be used in the UNI. We also suggest that the OIF = similarly corresponds with CCAMP. =20 =20 An electronic copy of this liaison statement is available at: = ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICAT= IONS/index.html ------=_NextPart_000_031B_01C5C473.02837560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

We have been copied on a = liaison from=20 ITU-T SG15 Q12 and Q14 to the OIF.

The text is below.

I = will put a=20 copy on the web at http://www.olddog.co.uk/ccamp.htm

No action = appears to=20 be required from CCAMP at this=20 stage.

Thanks,
Adrian

=3D=3D=3D=3D=3D=3D=3D

Sourc= e:  ITU-T SG15=20 Q12, 14/15
Title:   Response Liaison Statement to OIF on = OIF Demo=20 Finding
To:      Jim Jones, OIF Technical = Committee=20 Chair
Cc:      IETF CCAMP WG=20 Co-chairs
Approval:ITU-T SG15 Q14/15 Interim Meeting, Stuttgart = (Germany),=20 18-22 July 2005
For:     Action
Deadline:14 = November=20 2005
Contact:Hing-Kam Lam (hklam@lucent.com)
Contact:Malcolm= =20 Betts (betts01@nortel.com)
 
T= hank you=20 for sharing OIF UNI 2.0 work with SG15.  For the Ethernet feature, = we note=20 the alignment with the Ethernet series Recommendations developed in = SG15. =20 We also appreciate the significant effort required to accomplish the = recent OIF=20 Interoperability Demo, and some of the issues that were identified in = your=20 liaison.

As requested, please find our replies to the issues = below.

1. Call identifier format sent by an originating UNI client. = (Q14=20 only)
Q14 agrees that the issue exists in G.7713.2 and accepts the OIF=20 recommendation to define that message for C-Type=3D0 in a future = G.7713.2 update.=20 It should be noted that while G.7713.2 and RFC3474 already specify the = use=20 C-type=3D0, a request to IANA for C-Type=3D0 was accidentally neglected = when=20 processing RFC3474. This oversight needs to be resolved.
 
2. = Use of=20 the NVC field for VCAT connections (Q14 only)
There are two issues that have to be considered in this = question. =20 First, in what order the VCAT vs server layer calls are created, and = second, if=20 the server connections should be co-routed or not.
When creating a VCAT call, the request could start from the client = layer=20 which then results in the creation of server layer calls.  In this = case=20 when the server layer connections are created, it is known that they = will=20 participate in a VCAT group (VCG).  The opposite can also occur = where there=20 are server layer connections are already in place and VCAT call obtains = them for=20 the VCG.  Here, no signalling in the server layer is needed for the = server=20 layer calls.  In the first case, setting the NVC field could be = done in the=20 server layer calls as it is known that they will be part of a VCAT = call. =20 In the second case, the original signalling used did not know that the = call=20 would be part of a future VCAT call and hence the NVC field remains=20 zeroed.  To accommodate the case where existing connections are = added to a=20 VCG, it appears that the NVC field is not relevant.
In the SONET/SDH TSPEC where NVC is defined, the implied purpose is = to=20 create LSP signalling state for single session that may have multiple = SONET/SDH=20 connections that are in parallel.  That is, when NVC is set to = >1, the=20 expectation is that the connections are co-routed and they follow the = same=20 link(s) and tandem switching points.  To be able to use more = available=20 bandwidth in the server layer, it is desirable to not limit the = connections in a=20 VCG to be co-routed.  In this scenario, each connection is = separately=20 routed and a separate connection state is needed per connection.  = To=20 accommodate this degree of freedom, the NVC field itself does not appear = to be=20 relevant to server layer signalling.
Regarding H4 byte usage, note = that it is=20 the VCAT function that uses this byte but only after the connection(s) = is(are)=20 created.  So from a signalling point of view, the server layer has = no need=20 to be aware that the H4 byte is going to be used.  Only the client = layer=20 (VCAT) needs to be aware and trigger the use of the H4 = byte.
 
3.=20 TSPEC format to be used for Ethernet connections (Q12 and Q14)
Q14 and Q12 think that a new Ethernet Traffic Parameters TSPEC in = RSVP-TE=20 is the best long-term solution for specifying Ethernet bandwidth service = parameters and will request that CCAMP considers the Q.8011/MEF.6 = Ethernet=20 service parameters and construct a suitable TSPEC for it that can be = used in the=20 UNI. We also suggest that the OIF similarly corresponds with=20 CCAMP.
 
 
An electronic copy of this liaison = statement is=20 available at:=20 ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICAT= IONS/index.html=20
------=_NextPart_000_031B_01C5C473.02837560-- From owner-ccamp@ops.ietf.org Thu Sep 29 06:06:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKvIu-0005HW-JO for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 06:06:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00788 for ; Thu, 29 Sep 2005 06:06:13 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKvQU-00056o-Q4 for ccamp-archive@ietf.org; Thu, 29 Sep 2005 06:14:10 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKuwr-0006UI-Ii for ccamp-data@psg.com; Thu, 29 Sep 2005 09:43:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [217.32.164.151] (helo=smtp4.smtp.bt.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKuwq-0006U4-Iu for ccamp@ops.ietf.org; Thu, 29 Sep 2005 09:43:28 +0000 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 10:43:26 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Sep 2005 10:43:26 +0100 x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Graceful restart - inter-protocol dependencies Date: Thu, 29 Sep 2005 10:43:26 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A3538911790669@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Graceful restart - inter-protocol dependencies Thread-Index: AcXEW+1F1lvn6K7+Sf+nx1sLCgITFgAeyW6A From: To: , , X-OriginalArrivalTime: 29 Sep 2005 09:43:26.0670 (UTC) FILETIME=[3DAEAEE0:01C5C4DA] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable David, This is a very interesting/thoughtful mail. When I read it I was immediately struck by recent discussions some of us have been having on the topic of unified functional modelling within SG15, ie the underlying axiomatic truths that stem directly from Shannon/Turing wrt networking and that show how the co-cs, co-ps and cl-ps networking modes all have a common root. However, whilst I don't want to get into that here I do want to illustrate a key consequence of this work that is particularly relevant to your observations. In the co modes we have this rather important object called a trail. A trail is, in essence, a concatenated sequence of link-connections and nodes (which are the smallest subnetwork connections). However, the key observation is that at the epoch we create the trail we remove all further routing choices from the trail. You can almost think of this as effectively removing the trail from its parent network topology (there is a resource accounting issue to deal with, but that is a different point).....and I guess in IETF speak one would call this 'route-pinning'. What this means is that it does not matter what happens to the routing process after this epoch, once the trail is established there is no need to move it. And a key example of why this is important is the case of augmenting the network topology by adding further nodes/links. Because the network topology has now changed then future routing decisions are very likely to alter. But in the co mode case this does not matter....once a trail is created it remains faithful to its original routing choice unless we consciously decide to move it (which may of course be the result of failures or planned works). Now contrast this with the cl mode case. If we augment a cl network by adding new nodes/links then the routing process will update and traffic will move in accordance with whatever is the optimal path.=20 Note a trail has other key properties, eg it allows one to completely decouple a survivability semantic from the QoS semantics of client traffic units. This property is rather important when one offering a network builder service to customers. regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of David Charlap > Sent: 28 September 2005 19:37 > To: IETF MPLS List; IETF CCAMP List > Subject: Graceful restart - inter-protocol dependencies >=20 >=20 > Is there any point to implementing RSVP-TE's graceful restart without=20 > also implementing graceful restart for routing protocols? >=20 > On the one hand, RSVP doesn't require routing to recover=20 > LSPs. It knows=20 > the next-hop interface, because of the preserved data-plane=20 > connection.=20 > Whatever other information it may need, the switch can=20 > either preserve=20 > this information or recover it from a neighbor using the RecoveryPath=20 > object (draft-ietf-ccamp-rsvo-restart-ext-03). >=20 > On the other hand, nodes more than one hop upstream of the=20 > failure will=20 > detect the loss of routing-connectivity to the failed node if IGP=20 > graceful restart is not also implemented. They may reroute=20 > the LSP away=20 > from the failed node, or tear it down altogether, even though=20 > the data=20 > plane is still active and RSVP graceful restart is recovering the=20 > control-plane state. >=20 > An originating node may consider the destination unreachable, as a=20 > result of losing the routes even though the data-plane for the LSP is=20 > still up (which can be confirmed via OAM.) >=20 > A transit node, when processing an loose ERO-hop, may choose=20 > to reroute=20 > or fail the LSP if its local topology information says that=20 > the failed=20 > (and restarting) node is not available. It might even choose=20 > to do this=20 > for an established LSP, as a result of Path refresh processing. >=20 > My questions are: >=20 > 1: Does this mean it's pointless to use RSVP graceful restart without > also using IGP graceful restart (for whatever IGP is active). >=20 > 2: Is IGP graceful restart sufficient to prevent this problem? For > instance, OSPF's restart procedure requires all preserved state to > be thrown away if a topology change is detected. >=20 > 3: An originating node can use OAM to validate the data plane of an > LSP, and choose to ignore what routing tells it about the > destination's reachability. But what about transit nodes? As far > as I know, MPLS doesn't support segment-OAM, and it would be > prohibitive for every transit node to run its own OAM streams > to detect self-to-end connectivity. >=20 > 4: Are there other solutions to this problem? >=20 > One possible solution might be route-pinning, but RSVP doesn't have a=20 > built-in mechanism for this. The usual workaround (signal the LSP,=20 > requesting route-recording, then turn the RRO into an ERO for=20 > subsequent=20 > refreshes) can work, but are there situations where even this=20 > would be=20 > insufficient to prevent a transit node from rerouting/tearing the=20 > connection in this particular situation (where RSVP is doing=20 > a graceful=20 > restart but the IGP is not)? >=20 > -- David >=20 >=20 From owner-ccamp@ops.ietf.org Thu Sep 29 11:00:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKztO-0002b4-T5 for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 11:00:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17493 for ; Thu, 29 Sep 2005 11:00:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL010-0004bW-OF for ccamp-archive@ietf.org; Thu, 29 Sep 2005 11:08:11 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKzVC-0005ik-Bi for ccamp-data@psg.com; Thu, 29 Sep 2005 14:35:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [169.144.68.6] (helo=mailgate.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKzVB-0005iT-95 for ccamp@ops.ietf.org; Thu, 29 Sep 2005 14:35:13 +0000 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j8TEYeUk021488; Thu, 29 Sep 2005 10:34:40 -0400 (EDT) Received: from [169.144.136.107] (usvisdad104641.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01186; Thu, 29 Sep 2005 10:34:39 -0400 (EDT) Message-ID: <433BFB7F.7050107@marconi.com> Date: Thu, 29 Sep 2005 10:34:39 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'IETF MPLS List'" , "'IETF CCAMP List'" Subject: Re: Graceful restart - inter-protocol dependencies References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit But RSVP doesn't work this way. It is a soft-state protocol. If the route table changes such that the next-hop interface changes, RSVP is supposed to reroute the connection accordingly. This probably won't happen if the next-hop is a strict-hop in an ERO, but it can easily happen if the next-hop is loose or if the LSP is signaled without an ERO (meaning routing is consulted to determine the next-hop to the egress node.) If there is a paragraph in an RFC that says RSVP-TE should ignore all route-table changes once an LSP comes up, I missed it. -- David Jing Ruiquan wrote: > I think only the originating node should do the rerouting with RSVP-TE .At > the same time, all the nodes will converge their IGP routing data base. > > Rick > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of David Charlap > Sent: Thursday, September 29, 2005 2:37 AM > To: IETF MPLS List; IETF CCAMP List > Subject: Graceful restart - inter-protocol dependencies > > Is there any point to implementing RSVP-TE's graceful restart without also > implementing graceful restart for routing protocols? > > On the one hand, RSVP doesn't require routing to recover LSPs. It knows the > next-hop interface, because of the preserved data-plane connection. > Whatever other information it may need, the switch can either preserve > this information or recover it from a neighbor using the RecoveryPath object > (draft-ietf-ccamp-rsvo-restart-ext-03). > > On the other hand, nodes more than one hop upstream of the failure will > detect the loss of routing-connectivity to the failed node if IGP graceful > restart is not also implemented. They may reroute the LSP away from the > failed node, or tear it down altogether, even though the data plane is still > active and RSVP graceful restart is recovering the control-plane state. > > An originating node may consider the destination unreachable, as a result of > losing the routes even though the data-plane for the LSP is still up (which > can be confirmed via OAM.) > > A transit node, when processing an loose ERO-hop, may choose to reroute or > fail the LSP if its local topology information says that the failed (and > restarting) node is not available. It might even choose to do this for an > established LSP, as a result of Path refresh processing. > > My questions are: > > 1: Does this mean it's pointless to use RSVP graceful restart without > also using IGP graceful restart (for whatever IGP is active). > > 2: Is IGP graceful restart sufficient to prevent this problem? For > instance, OSPF's restart procedure requires all preserved state to > be thrown away if a topology change is detected. > > 3: An originating node can use OAM to validate the data plane of an > LSP, and choose to ignore what routing tells it about the > destination's reachability. But what about transit nodes? As far > as I know, MPLS doesn't support segment-OAM, and it would be > prohibitive for every transit node to run its own OAM streams > to detect self-to-end connectivity. > > 4: Are there other solutions to this problem? > > One possible solution might be route-pinning, but RSVP doesn't have a > built-in mechanism for this. The usual workaround (signal the LSP, > requesting route-recording, then turn the RRO into an ERO for subsequent > refreshes) can work, but are there situations where even this would be > insufficient to prevent a transit node from rerouting/tearing the connection > in this particular situation (where RSVP is doing a graceful restart but the > IGP is not)? > > -- David From owner-ccamp@ops.ietf.org Thu Sep 29 11:00:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKztP-0002b6-1i for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 11:00:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17494 for ; Thu, 29 Sep 2005 11:00:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL010-0004bV-OB for ccamp-archive@ietf.org; Thu, 29 Sep 2005 11:08:11 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKzaH-0006Fh-9Z for ccamp-data@psg.com; Thu, 29 Sep 2005 14:40:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [169.144.68.6] (helo=mailgate.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKzaG-0006FS-71 for ccamp@ops.ietf.org; Thu, 29 Sep 2005 14:40:28 +0000 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j8TEduUk021677; Thu, 29 Sep 2005 10:39:56 -0400 (EDT) Received: from [169.144.136.107] (usvisdad104641.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA01878; Thu, 29 Sep 2005 10:39:56 -0400 (EDT) Message-ID: <433BFCBC.70002@marconi.com> Date: Thu, 29 Sep 2005 10:39:56 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, ccamp@ops.ietf.org Subject: Re: Graceful restart - inter-protocol dependencies References: <0536FC9B908BEC4597EE721BE6A3538911790669@i2km07-ukbr.domain1.systemhost.net> In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538911790669@i2km07-ukbr.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit You're absolutely right that this is how co networks should operate. I would agree that there is little point to rerouting an LSP that has data-plane connectivity, even if routing says the path is invalid or suboptimal. Unfortunately, I don't think current MPLS signaling protocols (RSVP-TE and LDP) work this way. LDP is explicitly designed to dynamically change as routing changes. RSVP-TE seems (to my best understanding) to also react to routing changes, except for special cases (like when signaled with an ERO consisting entirely of strict nodes whose addresses can be resolved from interface-neighbor information instead of from routing.) -- David neil.2.harrison@bt.com wrote: > David, > > This is a very interesting/thoughtful mail. When I read it I was > immediately struck by recent discussions some of us have been having on > the topic of unified functional modelling within SG15, ie the underlying > axiomatic truths that stem directly from Shannon/Turing wrt networking > and that show how the co-cs, co-ps and cl-ps networking modes all have a > common root. However, whilst I don't want to get into that here I do > want to illustrate a key consequence of this work that is particularly > relevant to your observations. > > In the co modes we have this rather important object called a trail. A > trail is, in essence, a concatenated sequence of link-connections and > nodes (which are the smallest subnetwork connections). However, the key > observation is that at the epoch we create the trail we remove all > further routing choices from the trail. You can almost think of this as > effectively removing the trail from its parent network topology (there > is a resource accounting issue to deal with, but that is a different > point).....and I guess in IETF speak one would call this > 'route-pinning'. > > What this means is that it does not matter what happens to the routing > process after this epoch, once the trail is established there is no need > to move it. And a key example of why this is important is the case of > augmenting the network topology by adding further nodes/links. Because > the network topology has now changed then future routing decisions are > very likely to alter. But in the co mode case this does not > matter....once a trail is created it remains faithful to its original > routing choice unless we consciously decide to move it (which may of > course be the result of failures or planned works). > > Now contrast this with the cl mode case. If we augment a cl network by > adding new nodes/links then the routing process will update and traffic > will move in accordance with whatever is the optimal path. > > Note a trail has other key properties, eg it allows one to completely > decouple a survivability semantic from the QoS semantics of client > traffic units. This property is rather important when one offering a > network builder service to customers. > > regards, Neil > > > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of David Charlap >>Sent: 28 September 2005 19:37 >>To: IETF MPLS List; IETF CCAMP List >>Subject: Graceful restart - inter-protocol dependencies >> >> >>Is there any point to implementing RSVP-TE's graceful restart without >>also implementing graceful restart for routing protocols? >> >>On the one hand, RSVP doesn't require routing to recover >>LSPs. It knows >>the next-hop interface, because of the preserved data-plane >>connection. >> Whatever other information it may need, the switch can >>either preserve >>this information or recover it from a neighbor using the RecoveryPath >>object (draft-ietf-ccamp-rsvo-restart-ext-03). >> >>On the other hand, nodes more than one hop upstream of the >>failure will >>detect the loss of routing-connectivity to the failed node if IGP >>graceful restart is not also implemented. They may reroute >>the LSP away >>from the failed node, or tear it down altogether, even though >>the data >>plane is still active and RSVP graceful restart is recovering the >>control-plane state. >> >>An originating node may consider the destination unreachable, as a >>result of losing the routes even though the data-plane for the LSP is >>still up (which can be confirmed via OAM.) >> >>A transit node, when processing an loose ERO-hop, may choose >>to reroute >>or fail the LSP if its local topology information says that >>the failed >>(and restarting) node is not available. It might even choose >>to do this >>for an established LSP, as a result of Path refresh processing. >> >>My questions are: >> >>1: Does this mean it's pointless to use RSVP graceful restart without >> also using IGP graceful restart (for whatever IGP is active). >> >>2: Is IGP graceful restart sufficient to prevent this problem? For >> instance, OSPF's restart procedure requires all preserved state to >> be thrown away if a topology change is detected. >> >>3: An originating node can use OAM to validate the data plane of an >> LSP, and choose to ignore what routing tells it about the >> destination's reachability. But what about transit nodes? As far >> as I know, MPLS doesn't support segment-OAM, and it would be >> prohibitive for every transit node to run its own OAM streams >> to detect self-to-end connectivity. >> >>4: Are there other solutions to this problem? >> >>One possible solution might be route-pinning, but RSVP doesn't have a >>built-in mechanism for this. The usual workaround (signal the LSP, >>requesting route-recording, then turn the RRO into an ERO for >>subsequent >>refreshes) can work, but are there situations where even this >>would be >>insufficient to prevent a transit node from rerouting/tearing the >>connection in this particular situation (where RSVP is doing >>a graceful >>restart but the IGP is not)? >> >>-- David >> >> From owner-ccamp@ops.ietf.org Thu Sep 29 11:06:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKzzn-0004ah-II for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 11:06:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17798 for ; Thu, 29 Sep 2005 11:06:48 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL07H-0004lo-Gt for ccamp-archive@ietf.org; Thu, 29 Sep 2005 11:14:36 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EKzk8-0007LY-E5 for ccamp-data@psg.com; Thu, 29 Sep 2005 14:50:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EKzk7-0007Kx-H9 for ccamp@ops.ietf.org; Thu, 29 Sep 2005 14:50:39 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Sep 2005 07:50:39 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,157,1125903600"; d="scan'208"; a="11753940:sNHT22937740" Received: from cisco.com (shaqzilla.cisco.com [161.44.70.33]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8TEoaQl011271; Thu, 29 Sep 2005 10:50:36 -0400 (EDT) Received: from shaqzilla.cisco.com (localhost.localdomain [127.0.0.1]) by cisco.com (8.12.11/8.12.11) with ESMTP id j8TEoa5v018894; Thu, 29 Sep 2005 10:50:36 -0400 Received: (from ashokn@localhost) by shaqzilla.cisco.com (8.12.11/8.12.11/Submit) id j8TEoZpj018892; Thu, 29 Sep 2005 10:50:35 -0400 Date: Thu, 29 Sep 2005 10:50:35 -0400 From: Ashok Narayanan To: David Charlap Cc: "'IETF MPLS List'" , "'IETF CCAMP List'" Subject: Re: Graceful restart - inter-protocol dependencies Message-ID: <20050929145035.GP28771@cisco.com> References: <433BFB7F.7050107@marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433BFB7F.7050107@marconi.com> User-Agent: Mutt/1.4.2.1i Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Strict EROs are used in the vast majority of MPLS/TE deployments. Even Loose ERO hops tend to get expanded into strict EROs (e.g at ASBRs); and extensions such as PCE are all designed to move path calculation to a single point rather than doing it hop-by-hop. The problem with hop-by-hop routing is that you can only have LSPs track the best IP route, rather than the best "engineered" route through the network. However, the problem you've described is an interesting one for regular IPv4 RSVP (for QoS), though not necessarily for MPLS/TE. -Ashok On Thu, Sep 29, 2005 at 10:34:39AM -0400, David Charlap wrote: > But RSVP doesn't work this way. It is a soft-state protocol. > > If the route table changes such that the next-hop interface changes, > RSVP is supposed to reroute the connection accordingly. > > This probably won't happen if the next-hop is a strict-hop in an ERO, > but it can easily happen if the next-hop is loose or if the LSP is > signaled without an ERO (meaning routing is consulted to determine the > next-hop to the egress node.) > > If there is a paragraph in an RFC that says RSVP-TE should ignore all > route-table changes once an LSP comes up, I missed it. > > -- David > > Jing Ruiquan wrote: > >I think only the originating node should do the rerouting with RSVP-TE .At > >the same time, all the nodes will converge their IGP routing data base. > > > >Rick > > > >-----Original Message----- > >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > >Of David Charlap > >Sent: Thursday, September 29, 2005 2:37 AM > >To: IETF MPLS List; IETF CCAMP List > >Subject: Graceful restart - inter-protocol dependencies > > > >Is there any point to implementing RSVP-TE's graceful restart without also > >implementing graceful restart for routing protocols? > > > >On the one hand, RSVP doesn't require routing to recover LSPs. It knows > >the > >next-hop interface, because of the preserved data-plane connection. > > Whatever other information it may need, the switch can either preserve > >this information or recover it from a neighbor using the RecoveryPath > >object > >(draft-ietf-ccamp-rsvo-restart-ext-03). > > > >On the other hand, nodes more than one hop upstream of the failure will > >detect the loss of routing-connectivity to the failed node if IGP graceful > >restart is not also implemented. They may reroute the LSP away from the > >failed node, or tear it down altogether, even though the data plane is > >still > >active and RSVP graceful restart is recovering the control-plane state. > > > >An originating node may consider the destination unreachable, as a result > >of > >losing the routes even though the data-plane for the LSP is still up (which > >can be confirmed via OAM.) > > > >A transit node, when processing an loose ERO-hop, may choose to reroute or > >fail the LSP if its local topology information says that the failed (and > >restarting) node is not available. It might even choose to do this for an > >established LSP, as a result of Path refresh processing. > > > >My questions are: > > > >1: Does this mean it's pointless to use RSVP graceful restart without > > also using IGP graceful restart (for whatever IGP is active). > > > >2: Is IGP graceful restart sufficient to prevent this problem? For > > instance, OSPF's restart procedure requires all preserved state to > > be thrown away if a topology change is detected. > > > >3: An originating node can use OAM to validate the data plane of an > > LSP, and choose to ignore what routing tells it about the > > destination's reachability. But what about transit nodes? As far > > as I know, MPLS doesn't support segment-OAM, and it would be > > prohibitive for every transit node to run its own OAM streams > > to detect self-to-end connectivity. > > > >4: Are there other solutions to this problem? > > > >One possible solution might be route-pinning, but RSVP doesn't have a > >built-in mechanism for this. The usual workaround (signal the LSP, > >requesting route-recording, then turn the RRO into an ERO for subsequent > >refreshes) can work, but are there situations where even this would be > >insufficient to prevent a transit node from rerouting/tearing the > >connection > >in this particular situation (where RSVP is doing a graceful restart but > >the > >IGP is not)? > > > >-- David -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) From owner-ccamp@ops.ietf.org Thu Sep 29 11:46:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0cG-0006Rs-9F for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 11:46:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19540 for ; Thu, 29 Sep 2005 11:46:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL0js-0005hQ-EN for ccamp-archive@ietf.org; Thu, 29 Sep 2005 11:54:33 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EL0T7-000Bro-EA for ccamp-data@psg.com; Thu, 29 Sep 2005 15:37:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [217.32.164.151] (helo=smtp4.smtp.bt.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EL0T4-000Br7-KI for ccamp@ops.ietf.org; Thu, 29 Sep 2005 15:37:06 +0000 Received: from i2km99-ukbr.domain1.systemhost.net ([193.113.197.31]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 16:37:04 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km99-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Sep 2005 16:37:04 +0100 x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Graceful restart - inter-protocol dependencies Date: Thu, 29 Sep 2005 16:37:04 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389118004E7@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Graceful restart - inter-protocol dependencies Thread-Index: AcXFA/+QPkt5glu/Qzm6K/i6F7bBbgAAQZew From: To: , , X-OriginalArrivalTime: 29 Sep 2005 15:37:04.0658 (UTC) FILETIME=[A496B720:01C5C50B] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: quoted-printable Thanks David....it's not simply how they *should* work its how they *must* work if one wants to be able to offer network services to customers that have deterministic behaviour, ie one has precise (and it also should be simple) control over traffic/fault/performance management facets. A full service operator like BT needs all 3 networking modes working in concert...and they are for sure different. Understanding *why* they are different at fundamental level has taken us a while to properly figure out. However, the stuff we knew was intuitively right is now getting placed on a far stronger foundation of underlying 'truths' because of the unified modelling work I mentioned (this goes right back to Shannon and Turing stuff...indeed a network is precisely the union of Information Theory and a computing machine). The GMPLS co-cs stuff is largely self-protecting of abuse.....this is down to the nature of the constraints that define this mode (esp the labelling). Same can be said for the cl-ps mode. The major risks arise with the co-ps mode....and one can make life very complex here if one is not careful.....I'll resist the strong temptation to flesh this out wrt comments on MPLS and the PW stuff.=20 However, we do need a correctly specified co-ps mode networking capability because as we sun-set many of our legacy co-cs and co-ps technologies there is a major gap opening for a lower granularity (than SDH VC4) network builder capability....and we have many customers who demand such a network service. regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of David Charlap > Sent: 29 September 2005 15:40 > To: mpls@lists.ietf.org; ccamp@ops.ietf.org > Subject: Re: Graceful restart - inter-protocol dependencies >=20 >=20 > You're absolutely right that this is how co networks should=20 > operate. I=20 > would agree that there is little point to rerouting an LSP that has=20 > data-plane connectivity, even if routing says the path is invalid or=20 > suboptimal. >=20 > Unfortunately, I don't think current MPLS signaling protocols=20 > (RSVP-TE=20 > and LDP) work this way. LDP is explicitly designed to dynamically=20 > change as routing changes. >=20 > RSVP-TE seems (to my best understanding) to also react to routing=20 > changes, except for special cases (like when signaled with an ERO=20 > consisting entirely of strict nodes whose addresses can be=20 > resolved from=20 > interface-neighbor information instead of from routing.) >=20 > -- David >=20 >=20 > neil.2.harrison@bt.com wrote: > > David, > >=20 > > This is a very interesting/thoughtful mail. When I read it I was=20 > > immediately struck by recent discussions some of us have=20 > been having=20 > > on the topic of unified functional modelling within SG15, ie the=20 > > underlying axiomatic truths that stem directly from=20 > Shannon/Turing wrt=20 > > networking and that show how the co-cs, co-ps and cl-ps networking=20 > > modes all have a common root. However, whilst I don't want to get=20 > > into that here I do want to illustrate a key consequence of=20 > this work=20 > > that is particularly relevant to your observations. > >=20 > > In the co modes we have this rather important object called=20 > a trail. =20 > > A trail is, in essence, a concatenated sequence of link-connections=20 > > and nodes (which are the smallest subnetwork connections). =20 > However,=20 > > the key observation is that at the epoch we create the=20 > trail we remove=20 > > all further routing choices from the trail. You can almost=20 > think of=20 > > this as effectively removing the trail from its parent network=20 > > topology (there is a resource accounting issue to deal=20 > with, but that=20 > > is a different point).....and I guess in IETF speak one would call=20 > > this 'route-pinning'. > >=20 > > What this means is that it does not matter what happens to=20 > the routing=20 > > process after this epoch, once the trail is established there is no=20 > > need to move it. And a key example of why this is important is the=20 > > case of augmenting the network topology by adding further=20 > nodes/links. =20 > > Because the network topology has now changed then future routing=20 > > decisions are very likely to alter. But in the co mode=20 > case this does=20 > > not matter....once a trail is created it remains faithful to its=20 > > original routing choice unless we consciously decide to=20 > move it (which=20 > > may of course be the result of failures or planned works). > >=20 > > Now contrast this with the cl mode case. If we augment a cl=20 > network by=20 > > adding new nodes/links then the routing process will update and=20 > > traffic will move in accordance with whatever is the optimal path. > >=20 > > Note a trail has other key properties, eg it allows one to=20 > completely=20 > > decouple a survivability semantic from the QoS semantics of client=20 > > traffic units. This property is rather important when one=20 > offering a=20 > > network builder service to customers. > >=20 > > regards, Neil > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: owner-ccamp@ops.ietf.org > >>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of David Charlap > >>Sent: 28 September 2005 19:37 > >>To: IETF MPLS List; IETF CCAMP List > >>Subject: Graceful restart - inter-protocol dependencies > >> > >> > >>Is there any point to implementing RSVP-TE's graceful=20 > restart without > >>also implementing graceful restart for routing protocols? > >> > >>On the one hand, RSVP doesn't require routing to recover > >>LSPs. It knows=20 > >>the next-hop interface, because of the preserved data-plane=20 > >>connection.=20 > >> Whatever other information it may need, the switch can=20 > >>either preserve=20 > >>this information or recover it from a neighbor using the=20 > RecoveryPath=20 > >>object (draft-ietf-ccamp-rsvo-restart-ext-03). > >> > >>On the other hand, nodes more than one hop upstream of the > >>failure will=20 > >>detect the loss of routing-connectivity to the failed node if IGP=20 > >>graceful restart is not also implemented. They may reroute=20 > >>the LSP away=20 > >>from the failed node, or tear it down altogether, even though=20 > >>the data=20 > >>plane is still active and RSVP graceful restart is recovering the=20 > >>control-plane state. > >> > >>An originating node may consider the destination unreachable, as a > >>result of losing the routes even though the data-plane for=20 > the LSP is=20 > >>still up (which can be confirmed via OAM.) > >> > >>A transit node, when processing an loose ERO-hop, may choose > >>to reroute=20 > >>or fail the LSP if its local topology information says that=20 > >>the failed=20 > >>(and restarting) node is not available. It might even choose=20 > >>to do this=20 > >>for an established LSP, as a result of Path refresh processing. > >> > >>My questions are: > >> > >>1: Does this mean it's pointless to use RSVP graceful=20 > restart without > >> also using IGP graceful restart (for whatever IGP is active). > >> > >>2: Is IGP graceful restart sufficient to prevent this problem? For > >> instance, OSPF's restart procedure requires all=20 > preserved state to > >> be thrown away if a topology change is detected. > >> > >>3: An originating node can use OAM to validate the data plane of an > >> LSP, and choose to ignore what routing tells it about the > >> destination's reachability. But what about transit=20 > nodes? As far > >> as I know, MPLS doesn't support segment-OAM, and it would be > >> prohibitive for every transit node to run its own OAM streams > >> to detect self-to-end connectivity. > >> > >>4: Are there other solutions to this problem? > >> > >>One possible solution might be route-pinning, but RSVP=20 > doesn't have a > >>built-in mechanism for this. The usual workaround (signal the LSP,=20 > >>requesting route-recording, then turn the RRO into an ERO for=20 > >>subsequent=20 > >>refreshes) can work, but are there situations where even this=20 > >>would be=20 > >>insufficient to prevent a transit node from rerouting/tearing the=20 > >>connection in this particular situation (where RSVP is doing=20 > >>a graceful=20 > >>restart but the IGP is not)? > >> > >>-- David > >> > >> >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Thu Sep 29 12:13:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL12E-0003Vm-1c for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 12:13:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20633 for ; Thu, 29 Sep 2005 12:13:22 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL19l-0006Kx-14 for ccamp-archive@ietf.org; Thu, 29 Sep 2005 12:21:23 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EL0sd-000Exw-GG for ccamp-data@psg.com; Thu, 29 Sep 2005 16:03:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_20, RCVD_IN_BL_SPAMCOP_NET autolearn=no version=3.1.0 Received: from [38.113.3.71] (helo=smtp-out.hotpop.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EL0sb-000Exc-3H for ccamp@ops.ietf.org; Thu, 29 Sep 2005 16:03:29 +0000 Received: from hotpop.com (kubrick.hotpop.com [38.113.3.105]) by smtp-out.hotpop.com (Postfix) with SMTP id DE73A1945474 for ; Thu, 29 Sep 2005 16:03:23 +0000 (UTC) Received: from ALOKLXP (unknown [202.144.106.188]) by smtp-3.hotpop.com (Postfix) with ESMTP id BFBC81946A35 for ; Thu, 29 Sep 2005 16:03:21 +0000 (UTC) Message-ID: <00d101c5c50f$23320870$300218ac@rs.riverstonenet.com> From: "Alok" To: Subject: questions Date: Thu, 29 Sep 2005 21:32:01 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com ----------------------------------------------- Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 2.2 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit I may speak on behalf of a lot of friends/youngsters who do have questions related to the bases of how Muxing works.. and trying to understand the various VCs and containers and the reason they exist. Is it ok for new comers, who really dont understand transmissions and all those VT pointers to ask questions on the list.... -thanks Alok From owner-ccamp@ops.ietf.org Thu Sep 29 14:09:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL2qc-00037g-Pe for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 14:09:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26033 for ; Thu, 29 Sep 2005 14:09:32 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL2yK-0000nz-Fv for ccamp-archive@ietf.org; Thu, 29 Sep 2005 14:17:33 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EL2ii-0003RO-FU for ccamp-data@psg.com; Thu, 29 Sep 2005 18:01:24 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [169.144.68.6] (helo=mailgate.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EL2ig-0003Qr-Th for ccamp@ops.ietf.org; Thu, 29 Sep 2005 18:01:23 +0000 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j8TI0oUk026885; Thu, 29 Sep 2005 14:00:50 -0400 (EDT) Received: from [169.144.136.107] (usvisdad104641.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA01177; Thu, 29 Sep 2005 14:00:50 -0400 (EDT) Message-ID: <433C2BD1.4010104@marconi.com> Date: Thu, 29 Sep 2005 14:00:49 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MPLS List , IETF CCAMP List Subject: Re: Graceful restart - inter-protocol dependencies References: <433BFB7F.7050107@marconi.com> <6280db52050929104647919cbe@mail.gmail.com> In-Reply-To: <6280db52050929104647919cbe@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: 7bit When processing a loose hop, or even a strict hop with an address that is not an interface-neighbor address, RSVP relies on the route table to determine the next-hop interface (and possibly also the next-hop address.) How is it right to ignore route changes after this? If the route table changes such that the selected next-hop interface is no longer the best (or is no longer valid), should RSVP ignore this? It seems to me like this could end up blackholing traffic in a way that will not be detectable without OAM. The last I heard, network operators were not required to run OAM on every LSP. Has this changed? -- David Alia Atlas wrote: > David, > > In ref to RSVP-TE, a part of the question is who notices the routing > change and does > the reroute. In general, the idea of make-before-break and control by > the ingress apply. > > For a midpoint, a change to an LSP would be triggered by either the RSVP > PATH > message changing or by the selected next-hop interface no longer being > available. > Theoretically, a midpoint LSR could register for route changes to the > specified next-hop, > but to what purpose?? Once the midpoint LSR has determined the next-hop > interface, I'd > expect that to be treated as a strict hop, inside the LSR at least. > > Alia > > > On 9/29/05, *David Charlap* > wrote: > > But RSVP doesn't work this way. It is a soft-state protocol. > > If the route table changes such that the next-hop interface changes, > RSVP is supposed to reroute the connection accordingly. > > This probably won't happen if the next-hop is a strict-hop in an ERO, > but it can easily happen if the next-hop is loose or if the LSP is > signaled without an ERO (meaning routing is consulted to determine the > next-hop to the egress node.) > > If there is a paragraph in an RFC that says RSVP-TE should ignore all > route-table changes once an LSP comes up, I missed it. > > -- David > > Jing Ruiquan wrote: > > I think only the originating node should do the rerouting with > RSVP-TE .At > > the same time, all the nodes will converge their IGP routing data > base. > > > > Rick > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org ] > On Behalf > > Of David Charlap > > Sent: Thursday, September 29, 2005 2:37 AM > > To: IETF MPLS List; IETF CCAMP List > > Subject: Graceful restart - inter-protocol dependencies > > > > Is there any point to implementing RSVP-TE's graceful restart > without also > > implementing graceful restart for routing protocols? > > > > On the one hand, RSVP doesn't require routing to recover > LSPs. It knows the > > next-hop interface, because of the preserved data-plane connection. > > Whatever other information it may need, the switch can either > preserve > > this information or recover it from a neighbor using the > RecoveryPath object > > (draft-ietf-ccamp-rsvo-restart-ext-03). > > > > On the other hand, nodes more than one hop upstream of the > failure will > > detect the loss of routing-connectivity to the failed node if IGP > graceful > > restart is not also implemented. They may reroute the LSP away > from the > > failed node, or tear it down altogether, even though the data > plane is still > > active and RSVP graceful restart is recovering the control-plane > state. > > > > An originating node may consider the destination unreachable, as > a result of > > losing the routes even though the data-plane for the LSP is still > up (which > > can be confirmed via OAM.) > > > > A transit node, when processing an loose ERO-hop, may choose to > reroute or > > fail the LSP if its local topology information says that the > failed (and > > restarting) node is not available. It might even choose to do > this for an > > established LSP, as a result of Path refresh processing. > > > > My questions are: > > > > 1: Does this mean it's pointless to use RSVP graceful restart > without > > also using IGP graceful restart (for whatever IGP is active). > > > > 2: Is IGP graceful restart sufficient to prevent this problem? For > > instance, OSPF's restart procedure requires all preserved > state to > > be thrown away if a topology change is detected. > > > > 3: An originating node can use OAM to validate the data plane of an > > LSP, and choose to ignore what routing tells it about the > > destination's reachability. But what about transit > nodes? As far > > as I know, MPLS doesn't support segment-OAM, and it would be > > prohibitive for every transit node to run its own OAM streams > > to detect self-to-end connectivity. > > > > 4: Are there other solutions to this problem? > > > > One possible solution might be route-pinning, but RSVP doesn't have a > > built-in mechanism for this. The usual workaround (signal the LSP, > > requesting route-recording, then turn the RRO into an ERO for > subsequent > > refreshes) can work, but are there situations where even this > would be > > insufficient to prevent a transit node from rerouting/tearing the > connection > > in this particular situation (where RSVP is doing a graceful > restart but the > > IGP is not)? > > > > -- David > > > From owner-ccamp@ops.ietf.org Thu Sep 29 16:34:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL579-0005jV-QY for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 16:34:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12373 for ; Thu, 29 Sep 2005 16:34:45 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL5Em-0007WR-8I for ccamp-archive@ietf.org; Thu, 29 Sep 2005 16:42:47 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EL4xA-000F6V-Di for ccamp-data@psg.com; Thu, 29 Sep 2005 20:24:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EL4x9-000F6A-O9 for ccamp@ops.ietf.org; Thu, 29 Sep 2005 20:24:27 +0000 Received: from [192.168.0.100] (c-67-170-201-38.hsd1.ca.comcast.net [67.170.201.38]) (authenticated bits=0) by pro.abac.com (8.13.4/8.13.4) with ESMTP id j8TKMpbG000763; Thu, 29 Sep 2005 13:22:54 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <433C4D1A.8090008@grotto-networking.com> Date: Thu, 29 Sep 2005 13:22:50 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alok CC: ccamp@ops.ietf.org Subject: Re: questions References: <00d101c5c50f$23320870$300218ac@rs.riverstonenet.com> In-Reply-To: <00d101c5c50f$23320870$300218ac@rs.riverstonenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi Alok, by "Muxing" below I'm assuming that you're refering to TDM (circuit) multiplexing rather that packet multiplexing or wavelength division multiplexing (WDM)? If so check out the SONET/SDH overview in http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-05.txt Greg B. Alok wrote: >I may speak on behalf of a lot of friends/youngsters who do have questions >related to the bases of how Muxing works.. >and trying to understand the various VCs and containers and the reason they >exist. > >Is it ok for new comers, who really dont understand transmissions and all >those VT pointers to ask questions on the list.... > > > >-thanks >Alok > > > > > > > From owner-ccamp@ops.ietf.org Thu Sep 29 21:17:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL9WW-00037I-Ov for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 21:17:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27410 for ; Thu, 29 Sep 2005 21:17:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL9eD-00063D-C8 for ccamp-archive@ietf.org; Thu, 29 Sep 2005 21:25:18 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1EL9Lt-000H1s-QH for ccamp-data@psg.com; Fri, 30 Sep 2005 01:06:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.69] (helo=smtpauth09.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1EL9Ls-000H0T-Au for ccamp@ops.ietf.org; Fri, 30 Sep 2005 01:06:16 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JU447C/I0OPG7Bof+5VVi3u1vNObfUthlxGvpuT51k9t90/BrXOrqoRfgQCunvLt; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.249.107] (helo=jlucianilaptop) by smtpauth09.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1EL9Lk-0005fo-L0; Thu, 29 Sep 2005 21:06:10 -0400 Message-ID: <025b01c5c55b$64b05260$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , "Thomas D. Nadeau" , Cc: "Wijnen, Bert (Bert)" , References: <3.0.1.32.20050908114852.0147664c@pop.mindspring.com> <119b01c5bf74$daed3f20$28849ed9@Puppy> <012601c5c3da$b3441ec0$0500a8c0@jlucianilaptop> <020901c5c433$35234fd0$be849ed9@Puppy> Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Thu, 29 Sep 2005 21:07:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265475dd2ea0720ae12466d16d05a2ac3c5208a8bb3e8e732a70350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.249.107 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 819069d28e3cfe534e22b502261ce83f Content-Transfer-Encoding: 7bit Hi Adrian, Thank you for your quick response. Few comments inline. thanks, Joan ----- Original Message ----- From: Adrian Farrel To: ; Thomas D. Nadeau ; Cc: Wijnen, Bert (Bert) ; Sent: Wednesday, September 28, 2005 9:16 AM Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt > Again, thanks Joan. I think we are converging quickly. > > A few responses in the snipped email below. > > Cheers, > Adrian > > > > > >17) object: gmplsInterfaceSignalingCaps OBJECT-TYPE > > > > > > > > SYNTAX BITS { > > > > unknown (0), > > > > rsvpGmpls (1), > > > > crldpGmpls (2), -- note the use of CR-LDP is deprecated > > > > otherGmpls (3) > > > > } > > > > > > > > > > > >What is otherGmpls(3)?? > > > > > > Nack > > > > > > I'm embarrassed to say that there are other "GMPLS" signaling protocol > > > variants that have been developed outside the IETF. This was added in > > > response to a WG request. > > > > > > >Also, this description is confusing. How can unknown(0) and > > > >rsvpGmpls(1) be set simultaneously? > > > > > > Ack > > > Will add: > > > > > > ...but if unknown(0) is set, no other bit may be set. > > > > > > >Additionally, how can no bits be set? If this is a GMPLS interface, > > > >then doesn't one of these bits HAVE to be set? > > > > > > Ack > > > > > > As it says... > > > > > > Setting no bits implies > > > that GMPLS signaling cannot be performed on this interface and > > > all LSPs must be manually provisioned or that this table entry > > > is only present to supplement an entry in the > > > mplsInterfaceTable > > > by providing the information carried in other objects in this > > > row. > > > > > > This means that we should change gmplsInterfaceEntry to read: > > > > > > "A conceptual row in this table is created automatically by an > > > LSR for each interface that is both capable of supporting > > > GMPLS and that is configured to support GMPLS. Note that > > > support of GMPLS is not limited to control plane signaling, > > > but may include data-plane only function configured through > > > SNMP SET commands performed on this MIB module. > > > > > > A conceptual row in this table may also be created via SNMP > > > SET commands or automatically by the LSR to supplement a > > > conceptual row in the mplsInterfaceTable where the interface > > > is not capable of GMPLS but where the other objects carried > > > in this row provide useful additional information for an > > > MPLS interface." > > > > If I could ask you to put your chair hat on for a minute, what are the > > co-authors doing to get feedback from the MPLS working group on > > objects which may apply to MPLS? > > > > Additionally, is this draft going to have a last call in the MPLS > > working group? (maybe this is a question for the ADs). > > We can certainly poll the MPLS WG to see: > a. if there are other attributes that need to be controlled and could be > added to these modules > b. if there are any further review comments > > Since the work form MPLS-TE is split between the MPLS and CCAMP working > groups, it is usually assumed that anyone with an interest in MPLS-TE is > following both working groups. Further, since GMPLS is a superset of > MPLS-TE we can assume that anything that is needed for MPLS-TE is needed > for GMPLS. > > But I will send mail, not as a formal last call, but to see if we can > catch any more isues at this time. Thank you. I meant to suggest also sending email to the MPLS working group when these set of documents go to last call in the CCAMP working group. Sorry if that was not clear. > > > Also, it seems this object would be more appropriate in the > > GMPLS-TE-STD-MIB. Is there a reason for choosing the > > GMPLS-LSR-STD-MIB for this object? > > The main reason is that this object desribes the capabilities of an LSR's > interface. Included in this is the possilibity that the LSR does not > support any signaling protocols on the interface but still supports LSPs > (a la PVC). This makes this an LSR-related thing. Lastly, this object is > part of the gmplsInterfaceTable which is an extension of the > mplsInterfaceTable that appears in RFC3813, the MPLS-LSR-STD-MIB. > okay. > > > >18) gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE > > > > "Period, in milliseconds, between sending RSVP Hello messages > > > > on > > > > this interface. A value of 0 indicates that no Hello messages > > > > should be sent on this interface." > > > > > > > >This object is only valid if the gmplsInterfaceSignalingCaps > > > >object is set to rsvpGmpls. Please update the description > > > >to reflect that. > > > > > > Nack > > > It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB). > > > > Why is this object in this MIB as opposed to the GMPLS-TE-STD-MIB? > > > > I thought that GMPLS-TE-STD-MIB augmented the MPLS-TE-STD-MIB, > > is that not the case? > > Exactly the point. > RFC3812 does not contain per-interface objects. These are in RFC3813 in > the MPLS-LSR-STD-MIB. > > You are correct that this object is protocol dependent and would not be > used unless a TE protocol was in use (specifically RSVP-TE) unlike the > previous object. Thus, we could introduce a per-interface table within the > GMPLS-TE-STD-MIB to contain only this object, or we could leave it where > it is with all of the other per-interface objects. Had there been more > similar objects, I think we might have opted for this approach, but for > one object it did not seem worth it. > > Do you feel strongly? > Okay to leave where it is. Regarding MPLS objects in this and the GMPLS-TE-STD-MIB, I have consulted other MIB Doctors and one suggestion was made which I would like to relay, that is: to create a separate object group for these MPLS or MPLS TE objects in the Conformance Statements. An object group for the above object would contain only the one object, and the description would specify that this object applies to using MPLS with RSVP-TE. The benefits of doing this would be that someone reading the MIB module would quickly be able to isolate MPLS objects. As you pointed out, implementations will probably migrate certain groups (objects) before other groups, so this would probably help in making the decision of what object groups to implement first, second, etc. > > > >23) gmplsOutSegmentEntry OBJECT-TYPE > > > >Same comments as with gmplsInSegmentEntry > > > > > > Nack > > > Same answer > > > > Think you mean ack here? > > Oops, yes. > > > > >Section 8. GMPLS-LABEL-STD-MIB > > > >=================================== > > > > > >31) gmplsLabelTable OBJECT-TYPE > > > > > > > >The last part of the last paragraph is awkward: > > > > > > > > "... Labels in the tables in other MIBs are referred to using > > > > row pointer into this table. The indexing of this table > > > > provides > > > > for arbitrary indexing and also for concatenation of labels." > > > > > > > >Are you saying that other MIBs can use a row pointer to point to > > > >this table? Why would they do that if they could just use the > > > >indices directly? Also, I don't follow the comment about > > > >concatenation of labels. Could you explain this? > > > > > > Nack > > > Yes we are saying that other MIB modules can use a row pointer to > > > point to this table. > > > Yes they could use indices. This was the subject of a very lengthy > > > discussion between the co-authors, etc., but in the end we > > > observed that mplsInSegmentLabelPtr and mplsOutSegmentLabelPtr > > > (RFC3813) are rowPointers so we had better support being pointed to. > > > > > > We could soften the language here by replacing "are" with "may". > > > > Yes, please. > > > > > Note, we should change this to say "MIB modules" > > > > > > > good. > > > > > For an example of label concatenation see RFC3945 section 7.1. In > > > essence, a GMPLS label may be composite in order to identify a set > > > of resources in the data plane. Practial examples are timeslots > > > and wavelength sets (which are not contiguous like wavebands). > > > > > > The indexing mechanism allows multiple entries in this table to be > > > seen as a sequence of labels that should be concatenated. Ordering > > > is potentially very sensitive for concatenation. > > > > > > > It would be nice if you could add the above 2 paragraphs to the > > DESCRIPTION. > > OK, will do. Thank you. > > > > >32) gmplsLabelEntry OBJECT-TYPE > > > > > > > >The last sentence of the DESCRIPTION, please remove > > > >the word "more" from the phrase "is more persistent." > > > > > > >I still don't understand how the subindex provides a way > > > >to concatenate the labels. Could you give an example? > > > > > > Nack > > > If you are asking for an example in the I-D, I don't think it is > > > necessary. > > > > > > For your information, the composite label {{A}, {B}, {C}} might be > > > constructed as... > > > > > > gmplsLabelInterface = 1 > > > gmplsLabelIndex = 1 > > > gmplsLabelSubindex = 1 > > > gmplsLabelFreeform = A > > > > > > gmplsLabelInterface = 1 > > > gmplsLabelIndex = 1 > > > gmplsLabelSubindex = 2 > > > gmplsLabelFreeform = B > > > > > > gmplsLabelInterface = 1 > > > gmplsLabelIndex = 1 > > > gmplsLabelSubindex = 3 > > > gmplsLabelFreeform = C > > > > This is a good example and would, I think, be helpful someplace in the > > document. This is only a suggestion however, and not a blocking issue. > > OK. We'll look at how to include an example in the pre-amble text (not the > Description clasue). > Thank you. > > > >34) gmplsLabelInterface OBJECT-TYPE > > > > > > > >DESCRIPTION also needs to specify that zero may be > > > >used to indicate that the InterfaceIndex is not known > > > >or that an InterfaceIndex exists but it is not important > > > >wrt this implementation so zero is used. > > > > > > Nack > > > The use of zero is very precisely specified at the moment. > > > The reasons for setting zero that you cite are: > > > - the InterfaceIndex is not known > > > You cannot have a per-interface label space without knowing the > > > interface to which it applies. > > > - InterfaceIndex exists but it is not important wrt this > > > implementation > > > That is exactly the case of the global label space, and is already > > > stated. > > > > I think you need to list all the reasons under which zero could be a > > valid value for this index. You have listed more above which are not > > specified in the description. > > Erm, but of the two reasons given above I have refuted one, and the other > is specified in the descritpion. Opps, sorry. I misread your response. I'm fine with the original description. > I can't think of a meaningful way to change the existing text. > DESCRIPTION > "The interface on which this label is used. If the label has or > could have applicability across the whole system, this object > SHOULD be set to zero." > Perhaps we can re-order the words... > DESCRIPTION > "The interface on which this label is used. If this object is set > to zero, the label has or could have applicability across the > whole system and is not limited to a single interface." > > Does that help? > > > > > 35) gmplsLabelIndex OBJECT-TYPE > > > > SYNTAX Unsigned32 (0..4294967295) > > > > > >36b)Please change the "may" to "should" in this statement: > > > > A management application may read the gmplsLabelIndexNext > > > > object to find a suitable value for this object." > > > > > > Nack > > > Why "should" it do this? This is a convenience offered to it. It may > > > use any mechanism it chooses including the one suggested in the > > > quoted paragraph above. > > > > Without getting into a debate about tables and indexing, the > > should is extremely appropriate. Think of the case where you have a > > large number of rows in this table, do you expect a user to try a > > bunch of numbers to create a row even if he/she has access to a CLI, > > it will certainly be annoying to have to page through this table > > and get to an available number. > > > > If a user consults the gmplsLabelIndexNext object then creating an > > entry should be easier than not getting the gmplsLabelIndexNext > > object. > > And if the implementation is using correlation of gmplsLabelIndex > with the actual label ("Note that implementations that are > representing 32 bit labels within this table MAY choose to align > this index with the value of the label, but should be aware of the > implications of sparsely populated tables.") then the use of > gmplsLabelIndexNext would be completely inapproproriate because the > correct value (dependent on the label actually assigned in hardware) > comes from a different source. > > The use of "should" would curtail (a.k.a. break :-) this function. Okay, I understand this now, you are suggesting 2 different ways to assign a value for this index. I would expect that an operator would use one or the other for the table (not both), right? If so please modify the DESCRIPTION clause to make that clear, i.e. "The following paragraphs describe 2 methods to assign a value to this index, only one of these methods should be used." Please also add what the value of zero could represent for each method of assigning indexes, i.e. if using the value of the label as an index, than the value of zero, represents .....,... If using the gmplsLabelIndexNext there should be no value of zero (correct?) because gmplsLabelIndexNext returns zero to indicate that the table cannot create a row at this time. The use of "may" is fine. > > > > >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > > > > > > > >Please change the name to: gmplsLabelModuleReadOnlyCompliance > > > >to be consistent with the other MPLS and GMPLS MIB modules. > > > > > > Nack > > > I thought we tried to keep names down to 32 characters. I recall this > > > conversation before. Not mandatory, but desirable. > > > > > > A choice between two desires? > > > > > > > Please refer to Bert's comments on this. > > Agreed. > > > > >41) The ReadOnly compliance for gmplsLabelRowStatus > > > >does NOT have a MIN-ACCESS of read-only. Is this > > > >intentional? > > > > > > ??? > > > Not sure about this. > > > I thought the present of a WRITE-SYNTAX made some difference. > > > > Please refer to Bert's comments on this. > > Tom says he understands this, and will fix it. > > > > From owner-ccamp@ops.ietf.org Thu Sep 29 22:18:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELATS-0003iq-8o for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 22:18:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29458 for ; Thu, 29 Sep 2005 22:18:07 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELAb9-0007As-P3 for ccamp-archive@ietf.org; Thu, 29 Sep 2005 22:26:12 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELANX-000MiU-9c for ccamp-data@psg.com; Fri, 30 Sep 2005 02:12:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [209.86.89.69] (helo=smtpauth09.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ELANS-000Mhr-3H for ccamp@ops.ietf.org; Fri, 30 Sep 2005 02:12:00 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=akGa6jq7x3a4BeYbt80YoEldkYcquns5+LGYn+WeBoV/YizhIvAYw50/UPj6vIax; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.167.249.107] (helo=jlucianilaptop) by smtpauth09.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1ELANI-00008q-V9; Thu, 29 Sep 2005 22:11:50 -0400 Message-ID: <027b01c5c564$8fcff820$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , , Cc: , References: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> <11aa01c5bf75$b2750720$28849ed9@Puppy> Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Thu, 29 Sep 2005 22:13:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265475dd2ea0720ae124db315cf71ab535c2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.167.249.107 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6 Content-Transfer-Encoding: 7bit hi Adrian, Please see comments inline below, I have snipped parts where we are in agreement. thanks, joan ----- Original Message ----- From: Adrian Farrel To: ; ; Cc: ; Sent: Thursday, September 22, 2005 8:59 AM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > Hi Joan, > > Last but not least, the GMPLS TE MIB module. > > > Here are some comments on draft-ietf-ccamp-gmpls-te-mib-09.txt. > > All 3 docs show a good deal of work. > > Yes, but fortunatley most of the work appears to be editorial with only > very minor changes to the basis of the module. > > Please find acks and nacks in line below. > > We will also include the comments made by David and Tom Petch. > > Cheers, > Adrian > > > > Section 8. GMPLS Traffic Engineering MIB Module > > ----------------------------------------------- > > > > smicngPRO gives the following: > > > > W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should > have > > SIZE specified > > Ack > Understood this to be optional, but planning to add size as per David's > comments > > > W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is > > identical > > W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is > > identical > > W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is > > identical > > W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax > is > > identical > > W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", > syntax > > is identical > > Nack > Meaningless warning message. Cannot fix without explanation. The object is defined as: gmplsTunnelDirection OBJECT-TYPE SYNTAX INTEGER { forward (0), bidirectional (1) } MAX-ACCESS read-create STATUS current DESCRIPTION "Whether this tunnel carries forward data only (is unidirectional) or is bidirectional. Values of this object other than 'forward' are meaningful only if gmplsTunnelLSPEncoding is not set to 'tunnelLspNotGmpls'." DEFVAL { forward } ::= { gmplsTunnelEntry 8 } The following (part of the ReadOnly compliance statement) is causing the warning because the SYNTAX defined in the object and the SYNTAX below are the same. (Following the OBJECT are a few alternatives.) OBJECT gmplsTunnelDirection SYNTAX INTEGER { forward (0), bidirectional (1) } MIN-ACCESS read-only DESCRIPTION "Only forward (0) is required." If you do intend for the SYNTAX in both the OBJECT-TYPE and the OBJECT to be the same, then removing it from the OBJECT would get rid of the warning. This is not a blocking issue, but it is duplicate info that does not need to be duplicated. So here is what the OBJECT statement would like: OBJECT gmplsTunnelDirection MIN-ACCESS read-only DESCRIPTION "Only forward (0) is required." Another alternative would be to specify forward(0) only since this is what the DESCRIPTION is specifying, however, it is likely that you are probably allowing both, so I don't think this is what you intend, but this would also solve the compiler warning: OBJECT gmplsTunnelDirection SYNTAX INTEGER { forward (0), } MIN-ACCESS read-only DESCRIPTION "Only forward (0) is required." > > 5) gmplsTunnelTable > > > > DESCRIPTION > > > > "The row status of an entry in this table is controlled by > > mplsTunnelRowStatus in the corresponding entry in > > mplsTunnelTable. That is, it is not permitted to create a row in > > this table, nor to modify an existing row, when the > > corresponding mplsTunnelRowStatus has value active(1).... > > > > The sentence beginning with "That is," is awkward. Could you say > > something like: A row in this table is created when a row is created > > in the mplsTunnelTable. Entries in this table cannot be modified > > when the corresponding mplsTunnelRowStatus has a value of active(1). > > The exception.... > > > > Please also update this other places in this MIB (e.g > gmplsTunnelHopTable). > > Nack > "A row in this table is created when a row is created in the > mplsTunnelTable" is false. > Will attempt to reword to make this clearer. > > > 6) gmplsTunnelEntry > > DESCRIPTION: > > "... > > An entry can be created by a network administrator or by an SNMP > > agent as instructed by a signaling protocol." > > > > Please change the above to: > > > > "An entry can be created by a network administrator via SNMP SET > commands, or > > by the network management entity as instructed by a signaling > > protocol." > > Nack > "network management entity" implies a remote entity such as an NMS. Yes, I should have said, "network management entity (e.g., snmp agent). > Will change to: > > "An entry can be created by a network administrator via SNMP SET > commands, or in response to signaling protocol events." > good. > > 7) gmplsTunnelUnnumIf > > > > What IF-MIB object are referring to in the DESCRIPTION? > > Could you state which object in the description? > > Ack > An entry in ifTable. > Could you specify the ifType(s)? > > 8) gmplsTunnelAttributes > > Could you specify what happens when the bit is set (i.e. 1) > > vs. 0? > > Ack > Don't want to restate the protocol I-D, so this text will simply > replace "This flag indicates that" with "This flag is set to indicate > that" > > > 9) gmplsTunnelLSPEncoding > > > > The DESCRIPTION states: > > ...A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling > is > > not in use. Some objects in this MIB module may be of use for > > MPLS signaling extensions that do not use GMPLS signaling. By > > setting this object to 'tunnelLspNotGmpls', an application may > > indicate that only those objects meaningful in MPLS should be > > examined.... > > > > I believe that such objects should be put in to an MPLS MIB module > > and not included in this GMPLS MIB module. This is also true with > > the gmplsTunnelErrorTable. > > Nack > We strongly disagree with any implication that MPLS and GMPLS should be > separated in this way. GMPLS protocol extensions are likely to be > moved into MPLS implementations piecemeal and there is no clear > separation that you imply. The G in GMPLS stands for "generalized". > > Can you please indicate whether this is a sticking point for you. > As was suggested in an email on draft-ietf-ccamp-gmpls-lsr-mib, could you put these objects in a separate object group? Also, please separate MPLS and MPLS-TE objects into separate object groups. > > > 12) gmplsTunnelUpNotRecip > > > > Need to use InetAddressType and InetAddress. IpAddress > > is not used in MIBs anymore. Please be sure to support > > both v4 and v6 IP address Types. If you can't support > > v6 for some reason, that should be stated clearly. > > Ack per exchange with David. > > > Please change the name of this object to: > > gmplsTunnelUpstreamRecipientForNotify > > Nack > We are trying to keep to the (mythical?) 32 character limit. > How about: > gmplsTunnelUpNotifyRecipient How about gmplsTunnelUpstreamNotifyRecipient As for the 32 char limit, we've already addressed that, so won't repeat that discussion. > > > 13) gmplsTunnelDownNotRecip > > Same comment as above wrt to IpAddress. > > Ack > > > Please change the name to gmplsTunnelDownstreamRecipientForNotify > > Nack as above > How about: > gmplsTunnelDownNotifyRecipient How about gmplsTunnelDownstreamNotifyRecipient >> > 18) gmplsTunnelHopExpLabel and gmplsTunnelHopExpLabelPtr > > > > Need to add the word "Forward" in here as in > > gmplsTunnelHopExpForwardLabel and gmplsTunnelHopExpForwardLabelPtr > > > > That way it will be consistent with the Reverse counterparts. > > Nack > Please see point 21 about name lengths. > We will insert "Fwd" > > > 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpReverseLabelPtr > > > > Please change Rvrs to Reverse. > > Nack > Please see point 21 about name lengths In other objects in this MIB module are named using the entire word Reverse ( e.g. GmplsTunnelReversePerfEntry ::= SEQUENCE { gmplsTunnelReversePerfPackets Counter32, gmplsTunnelReversePerfHCPackets Counter64, gmplsTunnelReversePerfErrors Counter32, gmplsTunnelReversePerfBytes Counter32, gmplsTunnelReversePerfHCBytes Counter64 }) So please either change these to all use Rvrs or instead of Rvrs use the entire word, Reverse. Similarly with the use of Fwd and Forward, if you decide to use Reverse, then please use the entire word, Forward. If you decide to use Rvrs, then please use Fwd. I prefer the words spelled out but just please be consistent. > > 21) gmplsTunnelARHopExpLable and gmplsTunnelARHopExpLabelPtr > > > > Need to add the word "Forward" in here as in > > gmplsTunnelARHopExpForwardLabel and gmplsTunnelARHopExpForwardLabelPtr > > Nack > Would excede 32 characters. > Will use "Fwd" See discussion above wrt Rvrs and Reverse. > > > 22) gmplsTunnelARHopExpRvrsLabel and gmplsTunnelARHopExpRvrsLabelPtr > > > > Please change Rvrs to Reverse > > Nack > See point 21 > > > 23) gmplsTunnelARHopProtection OBJECT-TYPE > > > > Please add what the BIT set (i.e. 1) vs. 0 means in the > > DESCRIPTION. > > Ack > Limited change as before. > > > 24) gmplsTunnelCHopLabelTable objects > > > > Similar comments regarding the objects in this table > > to those above with regard to naming > > conventions (Forward and Reverse) and DESCRIPTIONs. Will not repeat the > > details, please refer to above comments on the > > prior 2 tables. > > Nack > Same answers as before. > Will use "Fwd" > > > 25) gmplsTunnelReversePerfTable > > Please add to the DESCRIPTION how a user knows if > > this is a bidirectional tunnel (i.e. what object > > or objects in the gmplsTunnelTable need to have > > what values?). > > Ack > > > 26) gmplsTunnelReversePerfPackets > > > > Does this object represent the 32-bit > > value of the least significant part of the > > 64-bit value (which is contained in gmplsTunnelReversePerfHCPackets)? > > Ack > > > 27) gmplsTunnelReversePerfBytes > > > > Does this object represent the 32-bit > > value of the least significant part of the > > 64-bit value (which is contained in gmplsTunnelReversePerfHCBytes)? > > Ack > > > 28) gmplsTunnelErrorTable OBJECT-TYPE > > > > Since this table applies to MPLS, it should be > > put in a separate MIB module which is MPLS specific. The > > prefix of gmpls could be confusing. > > Nack > This is applicable across MPLS and GMPLS. > Error TLVs are not present in MPLS RSVP-TE at this time. They may be added > later. > Discussed previously about separate OBJECT groups. > > 31) Compliance > > > > Please move some of the following comment in the > > DESCRIPTION of gmplsTeModuleFullCompliance > > > > -- The mandatory group has to be implemented by all LSRs that > > -- originate, terminate or act as transit for TE-LSPs/tunnels. > > -- In addition, depending on the type of tunnels supported, other > > -- groups become mandatory as explained below. > > Ack > > > 32) gmplsTunnelUnnumIf does not appear in the ReadOnly compliance > > and it probably should. > > Ack > > > Section 11.2.1. IANA-GMPLS-MIB Definition > > ----------------------------------------- > > > 38) I believe that the TC > > > > IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION > > > > should be put in the GMPLS-TC-STD-MIB or should just > > remain in the GMPLS-TE-STD-MIB. The reason is that this > > is not an assigned numbers list maintained by IANA, so > > should not be in the IANA GMPLS MIB. If I am incorrect > > about this please let me know, but I didn't see an IANA > > maintained Administrative Status Information enum. > > Nack > There are no fewer than three requests in CCAMP I-Ds that have passed WG > last call > for this space to be managed by IANA. Is this going to be managed by IANA soon? (just curious) > > > Additionally, this should be renamed to > > GmplsAdminStatusInformation which more closely matches rfc3471. > > Ack > > > 39) Several comments on the SYNTAX clause: > > > > 40a) smicngPRO gives the error > > > > E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS > > must be in contiguous positions > > > > SYNTAX BITS { > > delInProgress (0), > > adminDown (1), > > testing (2), > > reflect (31) > > } > > > > > > RFC2578 specifies that BITS should be contiguous > > (although there are exceptions to this, but this > > object does not seem to be an exception). > > Nack > > To quote the DESCRIPTION... > The relationship between the assignment of > gmplsTunnelAdminStatusFlags values and of the bit flags > in the Admin Status object or TLV within the GMPLS > signaling protocols is solely the purview of IANA and is > subject to change without notice." > However, it seems to us that making the bits match the flags in the > Admin Status object is a Good Idea (TM). > Here is the TLV that the object represents: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved |T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reflect (R): 1 bit Reserved: 28 bits Testing (T): 1 bit Administratively down (A): 1 bit Deletion in progress (D): 1 bit The BITS as specified look backwards when viewing the TLV. Are the BITS correctly specified? I consulted with other MIB Doctors and the following was suggested: SYNTAX BITS { delInProgress (0), adminDown (1), testing (2), reserved3(3), -- 0 on send, ignored on receive reserved4(4), -- 0 on send, ignored on receive .. reserved30(30), -- 0 on send, ignored on receive reflect (31) } Would this be acceptable? > > Could delInProgress, be renamed to deleteInProgress ? > > Could adminDown be renamed to administrativelyDown? > > These names more closely match 3471. > > Ack > From owner-ccamp@ops.ietf.org Thu Sep 29 22:21:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELAWn-0004Sr-F1 for ccamp-archive@megatron.ietf.org; Thu, 29 Sep 2005 22:21:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29612 for ; Thu, 29 Sep 2005 22:21:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELAeR-0007GH-IK for ccamp-archive@ietf.org; Thu, 29 Sep 2005 22:29:40 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELASC-000N6g-IX for ccamp-data@psg.com; Fri, 30 Sep 2005 02:16:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [156.106.192.41] (helo=protext01.itu.ch) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ELASB-000N6Q-I0 for ccamp@ops.ietf.org; Fri, 30 Sep 2005 02:16:51 +0000 Received: from protext01.itu.ch ([156.106.192.41]) by protext01.itu.ch with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Sep 2005 04:16:51 +0200 Received: From mail4.itu.ch ([156.106.192.20]) by protext01.itu.ch (WebShield SMTP v4.5 MR1a); id 1128046611209; Fri, 30 Sep 2005 04:16:51 +0200 Received: from ties.itu.ch (ties.itu.ch [156.106.192.33]) by mail4.itu.ch (8.13.4/8.13.4) with ESMTP id j8U2GnBG461672 for ; Fri, 30 Sep 2005 04:16:50 +0200 (MEST) Received: from localhost (tokaj.itu.ch [156.106.192.34]) by ties.itu.ch (8.12.9/8.12.9) with ESMTP id j8U2GnwX006904 for ; Fri, 30 Sep 2005 04:16:49 +0200 (MET DST) Received: from 156.106.192.159 ( [156.106.192.159]) as user jingr@ties.itu.ch by gold.itu.ch with HTTP; Fri, 30 Sep 2005 04:16:49 +0200 Message-ID: <1128046609.433ca01162e4b@gold.itu.ch> Date: Fri, 30 Sep 2005 04:16:49 +0200 From: ruiquan.jing@ties.itu.ch To: ccamp@ops.ietf.org Subject: RE: Graceful restart - inter-protocol dependencies MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 156.106.192.159 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (mail4.itu.ch [156.106.192.20]); Fri, 30 Sep 2005 04:16:51 +0200 (MEST) X-OriginalArrivalTime: 30 Sep 2005 02:16:51.0866 (UTC) FILETIME=[0525CFA0:01C5C565] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 8bit Hi David, We should specify which version of RSVP we are talking. What I have said is about GMPLS RSVP-TE as used in ASON. When there is a failed link within the network, the ingress node will know the failure by transport plan OAM mechanism such as SDH path layer AIS, or by RSVP- TE Notify message. And usually these mechanisms are faster than routing protocol convergence speed. After the ingress node knows which link or route has failed, it will do the rerouting while excluding the failed link or route. Hope I say it clearly :-) Rick -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of David Charlap Sent: Thursday, September 29, 2005 10:35 PM To: 'IETF MPLS List'; 'IETF CCAMP List' Subject: Re: Graceful restart - inter-protocol dependencies But RSVP doesn't work this way. It is a soft-state protocol. If the route table changes such that the next-hop interface changes, RSVP is supposed to reroute the connection accordingly. This probably won't happen if the next-hop is a strict-hop in an ERO, but it can easily happen if the next-hop is loose or if the LSP is signaled without an ERO (meaning routing is consulted to determine the next-hop to the egress node.) If there is a paragraph in an RFC that says RSVP-TE should ignore all route- table changes once an LSP comes up, I missed it. -- David Jing Ruiquan wrote: > I think only the originating node should do the rerouting with > RSVP-TE .At the same time, all the nodes will converge their IGP > routing data base. > > Rick > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of David Charlap > Sent: Thursday, September 29, 2005 2:37 AM > To: IETF MPLS List; IETF CCAMP List > Subject: Graceful restart - inter-protocol dependencies > > Is there any point to implementing RSVP-TE's graceful restart without > also implementing graceful restart for routing protocols? > > On the one hand, RSVP doesn't require routing to recover LSPs. It > knows the next-hop interface, because of the preserved data-plane connection. > Whatever other information it may need, the switch can either > preserve this information or recover it from a neighbor using the > RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03). > > On the other hand, nodes more than one hop upstream of the failure > will detect the loss of routing-connectivity to the failed node if IGP > graceful restart is not also implemented. They may reroute the LSP > away from the failed node, or tear it down altogether, even though the > data plane is still active and RSVP graceful restart is recovering the control-plane state. > > An originating node may consider the destination unreachable, as a > result of losing the routes even though the data-plane for the LSP is > still up (which can be confirmed via OAM.) > > A transit node, when processing an loose ERO-hop, may choose to > reroute or fail the LSP if its local topology information says that > the failed (and > restarting) node is not available. It might even choose to do this > for an established LSP, as a result of Path refresh processing. > > My questions are: > > 1: Does this mean it's pointless to use RSVP graceful restart without > also using IGP graceful restart (for whatever IGP is active). > > 2: Is IGP graceful restart sufficient to prevent this problem? For > instance, OSPF's restart procedure requires all preserved state to > be thrown away if a topology change is detected. > > 3: An originating node can use OAM to validate the data plane of an > LSP, and choose to ignore what routing tells it about the > destination's reachability. But what about transit nodes? As far > as I know, MPLS doesn't support segment-OAM, and it would be > prohibitive for every transit node to run its own OAM streams > to detect self-to-end connectivity. > > 4: Are there other solutions to this problem? > > One possible solution might be route-pinning, but RSVP doesn't have a > built-in mechanism for this. The usual workaround (signal the LSP, > requesting route-recording, then turn the RRO into an ERO for > subsequent > refreshes) can work, but are there situations where even this would be > insufficient to prevent a transit node from rerouting/tearing the > connection in this particular situation (where RSVP is doing a > graceful restart but the IGP is not)? > > -- David From owner-ccamp@ops.ietf.org Fri Sep 30 02:22:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELEHs-0004An-Vy for ccamp-archive@megatron.ietf.org; Fri, 30 Sep 2005 02:22:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22853 for ; Fri, 30 Sep 2005 02:22:27 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELEPc-0004KO-Dd for ccamp-archive@ietf.org; Fri, 30 Sep 2005 02:30:33 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELE8O-000ISP-Es for ccamp-data@psg.com; Fri, 30 Sep 2005 06:12:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [217.32.164.137] (helo=smtp1.smtp.bt.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ELE8L-000IS0-NU for ccamp@ops.ietf.org; Fri, 30 Sep 2005 06:12:37 +0000 Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 30 Sep 2005 07:12:35 +0100 Received: from i2km07-ukbr.domain1.systemhost.net ([193.113.197.26]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Sep 2005 07:12:35 +0100 x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Graceful restart - inter-protocol dependencies Date: Fri, 30 Sep 2005 07:12:35 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A3538911800733@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Graceful restart - inter-protocol dependencies Thread-Index: AcXFZY4WAglBl5cGQ7e3Aa1Qqa/MOQAF+Sjw From: To: , X-OriginalArrivalTime: 30 Sep 2005 06:12:35.0905 (UTC) FILETIME=[F3A6E310:01C5C585] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: quoted-printable Rick....you must differentiate the co-cs mode case from the co-ps case. They both belong to the co mode BUT there are very significant differences....indeed, the 3 network modes arise by the way constraints are applied to a unified networking model (and if you are active in ITU then check out what is happening in SG15 on this topic). In the co-cs mode case the constraints mean the following behaviours are FORCED: - control/management OOB.....this means that in a co-cs network system there is more than 1 data-plane network. This has major implications on the design of these networks (wrt addressing, security, resilience, stability, etc); - the only traffic carrying trail constructs allowed are p2p and p2mp, ie no merging is possible......and these are the ONLY trail constructs that allow deterministic traffic/fault/performance management anyway; - a trail MUST complete between trail source and sink points as this is where the characteristic information is processed that looks after the integrity of the trail (eg OAM stuff); - there are no QoS/traffic classes.....this looks like a throwaway remark but it's extremely important.....especially when considering network builder services, ie when building a client layer topology this defines performance inheritance behaviour; - true client/server relationships can exist, ie complete functional decoupling of client and server layer networks....again absolutely critical for a whole raft of factors (security, scalability,...) when considering network builder services. Now add these observation to my previous ones (eg the importance of the trail object (which I think many folks still don't really get), and how once created it gets decoupled from the routing process) and you start to get the picture of the required behaviour of a co mode technology. Its jolly hard to get things wrong with the co-cs mode but this is not true for the co-ps mode. However, there is no reason why the co-ps mode should not reproduce the important behaviours, and in doing so re-use the components (eg similar OOB design, signalling), that apply to co-cs mode technologies.....indeed when we kicked off the ASON work this was precisely what was in our minds. And as a more general observation here: When folks talk about convergence there is a lot of confusion as to what this really means....it for sure does NOT mean that (i) 1 network mode/technology can do it all, nor does it mean (ii) one can somehow 'functionally crunch' all 3 networking modes and treat them alike. What is does mean however is that we don't need lots of different technologies belonging to the SAME mode (as this creates duplication/waste and leads to stovepipe services and downstream migration/interworking problems), but we do need all 3 modes working in concert....and wrt to this latter observation we can apply sensible component re-use, ergo the comment above wrt ASON. And the 'service' reason this is required is because (as we sunset PDH, lower rate SDH VC12, FR and ATM layer networks) we need a network builder service capability at bit rates smaller than SDH VC4. It's taking a lot longer then we expected for the above to be better understood but I can see strong signs now emerging that we are starting to get there. =20 regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > ruiquan.jing@ties.itu.int > Sent: 30 September 2005 03:17 > To: ccamp@ops.ietf.org > Subject: RE: Graceful restart - inter-protocol dependencies >=20 >=20 >=20 >=20 > Hi David, >=20 > We should specify which version of RSVP we are talking. What > I have said is=20 > about GMPLS RSVP-TE as used in ASON.=20 >=20 > When there is a failed link within the network, the ingress > node will know the=20 > failure by transport plan OAM mechanism such as SDH path=20 > layer AIS, or by RSVP- TE Notify message. And usually these=20 > mechanisms are faster than routing=20 > protocol convergence speed. After the ingress node knows=20 > which link or route=20 > has failed, it will do the rerouting while excluding the=20 > failed link or route.=20 >=20 > Hope I say it clearly :-) >=20 > Rick >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > David Charlap > Sent: Thursday, September 29, 2005 10:35 PM > To: 'IETF MPLS List'; 'IETF CCAMP List' > Subject: Re: Graceful restart - inter-protocol dependencies >=20 > But RSVP doesn't work this way. It is a soft-state protocol. >=20 > If the route table changes such that the next-hop interface > changes, RSVP is=20 > supposed to reroute the connection accordingly. >=20 > This probably won't happen if the next-hop is a strict-hop in > an ERO, but it=20 > can easily happen if the next-hop is loose or if the LSP is=20 > signaled without=20 > an ERO (meaning routing is consulted to determine the=20 > next-hop to the egress > node.) >=20 > If there is a paragraph in an RFC that says RSVP-TE should > ignore all route- table changes once an LSP comes up, I missed it. >=20 > -- David >=20 > Jing Ruiquan wrote: > > I think only the originating node should do the rerouting with=20 > > RSVP-TE .At the same time, all the nodes will converge their IGP=20 > > routing > data base. > >=20 > > Rick > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of David Charlap > > Sent: Thursday, September 29, 2005 2:37 AM > > To: IETF MPLS List; IETF CCAMP List > > Subject: Graceful restart - inter-protocol dependencies > >=20 > > Is there any point to implementing RSVP-TE's graceful > restart without > > also implementing graceful restart for routing protocols? > >=20 > > On the one hand, RSVP doesn't require routing to recover LSPs. It=20 > > knows the next-hop interface, because of the preserved data-plane > connection. > > Whatever other information it may need, the switch can either=20 > > preserve this information or recover it from a neighbor using the=20 > > RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03). > >=20 > > On the other hand, nodes more than one hop upstream of the failure=20 > > will detect the loss of routing-connectivity to the failed > node if IGP > > graceful restart is not also implemented. They may reroute the LSP > > away from the failed node, or tear it down altogether, even=20 > though the > > data plane is still active and RSVP graceful restart is > recovering the > control-plane state. > >=20 > > An originating node may consider the destination unreachable, as a=20 > > result of losing the routes even though the data-plane for > the LSP is > > still up (which can be confirmed via OAM.) > >=20 > > A transit node, when processing an loose ERO-hop, may choose to=20 > > reroute or fail the LSP if its local topology information says that=20 > > the failed (and > > restarting) node is not available. It might even choose to do this > > for an established LSP, as a result of Path refresh processing. > >=20 > > My questions are: > >=20 > > 1: Does this mean it's pointless to use RSVP graceful > restart without > > also using IGP graceful restart (for whatever IGP is active). > >=20 > > 2: Is IGP graceful restart sufficient to prevent this problem? For > > instance, OSPF's restart procedure requires all > preserved state to > > be thrown away if a topology change is detected. > >=20 > > 3: An originating node can use OAM to validate the data plane of an > > LSP, and choose to ignore what routing tells it about the > > destination's reachability. But what about transit > nodes? As far > > as I know, MPLS doesn't support segment-OAM, and it would be > > prohibitive for every transit node to run its own OAM streams > > to detect self-to-end connectivity. > >=20 > > 4: Are there other solutions to this problem? > >=20 > > One possible solution might be route-pinning, but RSVP > doesn't have a > > built-in mechanism for this. The usual workaround (signal the LSP, > > requesting route-recording, then turn the RRO into an ERO for=20 > > subsequent > > refreshes) can work, but are there situations where even=20 > this would be > > insufficient to prevent a transit node from rerouting/tearing the > > connection in this particular situation (where RSVP is doing a=20 > > graceful restart but the IGP is not)? > >=20 > > -- David >=20 >=20 >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Fri Sep 30 06:51:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELIUf-0004mB-Pk for ccamp-archive@megatron.ietf.org; Fri, 30 Sep 2005 06:51:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04469 for ; Fri, 30 Sep 2005 06:51:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELIcW-0002AA-Ee for ccamp-archive@ietf.org; Fri, 30 Sep 2005 07:00:04 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELIMR-000Lw5-Ts for ccamp-data@psg.com; Fri, 30 Sep 2005 10:43:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ELIMR-000Lvs-0o for ccamp@ops.ietf.org; Fri, 30 Sep 2005 10:43:27 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8UAhLNd004355; Fri, 30 Sep 2005 05:43:22 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Sep 2005 12:43:20 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155082FB10E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, Adrian Farrel , tnadeau@cisco.com, ccamp@ops.ietf.org Cc: bwijnen@lucent.com Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Fri, 30 Sep 2005 12:43:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 W.r.t. > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Friday, September 30, 2005 04:14 > To: Adrian Farrel; tnadeau@cisco.com; ccamp@ops.ietf.org > Cc: bwijnen@lucent.com; jcucchiara@mindspring.com > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > .. snip .. > > > > > Section 8. GMPLS Traffic Engineering MIB Module > > > ----------------------------------------------- > > > > > > smicngPRO gives the following: > > > > > > W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should > > > have SIZE specified > > > > Ack > > Understood this to be optional, but planning to add size as > > per David's comments > > > > > W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax > > > is identical > > > W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", syntax > > > is identical > > > > Nack > > Meaningless warning message. Cannot fix without explanation. > > > The object is defined as: > > > gmplsTunnelDirection OBJECT-TYPE > SYNTAX INTEGER { > forward (0), > bidirectional (1) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Whether this tunnel carries forward data only (is > unidirectional) or is bidirectional. > > Values of this object other than 'forward' are meaningful > only if gmplsTunnelLSPEncoding is not set to > 'tunnelLspNotGmpls'." > DEFVAL { forward } > ::= { gmplsTunnelEntry 8 } > > > The following (part of the ReadOnly compliance statement) is causing > the warning because the SYNTAX defined in the object and the > SYNTAX below are the same. (Following the OBJECT are a > few alternatives.) > > OBJECT gmplsTunnelDirection > SYNTAX INTEGER { > forward (0), > bidirectional (1) > } > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > > If you do intend for the SYNTAX in both the OBJECT-TYPE and > the OBJECT to be the same, then removing it from the OBJECT > would get rid of the warning. This is not a blocking issue, but > it is duplicate info that does not need to be duplicated. > So here is what the OBJECT statement would like: > > OBJECT gmplsTunnelDirection > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > Another alternative would be to specify forward(0) only since > this is what the DESCRIPTION is specifying, however, it is > likely that you are probably allowing both, so I don't think this > is what you intend, but this would also solve the compiler warning: > > OBJECT gmplsTunnelDirection > SYNTAX INTEGER { > forward (0), > } > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > This last one is (in my view) the only correct one. The SYNTAX in fact is inline with what is in the DESCRIPTION clause. And that is in my view IMPORTANT. Bert From owner-ccamp@ops.ietf.org Fri Sep 30 06:52:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELIUo-0004tA-73 for ccamp-archive@megatron.ietf.org; Fri, 30 Sep 2005 06:52:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04475 for ; Fri, 30 Sep 2005 06:52:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELIce-0002Ae-VN for ccamp-archive@ietf.org; Fri, 30 Sep 2005 07:00:13 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELINF-000Lzo-C8 for ccamp-data@psg.com; Fri, 30 Sep 2005 10:44:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.11.222.163] (helo=ihemail2.lucent.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ELINE-000Lzb-QN for ccamp@ops.ietf.org; Fri, 30 Sep 2005 10:44:16 +0000 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8UAhLSw004353; Fri, 30 Sep 2005 05:43:22 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 30 Sep 2005 12:43:20 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155082FB10F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, Adrian Farrel , tnadeau@cisco.com, ccamp@ops.ietf.org Cc: bwijnen@lucent.com Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Fri, 30 Sep 2005 12:43:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 W.r.t. > > > 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpReverseLabelPtr > > > > > > Please change Rvrs to Reverse. > > > > Nack > > Please see point 21 about name lengths > > In other objects in this MIB module are named using the entire > word Reverse ( e.g. > GmplsTunnelReversePerfEntry ::= SEQUENCE { > gmplsTunnelReversePerfPackets Counter32, > gmplsTunnelReversePerfHCPackets Counter64, > gmplsTunnelReversePerfErrors Counter32, > gmplsTunnelReversePerfBytes Counter32, > gmplsTunnelReversePerfHCBytes Counter64 > }) > > So please either change these to all use Rvrs or instead of Rvrs use > the entire word, Reverse. Similarly with the use of Fwd and Forward, > if you decide to use Reverse, then please use the entire word, Forward. > If you decide to use Rvrs, then please use Fwd. I prefer the words > spelled out but just please be consistent. > I have explained repeatedly (and it has been in the MIB review guidelines (now RFC4181) for a long time), the 32 char limit is relaxed. And in general, consistency is MUCH more important (I think) than limiting to 32 chars. Bert From owner-ccamp@ops.ietf.org Fri Sep 30 08:55:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELKPr-0003V1-Nh for ccamp-archive@megatron.ietf.org; Fri, 30 Sep 2005 08:55:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09288 for ; Fri, 30 Sep 2005 08:55:06 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELKXc-000500-4l for ccamp-archive@ietf.org; Fri, 30 Sep 2005 09:03:15 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELKHm-0006T6-Sj for ccamp-data@psg.com; Fri, 30 Sep 2005 12:46:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ELKHm-0006Sp-4O for ccamp@ops.ietf.org; Fri, 30 Sep 2005 12:46:46 +0000 Received: from du-069-0048.access.clara.net ([217.158.132.48] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1EL1EZ-000OEz-7X for ccamp@ops.ietf.org; Thu, 29 Sep 2005 17:26:12 +0100 Message-ID: <053d01c5c512$ea3740e0$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <00d101c5c50f$23320870$300218ac@rs.riverstonenet.com> Subject: Re: questions Date: Thu, 29 Sep 2005 17:29:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi Alok, CCAMP is not really the place for this, but you can go ahead and ask here. There are folks on this list that should be able to answer you or point you at their books. Cheers, Adrian ----- Original Message ----- From: "Alok" To: Sent: Thursday, September 29, 2005 5:02 PM Subject: questions > I may speak on behalf of a lot of friends/youngsters who do have questions > related to the bases of how Muxing works.. > and trying to understand the various VCs and containers and the reason they > exist. > > Is it ok for new comers, who really dont understand transmissions and all > those VT pointers to ask questions on the list.... > > > > -thanks > Alok > > > > > > From owner-ccamp@ops.ietf.org Fri Sep 30 10:11:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELLbu-0000zy-Pb for ccamp-archive@megatron.ietf.org; Fri, 30 Sep 2005 10:11:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13153 for ; Fri, 30 Sep 2005 10:11:37 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELLjl-0006qU-PT for ccamp-archive@ietf.org; Fri, 30 Sep 2005 10:19:47 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELLU4-000D8J-HX for ccamp-data@psg.com; Fri, 30 Sep 2005 14:03:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [169.144.68.6] (helo=mailgate.pit.comms.marconi.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ELLU3-000D7o-1d for ccamp@ops.ietf.org; Fri, 30 Sep 2005 14:03:31 +0000 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id j8UE2wUk017045; Fri, 30 Sep 2005 10:02:58 -0400 (EDT) Received: from [169.144.136.107] (usvisdad104641.dc.fore.com [169.144.136.107]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12647; Fri, 30 Sep 2005 10:02:58 -0400 (EDT) Message-ID: <433D4591.4080308@marconi.com> Date: Fri, 30 Sep 2005 10:02:57 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'IETF MPLS List'" , "'IETF CCAMP List'" Subject: Re: Graceful restart - inter-protocol dependencies References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit Then we are talking about different protocols. I'm specifically referring to RSVP-TE, as defined by RFC 3209. I am aware that RSVP-TE's signaling mechanism (even just a PathErr message) will probably reach the ingress node long before routing can reconverge. But that's not the question. The question is, if the node failure is due to a restart, and it has implemented RSVP-TE restart (yes, I'm aware that this is a GMPLS extnsion), but has not implemented graceful restart for any routing protocols, then the originating node won't receive any RSVP-level information about the restarting node. But the IGP will. We want to prevent the reroute that would normally happen as a result of the route change. Originating nodes can test the LSP using OAM, if there is no other choice, but transit nodes don't have that option. Ultimately, this comes down to my original questions: Does it make any sense to use RSVP graceful restart in a network where graceful restart is not being used for any routing protocols? If the answer to the previous question is yes, what can be done (if anything) to prevent originating and transit nodes from rerouting LSPs as a result of the route-table change? -- David Jing Ruiquan wrote: > Hi David, > > We should specify which version of RSVP we are talking. What I have said is > about GMPLS RSVP-TE as used in ASON. > > When there is a failed link within the network, the ingress node will know > the failure by transport plan OAM mechanism such as SDH path layer AIS, or > by RSVP-TE Notify message. And usually these mechanisms are faster than > routing protocol convergence speed. After the ingress node knows which link > or route has failed, it will do the rerouting while excluding the failed > link or route. > > Hope I say it clearly :-) > > Rick > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of David Charlap > Sent: Thursday, September 29, 2005 10:35 PM > To: 'IETF MPLS List'; 'IETF CCAMP List' > Subject: Re: Graceful restart - inter-protocol dependencies > > But RSVP doesn't work this way. It is a soft-state protocol. > > If the route table changes such that the next-hop interface changes, RSVP is > supposed to reroute the connection accordingly. > > This probably won't happen if the next-hop is a strict-hop in an ERO, but it > can easily happen if the next-hop is loose or if the LSP is signaled without > an ERO (meaning routing is consulted to determine the next-hop to the egress > node.) > > If there is a paragraph in an RFC that says RSVP-TE should ignore all > route-table changes once an LSP comes up, I missed it. > > -- David > > Jing Ruiquan wrote: > >>I think only the originating node should do the rerouting with >>RSVP-TE .At the same time, all the nodes will converge their IGP routing > > data base. > >>Rick >> >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >>Behalf Of David Charlap >>Sent: Thursday, September 29, 2005 2:37 AM >>To: IETF MPLS List; IETF CCAMP List >>Subject: Graceful restart - inter-protocol dependencies >> >>Is there any point to implementing RSVP-TE's graceful restart without >>also implementing graceful restart for routing protocols? >> >>On the one hand, RSVP doesn't require routing to recover LSPs. It >>knows the next-hop interface, because of the preserved data-plane > > connection. > >> Whatever other information it may need, the switch can either >>preserve this information or recover it from a neighbor using the >>RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03). >> >>On the other hand, nodes more than one hop upstream of the failure >>will detect the loss of routing-connectivity to the failed node if IGP >>graceful restart is not also implemented. They may reroute the LSP >>away from the failed node, or tear it down altogether, even though the >>data plane is still active and RSVP graceful restart is recovering the > > control-plane state. > >>An originating node may consider the destination unreachable, as a >>result of losing the routes even though the data-plane for the LSP is >>still up (which can be confirmed via OAM.) >> >>A transit node, when processing an loose ERO-hop, may choose to >>reroute or fail the LSP if its local topology information says that >>the failed (and >>restarting) node is not available. It might even choose to do this >>for an established LSP, as a result of Path refresh processing. >> >>My questions are: >> >>1: Does this mean it's pointless to use RSVP graceful restart without >> also using IGP graceful restart (for whatever IGP is active). >> >>2: Is IGP graceful restart sufficient to prevent this problem? For >> instance, OSPF's restart procedure requires all preserved state to >> be thrown away if a topology change is detected. >> >>3: An originating node can use OAM to validate the data plane of an >> LSP, and choose to ignore what routing tells it about the >> destination's reachability. But what about transit nodes? As far >> as I know, MPLS doesn't support segment-OAM, and it would be >> prohibitive for every transit node to run its own OAM streams >> to detect self-to-end connectivity. >> >>4: Are there other solutions to this problem? >> >>One possible solution might be route-pinning, but RSVP doesn't have a >>built-in mechanism for this. The usual workaround (signal the LSP, >>requesting route-recording, then turn the RRO into an ERO for >>subsequent >>refreshes) can work, but are there situations where even this would be >>insufficient to prevent a transit node from rerouting/tearing the >>connection in this particular situation (where RSVP is doing a >>graceful restart but the IGP is not)? >> >>-- David > > From owner-ccamp@ops.ietf.org Fri Sep 30 10:59:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELMMY-0005Jv-Um for ccamp-archive@megatron.ietf.org; Fri, 30 Sep 2005 10:59:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15784 for ; Fri, 30 Sep 2005 10:59:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELMUL-0007sR-By for ccamp-archive@ietf.org; Fri, 30 Sep 2005 11:08:00 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELME8-000Gkg-UA for ccamp-data@psg.com; Fri, 30 Sep 2005 14:51:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.52 (FreeBSD)) id 1ELME7-000GkK-SS for ccamp@ops.ietf.org; Fri, 30 Sep 2005 14:51:08 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id 603D5144EB; Fri, 30 Sep 2005 10:51:06 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Fri, 30 Sep 2005 10:51:06 -0400 (EDT) Message-ID: <3648.68.100.80.11.1128091866.squirrel@webmail.movaz.com> In-Reply-To: <433D4591.4080308@marconi.com> References: <433D4591.4080308@marconi.com> Date: Fri, 30 Sep 2005 10:51:06 -0400 (EDT) Subject: Re: Graceful restart - inter-protocol dependencies From: ibryskin@movaz.com To: "David Charlap" Cc: "'IETF MPLS List'" , "'IETF CCAMP List'" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: 8bit David, I think your view on the RSVP-TE is a bit obsolete. The signaling subsystem should only react on the *data plane* events (e.g. detected data plane failures) rather than on the events that happen in routing. Routing events may at maximum cause the LSP ingress (or more precisely path computation entity that performed path computation for the LSP) to re-evaluate the path. Note also that TE paths are computed based on IGP-TE advertisings rather than on IGP advertisings and a failure of a an IP link does not necessarily change the latter. This is more obvious in non-packet switched networks, but is very true in IP networks as well The bottom line: a) An intermediate LSR should never attempt to re-route TE LSP based on IGP events b) Detected data plane failures should be signaled (via data or control plane) to the LSP ingress LSR or other LSR(s) responsible for recovery, and recovery action may (restoration) or may not (protection) result in the LSP rerouting. The latter may happen even if there were no changes detected by IGP (in fact, operation is completely orthogonal to what happens in IP routing) c) It is perfectly reasonable to implement the RSVP-TE graceful restart without implementing OSPF graceful restart. Again, the two are not related. Igor > Then we are talking about different protocols. I'm specifically > referring to RSVP-TE, as defined by RFC 3209. > > I am aware that RSVP-TE's signaling mechanism (even just a PathErr > message) will probably reach the ingress node long before routing can > reconverge. But that's not the question. > > The question is, if the node failure is due to a restart, and it has > implemented RSVP-TE restart (yes, I'm aware that this is a GMPLS > extnsion), but has not implemented graceful restart for any routing > protocols, then the originating node won't receive any RSVP-level > information about the restarting node. But the IGP will. > > We want to prevent the reroute that would normally happen as a result of > the route change. Originating nodes can test the LSP using OAM, if > there is no other choice, but transit nodes don't have that option. > > Ultimately, this comes down to my original questions: > > Does it make any sense to use RSVP graceful restart in a > network where graceful restart is not being used for any > routing protocols? > > If the answer to the previous question is yes, what can be > done (if anything) to prevent originating and transit nodes > from rerouting LSPs as a result of the route-table change? > > -- David > > Jing Ruiquan wrote: >> Hi David, >> >> We should specify which version of RSVP we are talking. What I have said >> is >> about GMPLS RSVP-TE as used in ASON. >> >> When there is a failed link within the network, the ingress node will >> know >> the failure by transport plan OAM mechanism such as SDH path layer AIS, >> or >> by RSVP-TE Notify message. And usually these mechanisms are faster than >> routing protocol convergence speed. After the ingress node knows which >> link >> or route has failed, it will do the rerouting while excluding the failed >> link or route. >> >> Hope I say it clearly :-) >> >> Rick >> >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf >> Of David Charlap >> Sent: Thursday, September 29, 2005 10:35 PM >> To: 'IETF MPLS List'; 'IETF CCAMP List' >> Subject: Re: Graceful restart - inter-protocol dependencies >> >> But RSVP doesn't work this way. It is a soft-state protocol. >> >> If the route table changes such that the next-hop interface changes, >> RSVP is >> supposed to reroute the connection accordingly. >> >> This probably won't happen if the next-hop is a strict-hop in an ERO, >> but it >> can easily happen if the next-hop is loose or if the LSP is signaled >> without >> an ERO (meaning routing is consulted to determine the next-hop to the >> egress >> node.) >> >> If there is a paragraph in an RFC that says RSVP-TE should ignore all >> route-table changes once an LSP comes up, I missed it. >> >> -- David >> >> Jing Ruiquan wrote: >> >>>I think only the originating node should do the rerouting with >>>RSVP-TE .At the same time, all the nodes will converge their IGP routing >> >> data base. >> >>>Rick >>> >>>-----Original Message----- >>>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >>>Behalf Of David Charlap >>>Sent: Thursday, September 29, 2005 2:37 AM >>>To: IETF MPLS List; IETF CCAMP List >>>Subject: Graceful restart - inter-protocol dependencies >>> >>>Is there any point to implementing RSVP-TE's graceful restart without >>>also implementing graceful restart for routing protocols? >>> >>>On the one hand, RSVP doesn't require routing to recover LSPs. It >>>knows the next-hop interface, because of the preserved data-plane >> >> connection. >> >>> Whatever other information it may need, the switch can either >>>preserve this information or recover it from a neighbor using the >>>RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03). >>> >>>On the other hand, nodes more than one hop upstream of the failure >>>will detect the loss of routing-connectivity to the failed node if IGP >>>graceful restart is not also implemented. They may reroute the LSP >>>away from the failed node, or tear it down altogether, even though the >>>data plane is still active and RSVP graceful restart is recovering the >> >> control-plane state. >> >>>An originating node may consider the destination unreachable, as a >>>result of losing the routes even though the data-plane for the LSP is >>>still up (which can be confirmed via OAM.) >>> >>>A transit node, when processing an loose ERO-hop, may choose to >>>reroute or fail the LSP if its local topology information says that >>>the failed (and >>>restarting) node is not available. It might even choose to do this >>>for an established LSP, as a result of Path refresh processing. >>> >>>My questions are: >>> >>>1: Does this mean it's pointless to use RSVP graceful restart without >>> also using IGP graceful restart (for whatever IGP is active). >>> >>>2: Is IGP graceful restart sufficient to prevent this problem? For >>> instance, OSPF's restart procedure requires all preserved state to >>> be thrown away if a topology change is detected. >>> >>>3: An originating node can use OAM to validate the data plane of an >>> LSP, and choose to ignore what routing tells it about the >>> destination's reachability. But what about transit nodes? As far >>> as I know, MPLS doesn't support segment-OAM, and it would be >>> prohibitive for every transit node to run its own OAM streams >>> to detect self-to-end connectivity. >>> >>>4: Are there other solutions to this problem? >>> >>>One possible solution might be route-pinning, but RSVP doesn't have a >>>built-in mechanism for this. The usual workaround (signal the LSP, >>>requesting route-recording, then turn the RRO into an ERO for >>>subsequent >>>refreshes) can work, but are there situations where even this would be >>>insufficient to prevent a transit node from rerouting/tearing the >>>connection in this particular situation (where RSVP is doing a >>>graceful restart but the IGP is not)? >>> >>>-- David >> >> > > > From owner-ccamp@ops.ietf.org Fri Sep 30 18:43:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELTb8-0006lW-6e for ccamp-archive@megatron.ietf.org; Fri, 30 Sep 2005 18:43:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24060 for ; Fri, 30 Sep 2005 18:43:19 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELTj3-0000US-8S for ccamp-archive@ietf.org; Fri, 30 Sep 2005 18:51:35 -0400 Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD)) id 1ELTRa-0002lH-8N for ccamp-data@psg.com; Fri, 30 Sep 2005 22:33:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,HTML_90_100, HTML_MESSAGE,HTML_SHOUTING7,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [205.177.121.2] (helo=ns1.cpanel.btnaccess.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.52 (FreeBSD)) id 1ELTRY-0002l3-JZ for ccamp@ops.ietf.org; Fri, 30 Sep 2005 22:33:29 +0000 Received: from [65.213.193.13] (helo=) by ns1.cpanel.btnaccess.com with smtp (Exim 4.52) id 1ELTRW-0006q5-8J for ccamp@ops.ietf.org; Fri, 30 Sep 2005 18:33:26 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="==========_ALT_1451519089_=====" From: "MPLS 2005" To: ccamp@ops.ietf.org Subject: Register Now to Attend MPLS 2005 (Oct 16-19) Washington, DC X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: Date: Fri, 30 Sep 2005 22:33:30 +0000 X-Spam-Score: 1.6 (+) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 NOTE: You are reading this note because your email program does not support messages in multi-part "MIME" format (you can see the plain text version of the message, but the HTML version is garbled). The best solution to this problem is to upgrade to an email program that supports MIME. If you can't do that, then just ignore the part of this message that is improperly displayed by your current email program. --==========_ALT_1451519089_===== Content-Type: text/plain; charset=us-ascii MPLS 2005 International Conference - Washington, DC OCTOBER 16-19, 2005 8th Annual International Conference on MPLS and Related Technologies Book your hotel today, the special conference rates end 10/4! Register now to secure your seat today Register online to save $200.00 http://www.mpls2005.com/registration.htm =================================================================== =============================================================== Key next generation Internet technologies in one event =============================================================== Dear Colleague, =========================================================== MPLS 2005 International Conference Conference: October 16-19, 2005 Exhibits: October 17-19, 2005 Omni Shoreham Hotel-Washington, DC www.mpls2005.com =========================================================== **************************************************** 6th Public Interoperability Demonstration October 20 http://www.mpls2005.com/program.htm To attend send a message to anusha@isocore.com **************************************************** --==========_ALT_1451519089_===== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA24060 a{text-decoration:none;} a:hover{text-decoration:none;} MPLS 2005 International Conference =20
=20 =20 =20
=A0

=09

=A0 =A0 =20 Speaker Area
=A0 =A0 (password required)

Tel:
=A0 =A0 703.860.1777
Email:
=A0 =A0 mp= ls2005-info@isocore.com

=A0=20
=20

Book your hotel today, the special co= nference rates end 10/4!

MPLS 2005 INTERNATIONAL CONFERENCE
OCTOBER 16-19, 2005
OMNI SHOREHAM HOTEL
WASHINGTON, DC
8th Annual International=20 Conference on
MPLS and Related Technologies

=20

=20
=09
3D"Registration"=20

=20 =20 =09

Conference Chair

 =A0

Technical Co-Chairs
3D"=           =20

=3D"Adrian

Adrian Farrel
Old Dog Consulting,
Co-chair IETF's CCAMP, PCE and L1VPN WGs


3D"David

David McDysan
MCI

=20 =20

Conference Program=20 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Inter-Op Demo=20


PLATINUM SPONSORS:
3D"A= =A0 =A0=20 =20 =A0 =A0 3D"Chiaro" =A0 =A0 3D"Cisco" =A0 =A0 3D"Isocore" =A0 =A0 3D"Juniper" =A0 =A0 3D"Lucent" =A0 =A0 3D"Nortel" =A0 =A0 3D"Reef =A0 =A0 3D"Tellabs"

=3D"Keihanna"
=A0 =A0
GOLD SPONSORS:
3D"Alcatel" =A0 =A0 3D"Ciena" =A0 =A0 3D"Extreme =A0 =A0 3D"Fujitsu" =A0 =A0 3D"IXIA" =A0 =A0 =A0 =A0 3D"Mangrove" =A0 =A0 3D"Redback" =A0 =A0 3D"Spirent =A0 =A0 3D"WANDL"
=20
=A0=20

=A9 2005 ISOCORE CORP. ALL RIGHTS RESERVED=A0=
--==========_ALT_1451519089_=====-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Sep 2005 22:35:23 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="==========_ALT_1451519089_=====" Content-Transfer-Encoding: 7bit From: "MPLS 2005" To: ccamp@ops.ietf.org Subject: Register Now to Attend MPLS 2005 (Oct 16-19) Washington, DC Message-Id: Date: Fri, 30 Sep 2005 22:33:30 +0000 NOTE: You are reading this note because your email program does not support messages in multi-part "MIME" format (you can see the plain text version of the message, but the HTML version is garbled). The best solution to this problem is to upgrade to an email program that supports MIME. If you can't do that, then just ignore the part of this message that is improperly displayed by your current email program. --==========_ALT_1451519089_===== Content-Type: text/plain; charset=us-ascii MPLS 2005 International Conference - Washington, DC OCTOBER 16-19, 2005 8th Annual International Conference on MPLS and Related Technologies Book your hotel today, the special conference rates end 10/4! Register now to secure your seat today Register online to save $200.00 http://www.mpls2005.com/registration.htm =================================================================== =============================================================== Key next generation Internet technologies in one event =============================================================== Dear Colleague, =========================================================== MPLS 2005 International Conference Conference: October 16-19, 2005 Exhibits: October 17-19, 2005 Omni Shoreham Hotel-Washington, DC www.mpls2005.com =========================================================== **************************************************** 6th Public Interoperability Demonstration October 20 http://www.mpls2005.com/program.htm To attend send a message to anusha@isocore.com **************************************************** --==========_ALT_1451519089_===== Content-Type: text/html; charset=us-ascii MPLS 2005 International Conference
 

    Speaker Area
    (password required)

Tel:
    703.860.1777
Email:
    mpls2005-info@isocore.com

 

Book your hotel today, the special conference rates end 10/4!

MPLS 2005 INTERNATIONAL CONFERENCE
OCTOBER 16-19, 2005
OMNI SHOREHAM HOTEL
WASHINGTON, DC
8th Annual International Conference on
MPLS and Related Technologies

Conference Chair

  

Technical Co-Chairs
T. Okada & J. Agogbua          

Adrian Farrel

Adrian Farrel
Old Dog Consulting,
Co-chair IETF's CCAMP, PCE and L1VPN WGs


David McDysan

David McDysan
MCI

Conference Program                             Inter-Op Demo


PLATINUM SPONSORS:
ADC     Avici     Chiaro     Cisco     Isocore     Juniper     Lucent     Nortel     Reef Point     Tellabs

Keihanna
   
GOLD SPONSORS:
Alcatel     Ciena     Extreme Networks     Fujitsu     IXIA     ECI Telecom     Mangrove     Redback     Spirent Communications     WANDL
 

© 2005 ISOCORE CORP. ALL RIGHTS RESERVED 
--==========_ALT_1451519089_=====-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Sep 2005 14:52:20 +0000 Message-ID: <3648.68.100.80.11.1128091866.squirrel@webmail.movaz.com> Date: Fri, 30 Sep 2005 10:51:06 -0400 (EDT) Subject: Re: Graceful restart - inter-protocol dependencies From: ibryskin@movaz.com To: "David Charlap" Cc: "'IETF MPLS List'" , "'IETF CCAMP List'" User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit David, I think your view on the RSVP-TE is a bit obsolete. The signaling subsystem should only react on the *data plane* events (e.g. detected data plane failures) rather than on the events that happen in routing. Routing events may at maximum cause the LSP ingress (or more precisely path computation entity that performed path computation for the LSP) to re-evaluate the path. Note also that TE paths are computed based on IGP-TE advertisings rather than on IGP advertisings and a failure of a an IP link does not necessarily change the latter. This is more obvious in non-packet switched networks, but is very true in IP networks as well The bottom line: a) An intermediate LSR should never attempt to re-route TE LSP based on IGP events b) Detected data plane failures should be signaled (via data or control plane) to the LSP ingress LSR or other LSR(s) responsible for recovery, and recovery action may (restoration) or may not (protection) result in the LSP rerouting. The latter may happen even if there were no changes detected by IGP (in fact, operation is completely orthogonal to what happens in IP routing) c) It is perfectly reasonable to implement the RSVP-TE graceful restart without implementing OSPF graceful restart. Again, the two are not related. Igor > Then we are talking about different protocols. I'm specifically > referring to RSVP-TE, as defined by RFC 3209. > > I am aware that RSVP-TE's signaling mechanism (even just a PathErr > message) will probably reach the ingress node long before routing can > reconverge. But that's not the question. > > The question is, if the node failure is due to a restart, and it has > implemented RSVP-TE restart (yes, I'm aware that this is a GMPLS > extnsion), but has not implemented graceful restart for any routing > protocols, then the originating node won't receive any RSVP-level > information about the restarting node. But the IGP will. > > We want to prevent the reroute that would normally happen as a result of > the route change. Originating nodes can test the LSP using OAM, if > there is no other choice, but transit nodes don't have that option. > > Ultimately, this comes down to my original questions: > > Does it make any sense to use RSVP graceful restart in a > network where graceful restart is not being used for any > routing protocols? > > If the answer to the previous question is yes, what can be > done (if anything) to prevent originating and transit nodes > from rerouting LSPs as a result of the route-table change? > > -- David > > Jing Ruiquan wrote: >> Hi David, >> >> We should specify which version of RSVP we are talking. What I have said >> is >> about GMPLS RSVP-TE as used in ASON. >> >> When there is a failed link within the network, the ingress node will >> know >> the failure by transport plan OAM mechanism such as SDH path layer AIS, >> or >> by RSVP-TE Notify message. And usually these mechanisms are faster than >> routing protocol convergence speed. After the ingress node knows which >> link >> or route has failed, it will do the rerouting while excluding the failed >> link or route. >> >> Hope I say it clearly :-) >> >> Rick >> >> -----Original Message----- >> From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >> Behalf >> Of David Charlap >> Sent: Thursday, September 29, 2005 10:35 PM >> To: 'IETF MPLS List'; 'IETF CCAMP List' >> Subject: Re: Graceful restart - inter-protocol dependencies >> >> But RSVP doesn't work this way. It is a soft-state protocol. >> >> If the route table changes such that the next-hop interface changes, >> RSVP is >> supposed to reroute the connection accordingly. >> >> This probably won't happen if the next-hop is a strict-hop in an ERO, >> but it >> can easily happen if the next-hop is loose or if the LSP is signaled >> without >> an ERO (meaning routing is consulted to determine the next-hop to the >> egress >> node.) >> >> If there is a paragraph in an RFC that says RSVP-TE should ignore all >> route-table changes once an LSP comes up, I missed it. >> >> -- David >> >> Jing Ruiquan wrote: >> >>>I think only the originating node should do the rerouting with >>>RSVP-TE .At the same time, all the nodes will converge their IGP routing >> >> data base. >> >>>Rick >>> >>>-----Original Message----- >>>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >>>Behalf Of David Charlap >>>Sent: Thursday, September 29, 2005 2:37 AM >>>To: IETF MPLS List; IETF CCAMP List >>>Subject: Graceful restart - inter-protocol dependencies >>> >>>Is there any point to implementing RSVP-TE's graceful restart without >>>also implementing graceful restart for routing protocols? >>> >>>On the one hand, RSVP doesn't require routing to recover LSPs. It >>>knows the next-hop interface, because of the preserved data-plane >> >> connection. >> >>> Whatever other information it may need, the switch can either >>>preserve this information or recover it from a neighbor using the >>>RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03). >>> >>>On the other hand, nodes more than one hop upstream of the failure >>>will detect the loss of routing-connectivity to the failed node if IGP >>>graceful restart is not also implemented. They may reroute the LSP >>>away from the failed node, or tear it down altogether, even though the >>>data plane is still active and RSVP graceful restart is recovering the >> >> control-plane state. >> >>>An originating node may consider the destination unreachable, as a >>>result of losing the routes even though the data-plane for the LSP is >>>still up (which can be confirmed via OAM.) >>> >>>A transit node, when processing an loose ERO-hop, may choose to >>>reroute or fail the LSP if its local topology information says that >>>the failed (and >>>restarting) node is not available. It might even choose to do this >>>for an established LSP, as a result of Path refresh processing. >>> >>>My questions are: >>> >>>1: Does this mean it's pointless to use RSVP graceful restart without >>> also using IGP graceful restart (for whatever IGP is active). >>> >>>2: Is IGP graceful restart sufficient to prevent this problem? For >>> instance, OSPF's restart procedure requires all preserved state to >>> be thrown away if a topology change is detected. >>> >>>3: An originating node can use OAM to validate the data plane of an >>> LSP, and choose to ignore what routing tells it about the >>> destination's reachability. But what about transit nodes? As far >>> as I know, MPLS doesn't support segment-OAM, and it would be >>> prohibitive for every transit node to run its own OAM streams >>> to detect self-to-end connectivity. >>> >>>4: Are there other solutions to this problem? >>> >>>One possible solution might be route-pinning, but RSVP doesn't have a >>>built-in mechanism for this. The usual workaround (signal the LSP, >>>requesting route-recording, then turn the RRO into an ERO for >>>subsequent >>>refreshes) can work, but are there situations where even this would be >>>insufficient to prevent a transit node from rerouting/tearing the >>>connection in this particular situation (where RSVP is doing a >>>graceful restart but the IGP is not)? >>> >>>-- David >> >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Sep 2005 14:04:46 +0000 Message-ID: <433D4591.4080308@marconi.com> Date: Fri, 30 Sep 2005 10:02:57 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: "'IETF MPLS List'" , "'IETF CCAMP List'" Subject: Re: Graceful restart - inter-protocol dependencies Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Then we are talking about different protocols. I'm specifically referring to RSVP-TE, as defined by RFC 3209. I am aware that RSVP-TE's signaling mechanism (even just a PathErr message) will probably reach the ingress node long before routing can reconverge. But that's not the question. The question is, if the node failure is due to a restart, and it has implemented RSVP-TE restart (yes, I'm aware that this is a GMPLS extnsion), but has not implemented graceful restart for any routing protocols, then the originating node won't receive any RSVP-level information about the restarting node. But the IGP will. We want to prevent the reroute that would normally happen as a result of the route change. Originating nodes can test the LSP using OAM, if there is no other choice, but transit nodes don't have that option. Ultimately, this comes down to my original questions: Does it make any sense to use RSVP graceful restart in a network where graceful restart is not being used for any routing protocols? If the answer to the previous question is yes, what can be done (if anything) to prevent originating and transit nodes from rerouting LSPs as a result of the route-table change? -- David Jing Ruiquan wrote: > Hi David, > > We should specify which version of RSVP we are talking. What I have said is > about GMPLS RSVP-TE as used in ASON. > > When there is a failed link within the network, the ingress node will know > the failure by transport plan OAM mechanism such as SDH path layer AIS, or > by RSVP-TE Notify message. And usually these mechanisms are faster than > routing protocol convergence speed. After the ingress node knows which link > or route has failed, it will do the rerouting while excluding the failed > link or route. > > Hope I say it clearly :-) > > Rick > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of David Charlap > Sent: Thursday, September 29, 2005 10:35 PM > To: 'IETF MPLS List'; 'IETF CCAMP List' > Subject: Re: Graceful restart - inter-protocol dependencies > > But RSVP doesn't work this way. It is a soft-state protocol. > > If the route table changes such that the next-hop interface changes, RSVP is > supposed to reroute the connection accordingly. > > This probably won't happen if the next-hop is a strict-hop in an ERO, but it > can easily happen if the next-hop is loose or if the LSP is signaled without > an ERO (meaning routing is consulted to determine the next-hop to the egress > node.) > > If there is a paragraph in an RFC that says RSVP-TE should ignore all > route-table changes once an LSP comes up, I missed it. > > -- David > > Jing Ruiquan wrote: > >>I think only the originating node should do the rerouting with >>RSVP-TE .At the same time, all the nodes will converge their IGP routing > > data base. > >>Rick >> >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On >>Behalf Of David Charlap >>Sent: Thursday, September 29, 2005 2:37 AM >>To: IETF MPLS List; IETF CCAMP List >>Subject: Graceful restart - inter-protocol dependencies >> >>Is there any point to implementing RSVP-TE's graceful restart without >>also implementing graceful restart for routing protocols? >> >>On the one hand, RSVP doesn't require routing to recover LSPs. It >>knows the next-hop interface, because of the preserved data-plane > > connection. > >> Whatever other information it may need, the switch can either >>preserve this information or recover it from a neighbor using the >>RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03). >> >>On the other hand, nodes more than one hop upstream of the failure >>will detect the loss of routing-connectivity to the failed node if IGP >>graceful restart is not also implemented. They may reroute the LSP >>away from the failed node, or tear it down altogether, even though the >>data plane is still active and RSVP graceful restart is recovering the > > control-plane state. > >>An originating node may consider the destination unreachable, as a >>result of losing the routes even though the data-plane for the LSP is >>still up (which can be confirmed via OAM.) >> >>A transit node, when processing an loose ERO-hop, may choose to >>reroute or fail the LSP if its local topology information says that >>the failed (and >>restarting) node is not available. It might even choose to do this >>for an established LSP, as a result of Path refresh processing. >> >>My questions are: >> >>1: Does this mean it's pointless to use RSVP graceful restart without >> also using IGP graceful restart (for whatever IGP is active). >> >>2: Is IGP graceful restart sufficient to prevent this problem? For >> instance, OSPF's restart procedure requires all preserved state to >> be thrown away if a topology change is detected. >> >>3: An originating node can use OAM to validate the data plane of an >> LSP, and choose to ignore what routing tells it about the >> destination's reachability. But what about transit nodes? As far >> as I know, MPLS doesn't support segment-OAM, and it would be >> prohibitive for every transit node to run its own OAM streams >> to detect self-to-end connectivity. >> >>4: Are there other solutions to this problem? >> >>One possible solution might be route-pinning, but RSVP doesn't have a >>built-in mechanism for this. The usual workaround (signal the LSP, >>requesting route-recording, then turn the RRO into an ERO for >>subsequent >>refreshes) can work, but are there situations where even this would be >>insufficient to prevent a transit node from rerouting/tearing the >>connection in this particular situation (where RSVP is doing a >>graceful restart but the IGP is not)? >> >>-- David > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Sep 2005 12:48:52 +0000 Message-ID: <053d01c5c512$ea3740e0$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Re: questions Date: Thu, 29 Sep 2005 17:29:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alok, CCAMP is not really the place for this, but you can go ahead and ask here. There are folks on this list that should be able to answer you or point you at their books. Cheers, Adrian ----- Original Message ----- From: "Alok" To: Sent: Thursday, September 29, 2005 5:02 PM Subject: questions > I may speak on behalf of a lot of friends/youngsters who do have questions > related to the bases of how Muxing works.. > and trying to understand the various VCs and containers and the reason they > exist. > > Is it ok for new comers, who really dont understand transmissions and all > those VT pointers to ask questions on the list.... > > > > -thanks > Alok > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Sep 2005 10:45:09 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155082FB10F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, Adrian Farrel , tnadeau@cisco.com, ccamp@ops.ietf.org Cc: bwijnen@lucent.com Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Fri, 30 Sep 2005 12:43:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" W.r.t. > > > 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpReverseLabelPtr > > > > > > Please change Rvrs to Reverse. > > > > Nack > > Please see point 21 about name lengths > > In other objects in this MIB module are named using the entire > word Reverse ( e.g. > GmplsTunnelReversePerfEntry ::= SEQUENCE { > gmplsTunnelReversePerfPackets Counter32, > gmplsTunnelReversePerfHCPackets Counter64, > gmplsTunnelReversePerfErrors Counter32, > gmplsTunnelReversePerfBytes Counter32, > gmplsTunnelReversePerfHCBytes Counter64 > }) > > So please either change these to all use Rvrs or instead of Rvrs use > the entire word, Reverse. Similarly with the use of Fwd and Forward, > if you decide to use Reverse, then please use the entire word, Forward. > If you decide to use Rvrs, then please use Fwd. I prefer the words > spelled out but just please be consistent. > I have explained repeatedly (and it has been in the MIB review guidelines (now RFC4181) for a long time), the 32 char limit is relaxed. And in general, consistency is MUCH more important (I think) than limiting to 32 chars. Bert Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Sep 2005 10:45:02 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155082FB10E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, Adrian Farrel , tnadeau@cisco.com, ccamp@ops.ietf.org Cc: bwijnen@lucent.com Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Fri, 30 Sep 2005 12:43:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" W.r.t. > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Friday, September 30, 2005 04:14 > To: Adrian Farrel; tnadeau@cisco.com; ccamp@ops.ietf.org > Cc: bwijnen@lucent.com; jcucchiara@mindspring.com > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > .. snip .. > > > > > Section 8. GMPLS Traffic Engineering MIB Module > > > ----------------------------------------------- > > > > > > smicngPRO gives the following: > > > > > > W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should > > > have SIZE specified > > > > Ack > > Understood this to be optional, but planning to add size as > > per David's comments > > > > > W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is > > > identical > > > W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax > > > is identical > > > W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", syntax > > > is identical > > > > Nack > > Meaningless warning message. Cannot fix without explanation. > > > The object is defined as: > > > gmplsTunnelDirection OBJECT-TYPE > SYNTAX INTEGER { > forward (0), > bidirectional (1) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Whether this tunnel carries forward data only (is > unidirectional) or is bidirectional. > > Values of this object other than 'forward' are meaningful > only if gmplsTunnelLSPEncoding is not set to > 'tunnelLspNotGmpls'." > DEFVAL { forward } > ::= { gmplsTunnelEntry 8 } > > > The following (part of the ReadOnly compliance statement) is causing > the warning because the SYNTAX defined in the object and the > SYNTAX below are the same. (Following the OBJECT are a > few alternatives.) > > OBJECT gmplsTunnelDirection > SYNTAX INTEGER { > forward (0), > bidirectional (1) > } > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > > If you do intend for the SYNTAX in both the OBJECT-TYPE and > the OBJECT to be the same, then removing it from the OBJECT > would get rid of the warning. This is not a blocking issue, but > it is duplicate info that does not need to be duplicated. > So here is what the OBJECT statement would like: > > OBJECT gmplsTunnelDirection > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > Another alternative would be to specify forward(0) only since > this is what the DESCRIPTION is specifying, however, it is > likely that you are probably allowing both, so I don't think this > is what you intend, but this would also solve the compiler warning: > > OBJECT gmplsTunnelDirection > SYNTAX INTEGER { > forward (0), > } > MIN-ACCESS read-only > DESCRIPTION > "Only forward (0) is required." > > This last one is (in my view) the only correct one. The SYNTAX in fact is inline with what is in the DESCRIPTION clause. And that is in my view IMPORTANT. Bert Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Sep 2005 06:14:08 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Graceful restart - inter-protocol dependencies Date: Fri, 30 Sep 2005 07:12:35 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A3538911800733@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Graceful restart - inter-protocol dependencies Thread-Index: AcXFZY4WAglBl5cGQ7e3Aa1Qqa/MOQAF+Sjw From: To: , Rick....you must differentiate the co-cs mode case from the co-ps case. They both belong to the co mode BUT there are very significant differences....indeed, the 3 network modes arise by the way constraints are applied to a unified networking model (and if you are active in ITU then check out what is happening in SG15 on this topic). In the co-cs mode case the constraints mean the following behaviours are FORCED: - control/management OOB.....this means that in a co-cs network system there is more than 1 data-plane network. This has major implications on the design of these networks (wrt addressing, security, resilience, stability, etc); - the only traffic carrying trail constructs allowed are p2p and p2mp, ie no merging is possible......and these are the ONLY trail constructs that allow deterministic traffic/fault/performance management anyway; - a trail MUST complete between trail source and sink points as this is where the characteristic information is processed that looks after the integrity of the trail (eg OAM stuff); - there are no QoS/traffic classes.....this looks like a throwaway remark but it's extremely important.....especially when considering network builder services, ie when building a client layer topology this defines performance inheritance behaviour; - true client/server relationships can exist, ie complete functional decoupling of client and server layer networks....again absolutely critical for a whole raft of factors (security, scalability,...) when considering network builder services. Now add these observation to my previous ones (eg the importance of the trail object (which I think many folks still don't really get), and how once created it gets decoupled from the routing process) and you start to get the picture of the required behaviour of a co mode technology. Its jolly hard to get things wrong with the co-cs mode but this is not true for the co-ps mode. However, there is no reason why the co-ps mode should not reproduce the important behaviours, and in doing so re-use the components (eg similar OOB design, signalling), that apply to co-cs mode technologies.....indeed when we kicked off the ASON work this was precisely what was in our minds. And as a more general observation here: When folks talk about convergence there is a lot of confusion as to what this really means....it for sure does NOT mean that (i) 1 network mode/technology can do it all, nor does it mean (ii) one can somehow 'functionally crunch' all 3 networking modes and treat them alike. What is does mean however is that we don't need lots of different technologies belonging to the SAME mode (as this creates duplication/waste and leads to stovepipe services and downstream migration/interworking problems), but we do need all 3 modes working in concert....and wrt to this latter observation we can apply sensible component re-use, ergo the comment above wrt ASON. And the 'service' reason this is required is because (as we sunset PDH, lower rate SDH VC12, FR and ATM layer networks) we need a network builder service capability at bit rates smaller than SDH VC4. It's taking a lot longer then we expected for the above to be better understood but I can see strong signs now emerging that we are starting to get there. =20 regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > ruiquan.jing@ties.itu.int > Sent: 30 September 2005 03:17 > To: ccamp@ops.ietf.org > Subject: RE: Graceful restart - inter-protocol dependencies >=20 >=20 >=20 >=20 > Hi David, >=20 > We should specify which version of RSVP we are talking. What > I have said is=20 > about GMPLS RSVP-TE as used in ASON.=20 >=20 > When there is a failed link within the network, the ingress > node will know the=20 > failure by transport plan OAM mechanism such as SDH path=20 > layer AIS, or by RSVP- TE Notify message. And usually these=20 > mechanisms are faster than routing=20 > protocol convergence speed. After the ingress node knows=20 > which link or route=20 > has failed, it will do the rerouting while excluding the=20 > failed link or route.=20 >=20 > Hope I say it clearly :-) >=20 > Rick >=20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of=20 > David Charlap > Sent: Thursday, September 29, 2005 10:35 PM > To: 'IETF MPLS List'; 'IETF CCAMP List' > Subject: Re: Graceful restart - inter-protocol dependencies >=20 > But RSVP doesn't work this way. It is a soft-state protocol. >=20 > If the route table changes such that the next-hop interface > changes, RSVP is=20 > supposed to reroute the connection accordingly. >=20 > This probably won't happen if the next-hop is a strict-hop in > an ERO, but it=20 > can easily happen if the next-hop is loose or if the LSP is=20 > signaled without=20 > an ERO (meaning routing is consulted to determine the=20 > next-hop to the egress > node.) >=20 > If there is a paragraph in an RFC that says RSVP-TE should > ignore all route- table changes once an LSP comes up, I missed it. >=20 > -- David >=20 > Jing Ruiquan wrote: > > I think only the originating node should do the rerouting with=20 > > RSVP-TE .At the same time, all the nodes will converge their IGP=20 > > routing > data base. > >=20 > > Rick > >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On=20 > > Behalf Of David Charlap > > Sent: Thursday, September 29, 2005 2:37 AM > > To: IETF MPLS List; IETF CCAMP List > > Subject: Graceful restart - inter-protocol dependencies > >=20 > > Is there any point to implementing RSVP-TE's graceful > restart without > > also implementing graceful restart for routing protocols? > >=20 > > On the one hand, RSVP doesn't require routing to recover LSPs. It=20 > > knows the next-hop interface, because of the preserved data-plane > connection. > > Whatever other information it may need, the switch can either=20 > > preserve this information or recover it from a neighbor using the=20 > > RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03). > >=20 > > On the other hand, nodes more than one hop upstream of the failure=20 > > will detect the loss of routing-connectivity to the failed > node if IGP > > graceful restart is not also implemented. They may reroute the LSP > > away from the failed node, or tear it down altogether, even=20 > though the > > data plane is still active and RSVP graceful restart is > recovering the > control-plane state. > >=20 > > An originating node may consider the destination unreachable, as a=20 > > result of losing the routes even though the data-plane for > the LSP is > > still up (which can be confirmed via OAM.) > >=20 > > A transit node, when processing an loose ERO-hop, may choose to=20 > > reroute or fail the LSP if its local topology information says that=20 > > the failed (and > > restarting) node is not available. It might even choose to do this > > for an established LSP, as a result of Path refresh processing. > >=20 > > My questions are: > >=20 > > 1: Does this mean it's pointless to use RSVP graceful > restart without > > also using IGP graceful restart (for whatever IGP is active). > >=20 > > 2: Is IGP graceful restart sufficient to prevent this problem? For > > instance, OSPF's restart procedure requires all > preserved state to > > be thrown away if a topology change is detected. > >=20 > > 3: An originating node can use OAM to validate the data plane of an > > LSP, and choose to ignore what routing tells it about the > > destination's reachability. But what about transit > nodes? As far > > as I know, MPLS doesn't support segment-OAM, and it would be > > prohibitive for every transit node to run its own OAM streams > > to detect self-to-end connectivity. > >=20 > > 4: Are there other solutions to this problem? > >=20 > > One possible solution might be route-pinning, but RSVP > doesn't have a > > built-in mechanism for this. The usual workaround (signal the LSP, > > requesting route-recording, then turn the RRO into an ERO for=20 > > subsequent > > refreshes) can work, but are there situations where even=20 > this would be > > insufficient to prevent a transit node from rerouting/tearing the > > connection in this particular situation (where RSVP is doing a=20 > > graceful restart but the IGP is not)? > >=20 > > -- David >=20 >=20 >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Sep 2005 02:17:01 +0000 Message-ID: <1128046609.433ca01162e4b@gold.itu.ch> Date: Fri, 30 Sep 2005 04:16:49 +0200 From: ruiquan.jing@ties.itu.int To: ccamp@ops.ietf.org Subject: RE: Graceful restart - inter-protocol dependencies MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 Hi David, We should specify which version of RSVP we are talking. What I have said is about GMPLS RSVP-TE as used in ASON. When there is a failed link within the network, the ingress node will know the failure by transport plan OAM mechanism such as SDH path layer AIS, or by RSVP- TE Notify message. And usually these mechanisms are faster than routing protocol convergence speed. After the ingress node knows which link or route has failed, it will do the rerouting while excluding the failed link or route. Hope I say it clearly :-) Rick -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of David Charlap Sent: Thursday, September 29, 2005 10:35 PM To: 'IETF MPLS List'; 'IETF CCAMP List' Subject: Re: Graceful restart - inter-protocol dependencies But RSVP doesn't work this way. It is a soft-state protocol. If the route table changes such that the next-hop interface changes, RSVP is supposed to reroute the connection accordingly. This probably won't happen if the next-hop is a strict-hop in an ERO, but it can easily happen if the next-hop is loose or if the LSP is signaled without an ERO (meaning routing is consulted to determine the next-hop to the egress node.) If there is a paragraph in an RFC that says RSVP-TE should ignore all route- table changes once an LSP comes up, I missed it. -- David Jing Ruiquan wrote: > I think only the originating node should do the rerouting with > RSVP-TE .At the same time, all the nodes will converge their IGP > routing data base. > > Rick > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On > Behalf Of David Charlap > Sent: Thursday, September 29, 2005 2:37 AM > To: IETF MPLS List; IETF CCAMP List > Subject: Graceful restart - inter-protocol dependencies > > Is there any point to implementing RSVP-TE's graceful restart without > also implementing graceful restart for routing protocols? > > On the one hand, RSVP doesn't require routing to recover LSPs. It > knows the next-hop interface, because of the preserved data-plane connection. > Whatever other information it may need, the switch can either > preserve this information or recover it from a neighbor using the > RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03). > > On the other hand, nodes more than one hop upstream of the failure > will detect the loss of routing-connectivity to the failed node if IGP > graceful restart is not also implemented. They may reroute the LSP > away from the failed node, or tear it down altogether, even though the > data plane is still active and RSVP graceful restart is recovering the control-plane state. > > An originating node may consider the destination unreachable, as a > result of losing the routes even though the data-plane for the LSP is > still up (which can be confirmed via OAM.) > > A transit node, when processing an loose ERO-hop, may choose to > reroute or fail the LSP if its local topology information says that > the failed (and > restarting) node is not available. It might even choose to do this > for an established LSP, as a result of Path refresh processing. > > My questions are: > > 1: Does this mean it's pointless to use RSVP graceful restart without > also using IGP graceful restart (for whatever IGP is active). > > 2: Is IGP graceful restart sufficient to prevent this problem? For > instance, OSPF's restart procedure requires all preserved state to > be thrown away if a topology change is detected. > > 3: An originating node can use OAM to validate the data plane of an > LSP, and choose to ignore what routing tells it about the > destination's reachability. But what about transit nodes? As far > as I know, MPLS doesn't support segment-OAM, and it would be > prohibitive for every transit node to run its own OAM streams > to detect self-to-end connectivity. > > 4: Are there other solutions to this problem? > > One possible solution might be route-pinning, but RSVP doesn't have a > built-in mechanism for this. The usual workaround (signal the LSP, > requesting route-recording, then turn the RRO into an ERO for > subsequent > refreshes) can work, but are there situations where even this would be > insufficient to prevent a transit node from rerouting/tearing the > connection in this particular situation (where RSVP is doing a > graceful restart but the IGP is not)? > > -- David Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Sep 2005 02:12:56 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=akGa6jq7x3a4BeYbt80YoEldkYcquns5+LGYn+WeBoV/YizhIvAYw50/UPj6vIax; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <027b01c5c564$8fcff820$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , , Cc: , Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Thu, 29 Sep 2005 22:13:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit hi Adrian, Please see comments inline below, I have snipped parts where we are in agreement. thanks, joan ----- Original Message ----- From: Adrian Farrel To: ; ; Cc: ; Sent: Thursday, September 22, 2005 8:59 AM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt > Hi Joan, > > Last but not least, the GMPLS TE MIB module. > > > Here are some comments on draft-ietf-ccamp-gmpls-te-mib-09.txt. > > All 3 docs show a good deal of work. > > Yes, but fortunatley most of the work appears to be editorial with only > very minor changes to the basis of the module. > > Please find acks and nacks in line below. > > We will also include the comments made by David and Tom Petch. > > Cheers, > Adrian > > > > Section 8. GMPLS Traffic Engineering MIB Module > > ----------------------------------------------- > > > > smicngPRO gives the following: > > > > W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should > have > > SIZE specified > > Ack > Understood this to be optional, but planning to add size as per David's > comments > > > W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is > > identical > > W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is > > identical > > W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is > > identical > > W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax > is > > identical > > W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", > syntax > > is identical > > Nack > Meaningless warning message. Cannot fix without explanation. The object is defined as: gmplsTunnelDirection OBJECT-TYPE SYNTAX INTEGER { forward (0), bidirectional (1) } MAX-ACCESS read-create STATUS current DESCRIPTION "Whether this tunnel carries forward data only (is unidirectional) or is bidirectional. Values of this object other than 'forward' are meaningful only if gmplsTunnelLSPEncoding is not set to 'tunnelLspNotGmpls'." DEFVAL { forward } ::= { gmplsTunnelEntry 8 } The following (part of the ReadOnly compliance statement) is causing the warning because the SYNTAX defined in the object and the SYNTAX below are the same. (Following the OBJECT are a few alternatives.) OBJECT gmplsTunnelDirection SYNTAX INTEGER { forward (0), bidirectional (1) } MIN-ACCESS read-only DESCRIPTION "Only forward (0) is required." If you do intend for the SYNTAX in both the OBJECT-TYPE and the OBJECT to be the same, then removing it from the OBJECT would get rid of the warning. This is not a blocking issue, but it is duplicate info that does not need to be duplicated. So here is what the OBJECT statement would like: OBJECT gmplsTunnelDirection MIN-ACCESS read-only DESCRIPTION "Only forward (0) is required." Another alternative would be to specify forward(0) only since this is what the DESCRIPTION is specifying, however, it is likely that you are probably allowing both, so I don't think this is what you intend, but this would also solve the compiler warning: OBJECT gmplsTunnelDirection SYNTAX INTEGER { forward (0), } MIN-ACCESS read-only DESCRIPTION "Only forward (0) is required." > > 5) gmplsTunnelTable > > > > DESCRIPTION > > > > "The row status of an entry in this table is controlled by > > mplsTunnelRowStatus in the corresponding entry in > > mplsTunnelTable. That is, it is not permitted to create a row in > > this table, nor to modify an existing row, when the > > corresponding mplsTunnelRowStatus has value active(1).... > > > > The sentence beginning with "That is," is awkward. Could you say > > something like: A row in this table is created when a row is created > > in the mplsTunnelTable. Entries in this table cannot be modified > > when the corresponding mplsTunnelRowStatus has a value of active(1). > > The exception.... > > > > Please also update this other places in this MIB (e.g > gmplsTunnelHopTable). > > Nack > "A row in this table is created when a row is created in the > mplsTunnelTable" is false. > Will attempt to reword to make this clearer. > > > 6) gmplsTunnelEntry > > DESCRIPTION: > > "... > > An entry can be created by a network administrator or by an SNMP > > agent as instructed by a signaling protocol." > > > > Please change the above to: > > > > "An entry can be created by a network administrator via SNMP SET > commands, or > > by the network management entity as instructed by a signaling > > protocol." > > Nack > "network management entity" implies a remote entity such as an NMS. Yes, I should have said, "network management entity (e.g., snmp agent). > Will change to: > > "An entry can be created by a network administrator via SNMP SET > commands, or in response to signaling protocol events." > good. > > 7) gmplsTunnelUnnumIf > > > > What IF-MIB object are referring to in the DESCRIPTION? > > Could you state which object in the description? > > Ack > An entry in ifTable. > Could you specify the ifType(s)? > > 8) gmplsTunnelAttributes > > Could you specify what happens when the bit is set (i.e. 1) > > vs. 0? > > Ack > Don't want to restate the protocol I-D, so this text will simply > replace "This flag indicates that" with "This flag is set to indicate > that" > > > 9) gmplsTunnelLSPEncoding > > > > The DESCRIPTION states: > > ...A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling > is > > not in use. Some objects in this MIB module may be of use for > > MPLS signaling extensions that do not use GMPLS signaling. By > > setting this object to 'tunnelLspNotGmpls', an application may > > indicate that only those objects meaningful in MPLS should be > > examined.... > > > > I believe that such objects should be put in to an MPLS MIB module > > and not included in this GMPLS MIB module. This is also true with > > the gmplsTunnelErrorTable. > > Nack > We strongly disagree with any implication that MPLS and GMPLS should be > separated in this way. GMPLS protocol extensions are likely to be > moved into MPLS implementations piecemeal and there is no clear > separation that you imply. The G in GMPLS stands for "generalized". > > Can you please indicate whether this is a sticking point for you. > As was suggested in an email on draft-ietf-ccamp-gmpls-lsr-mib, could you put these objects in a separate object group? Also, please separate MPLS and MPLS-TE objects into separate object groups. > > > 12) gmplsTunnelUpNotRecip > > > > Need to use InetAddressType and InetAddress. IpAddress > > is not used in MIBs anymore. Please be sure to support > > both v4 and v6 IP address Types. If you can't support > > v6 for some reason, that should be stated clearly. > > Ack per exchange with David. > > > Please change the name of this object to: > > gmplsTunnelUpstreamRecipientForNotify > > Nack > We are trying to keep to the (mythical?) 32 character limit. > How about: > gmplsTunnelUpNotifyRecipient How about gmplsTunnelUpstreamNotifyRecipient As for the 32 char limit, we've already addressed that, so won't repeat that discussion. > > > 13) gmplsTunnelDownNotRecip > > Same comment as above wrt to IpAddress. > > Ack > > > Please change the name to gmplsTunnelDownstreamRecipientForNotify > > Nack as above > How about: > gmplsTunnelDownNotifyRecipient How about gmplsTunnelDownstreamNotifyRecipient >> > 18) gmplsTunnelHopExpLabel and gmplsTunnelHopExpLabelPtr > > > > Need to add the word "Forward" in here as in > > gmplsTunnelHopExpForwardLabel and gmplsTunnelHopExpForwardLabelPtr > > > > That way it will be consistent with the Reverse counterparts. > > Nack > Please see point 21 about name lengths. > We will insert "Fwd" > > > 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpReverseLabelPtr > > > > Please change Rvrs to Reverse. > > Nack > Please see point 21 about name lengths In other objects in this MIB module are named using the entire word Reverse ( e.g. GmplsTunnelReversePerfEntry ::= SEQUENCE { gmplsTunnelReversePerfPackets Counter32, gmplsTunnelReversePerfHCPackets Counter64, gmplsTunnelReversePerfErrors Counter32, gmplsTunnelReversePerfBytes Counter32, gmplsTunnelReversePerfHCBytes Counter64 }) So please either change these to all use Rvrs or instead of Rvrs use the entire word, Reverse. Similarly with the use of Fwd and Forward, if you decide to use Reverse, then please use the entire word, Forward. If you decide to use Rvrs, then please use Fwd. I prefer the words spelled out but just please be consistent. > > 21) gmplsTunnelARHopExpLable and gmplsTunnelARHopExpLabelPtr > > > > Need to add the word "Forward" in here as in > > gmplsTunnelARHopExpForwardLabel and gmplsTunnelARHopExpForwardLabelPtr > > Nack > Would excede 32 characters. > Will use "Fwd" See discussion above wrt Rvrs and Reverse. > > > 22) gmplsTunnelARHopExpRvrsLabel and gmplsTunnelARHopExpRvrsLabelPtr > > > > Please change Rvrs to Reverse > > Nack > See point 21 > > > 23) gmplsTunnelARHopProtection OBJECT-TYPE > > > > Please add what the BIT set (i.e. 1) vs. 0 means in the > > DESCRIPTION. > > Ack > Limited change as before. > > > 24) gmplsTunnelCHopLabelTable objects > > > > Similar comments regarding the objects in this table > > to those above with regard to naming > > conventions (Forward and Reverse) and DESCRIPTIONs. Will not repeat the > > details, please refer to above comments on the > > prior 2 tables. > > Nack > Same answers as before. > Will use "Fwd" > > > 25) gmplsTunnelReversePerfTable > > Please add to the DESCRIPTION how a user knows if > > this is a bidirectional tunnel (i.e. what object > > or objects in the gmplsTunnelTable need to have > > what values?). > > Ack > > > 26) gmplsTunnelReversePerfPackets > > > > Does this object represent the 32-bit > > value of the least significant part of the > > 64-bit value (which is contained in gmplsTunnelReversePerfHCPackets)? > > Ack > > > 27) gmplsTunnelReversePerfBytes > > > > Does this object represent the 32-bit > > value of the least significant part of the > > 64-bit value (which is contained in gmplsTunnelReversePerfHCBytes)? > > Ack > > > 28) gmplsTunnelErrorTable OBJECT-TYPE > > > > Since this table applies to MPLS, it should be > > put in a separate MIB module which is MPLS specific. The > > prefix of gmpls could be confusing. > > Nack > This is applicable across MPLS and GMPLS. > Error TLVs are not present in MPLS RSVP-TE at this time. They may be added > later. > Discussed previously about separate OBJECT groups. > > 31) Compliance > > > > Please move some of the following comment in the > > DESCRIPTION of gmplsTeModuleFullCompliance > > > > -- The mandatory group has to be implemented by all LSRs that > > -- originate, terminate or act as transit for TE-LSPs/tunnels. > > -- In addition, depending on the type of tunnels supported, other > > -- groups become mandatory as explained below. > > Ack > > > 32) gmplsTunnelUnnumIf does not appear in the ReadOnly compliance > > and it probably should. > > Ack > > > Section 11.2.1. IANA-GMPLS-MIB Definition > > ----------------------------------------- > > > 38) I believe that the TC > > > > IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION > > > > should be put in the GMPLS-TC-STD-MIB or should just > > remain in the GMPLS-TE-STD-MIB. The reason is that this > > is not an assigned numbers list maintained by IANA, so > > should not be in the IANA GMPLS MIB. If I am incorrect > > about this please let me know, but I didn't see an IANA > > maintained Administrative Status Information enum. > > Nack > There are no fewer than three requests in CCAMP I-Ds that have passed WG > last call > for this space to be managed by IANA. Is this going to be managed by IANA soon? (just curious) > > > Additionally, this should be renamed to > > GmplsAdminStatusInformation which more closely matches rfc3471. > > Ack > > > 39) Several comments on the SYNTAX clause: > > > > 40a) smicngPRO gives the error > > > > E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS > > must be in contiguous positions > > > > SYNTAX BITS { > > delInProgress (0), > > adminDown (1), > > testing (2), > > reflect (31) > > } > > > > > > RFC2578 specifies that BITS should be contiguous > > (although there are exceptions to this, but this > > object does not seem to be an exception). > > Nack > > To quote the DESCRIPTION... > The relationship between the assignment of > gmplsTunnelAdminStatusFlags values and of the bit flags > in the Admin Status object or TLV within the GMPLS > signaling protocols is solely the purview of IANA and is > subject to change without notice." > However, it seems to us that making the bits match the flags in the > Admin Status object is a Good Idea (TM). > Here is the TLV that the object represents: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved |T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reflect (R): 1 bit Reserved: 28 bits Testing (T): 1 bit Administratively down (A): 1 bit Deletion in progress (D): 1 bit The BITS as specified look backwards when viewing the TLV. Are the BITS correctly specified? I consulted with other MIB Doctors and the following was suggested: SYNTAX BITS { delInProgress (0), adminDown (1), testing (2), reserved3(3), -- 0 on send, ignored on receive reserved4(4), -- 0 on send, ignored on receive .. reserved30(30), -- 0 on send, ignored on receive reflect (31) } Would this be acceptable? > > Could delInProgress, be renamed to deleteInProgress ? > > Could adminDown be renamed to administrativelyDown? > > These names more closely match 3471. > > Ack > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 30 Sep 2005 01:07:53 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=JU447C/I0OPG7Bof+5VVi3u1vNObfUthlxGvpuT51k9t90/BrXOrqoRfgQCunvLt; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <025b01c5c55b$64b05260$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , "Thomas D. Nadeau" , Cc: "Wijnen, Bert (Bert)" , Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Thu, 29 Sep 2005 21:07:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Adrian, Thank you for your quick response. Few comments inline. thanks, Joan ----- Original Message ----- From: Adrian Farrel To: ; Thomas D. Nadeau ; Cc: Wijnen, Bert (Bert) ; Sent: Wednesday, September 28, 2005 9:16 AM Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt > Again, thanks Joan. I think we are converging quickly. > > A few responses in the snipped email below. > > Cheers, > Adrian > > > > > >17) object: gmplsInterfaceSignalingCaps OBJECT-TYPE > > > > > > > > SYNTAX BITS { > > > > unknown (0), > > > > rsvpGmpls (1), > > > > crldpGmpls (2), -- note the use of CR-LDP is deprecated > > > > otherGmpls (3) > > > > } > > > > > > > > > > > >What is otherGmpls(3)?? > > > > > > Nack > > > > > > I'm embarrassed to say that there are other "GMPLS" signaling protocol > > > variants that have been developed outside the IETF. This was added in > > > response to a WG request. > > > > > > >Also, this description is confusing. How can unknown(0) and > > > >rsvpGmpls(1) be set simultaneously? > > > > > > Ack > > > Will add: > > > > > > ...but if unknown(0) is set, no other bit may be set. > > > > > > >Additionally, how can no bits be set? If this is a GMPLS interface, > > > >then doesn't one of these bits HAVE to be set? > > > > > > Ack > > > > > > As it says... > > > > > > Setting no bits implies > > > that GMPLS signaling cannot be performed on this interface and > > > all LSPs must be manually provisioned or that this table entry > > > is only present to supplement an entry in the > > > mplsInterfaceTable > > > by providing the information carried in other objects in this > > > row. > > > > > > This means that we should change gmplsInterfaceEntry to read: > > > > > > "A conceptual row in this table is created automatically by an > > > LSR for each interface that is both capable of supporting > > > GMPLS and that is configured to support GMPLS. Note that > > > support of GMPLS is not limited to control plane signaling, > > > but may include data-plane only function configured through > > > SNMP SET commands performed on this MIB module. > > > > > > A conceptual row in this table may also be created via SNMP > > > SET commands or automatically by the LSR to supplement a > > > conceptual row in the mplsInterfaceTable where the interface > > > is not capable of GMPLS but where the other objects carried > > > in this row provide useful additional information for an > > > MPLS interface." > > > > If I could ask you to put your chair hat on for a minute, what are the > > co-authors doing to get feedback from the MPLS working group on > > objects which may apply to MPLS? > > > > Additionally, is this draft going to have a last call in the MPLS > > working group? (maybe this is a question for the ADs). > > We can certainly poll the MPLS WG to see: > a. if there are other attributes that need to be controlled and could be > added to these modules > b. if there are any further review comments > > Since the work form MPLS-TE is split between the MPLS and CCAMP working > groups, it is usually assumed that anyone with an interest in MPLS-TE is > following both working groups. Further, since GMPLS is a superset of > MPLS-TE we can assume that anything that is needed for MPLS-TE is needed > for GMPLS. > > But I will send mail, not as a formal last call, but to see if we can > catch any more isues at this time. Thank you. I meant to suggest also sending email to the MPLS working group when these set of documents go to last call in the CCAMP working group. Sorry if that was not clear. > > > Also, it seems this object would be more appropriate in the > > GMPLS-TE-STD-MIB. Is there a reason for choosing the > > GMPLS-LSR-STD-MIB for this object? > > The main reason is that this object desribes the capabilities of an LSR's > interface. Included in this is the possilibity that the LSR does not > support any signaling protocols on the interface but still supports LSPs > (a la PVC). This makes this an LSR-related thing. Lastly, this object is > part of the gmplsInterfaceTable which is an extension of the > mplsInterfaceTable that appears in RFC3813, the MPLS-LSR-STD-MIB. > okay. > > > >18) gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE > > > > "Period, in milliseconds, between sending RSVP Hello messages > > > > on > > > > this interface. A value of 0 indicates that no Hello messages > > > > should be sent on this interface." > > > > > > > >This object is only valid if the gmplsInterfaceSignalingCaps > > > >object is set to rsvpGmpls. Please update the description > > > >to reflect that. > > > > > > Nack > > > It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB). > > > > Why is this object in this MIB as opposed to the GMPLS-TE-STD-MIB? > > > > I thought that GMPLS-TE-STD-MIB augmented the MPLS-TE-STD-MIB, > > is that not the case? > > Exactly the point. > RFC3812 does not contain per-interface objects. These are in RFC3813 in > the MPLS-LSR-STD-MIB. > > You are correct that this object is protocol dependent and would not be > used unless a TE protocol was in use (specifically RSVP-TE) unlike the > previous object. Thus, we could introduce a per-interface table within the > GMPLS-TE-STD-MIB to contain only this object, or we could leave it where > it is with all of the other per-interface objects. Had there been more > similar objects, I think we might have opted for this approach, but for > one object it did not seem worth it. > > Do you feel strongly? > Okay to leave where it is. Regarding MPLS objects in this and the GMPLS-TE-STD-MIB, I have consulted other MIB Doctors and one suggestion was made which I would like to relay, that is: to create a separate object group for these MPLS or MPLS TE objects in the Conformance Statements. An object group for the above object would contain only the one object, and the description would specify that this object applies to using MPLS with RSVP-TE. The benefits of doing this would be that someone reading the MIB module would quickly be able to isolate MPLS objects. As you pointed out, implementations will probably migrate certain groups (objects) before other groups, so this would probably help in making the decision of what object groups to implement first, second, etc. > > > >23) gmplsOutSegmentEntry OBJECT-TYPE > > > >Same comments as with gmplsInSegmentEntry > > > > > > Nack > > > Same answer > > > > Think you mean ack here? > > Oops, yes. > > > > >Section 8. GMPLS-LABEL-STD-MIB > > > >=================================== > > > > > >31) gmplsLabelTable OBJECT-TYPE > > > > > > > >The last part of the last paragraph is awkward: > > > > > > > > "... Labels in the tables in other MIBs are referred to using > > > > row pointer into this table. The indexing of this table > > > > provides > > > > for arbitrary indexing and also for concatenation of labels." > > > > > > > >Are you saying that other MIBs can use a row pointer to point to > > > >this table? Why would they do that if they could just use the > > > >indices directly? Also, I don't follow the comment about > > > >concatenation of labels. Could you explain this? > > > > > > Nack > > > Yes we are saying that other MIB modules can use a row pointer to > > > point to this table. > > > Yes they could use indices. This was the subject of a very lengthy > > > discussion between the co-authors, etc., but in the end we > > > observed that mplsInSegmentLabelPtr and mplsOutSegmentLabelPtr > > > (RFC3813) are rowPointers so we had better support being pointed to. > > > > > > We could soften the language here by replacing "are" with "may". > > > > Yes, please. > > > > > Note, we should change this to say "MIB modules" > > > > > > > good. > > > > > For an example of label concatenation see RFC3945 section 7.1. In > > > essence, a GMPLS label may be composite in order to identify a set > > > of resources in the data plane. Practial examples are timeslots > > > and wavelength sets (which are not contiguous like wavebands). > > > > > > The indexing mechanism allows multiple entries in this table to be > > > seen as a sequence of labels that should be concatenated. Ordering > > > is potentially very sensitive for concatenation. > > > > > > > It would be nice if you could add the above 2 paragraphs to the > > DESCRIPTION. > > OK, will do. Thank you. > > > > >32) gmplsLabelEntry OBJECT-TYPE > > > > > > > >The last sentence of the DESCRIPTION, please remove > > > >the word "more" from the phrase "is more persistent." > > > > > > >I still don't understand how the subindex provides a way > > > >to concatenate the labels. Could you give an example? > > > > > > Nack > > > If you are asking for an example in the I-D, I don't think it is > > > necessary. > > > > > > For your information, the composite label {{A}, {B}, {C}} might be > > > constructed as... > > > > > > gmplsLabelInterface = 1 > > > gmplsLabelIndex = 1 > > > gmplsLabelSubindex = 1 > > > gmplsLabelFreeform = A > > > > > > gmplsLabelInterface = 1 > > > gmplsLabelIndex = 1 > > > gmplsLabelSubindex = 2 > > > gmplsLabelFreeform = B > > > > > > gmplsLabelInterface = 1 > > > gmplsLabelIndex = 1 > > > gmplsLabelSubindex = 3 > > > gmplsLabelFreeform = C > > > > This is a good example and would, I think, be helpful someplace in the > > document. This is only a suggestion however, and not a blocking issue. > > OK. We'll look at how to include an example in the pre-amble text (not the > Description clasue). > Thank you. > > > >34) gmplsLabelInterface OBJECT-TYPE > > > > > > > >DESCRIPTION also needs to specify that zero may be > > > >used to indicate that the InterfaceIndex is not known > > > >or that an InterfaceIndex exists but it is not important > > > >wrt this implementation so zero is used. > > > > > > Nack > > > The use of zero is very precisely specified at the moment. > > > The reasons for setting zero that you cite are: > > > - the InterfaceIndex is not known > > > You cannot have a per-interface label space without knowing the > > > interface to which it applies. > > > - InterfaceIndex exists but it is not important wrt this > > > implementation > > > That is exactly the case of the global label space, and is already > > > stated. > > > > I think you need to list all the reasons under which zero could be a > > valid value for this index. You have listed more above which are not > > specified in the description. > > Erm, but of the two reasons given above I have refuted one, and the other > is specified in the descritpion. Opps, sorry. I misread your response. I'm fine with the original description. > I can't think of a meaningful way to change the existing text. > DESCRIPTION > "The interface on which this label is used. If the label has or > could have applicability across the whole system, this object > SHOULD be set to zero." > Perhaps we can re-order the words... > DESCRIPTION > "The interface on which this label is used. If this object is set > to zero, the label has or could have applicability across the > whole system and is not limited to a single interface." > > Does that help? > > > > > 35) gmplsLabelIndex OBJECT-TYPE > > > > SYNTAX Unsigned32 (0..4294967295) > > > > > >36b)Please change the "may" to "should" in this statement: > > > > A management application may read the gmplsLabelIndexNext > > > > object to find a suitable value for this object." > > > > > > Nack > > > Why "should" it do this? This is a convenience offered to it. It may > > > use any mechanism it chooses including the one suggested in the > > > quoted paragraph above. > > > > Without getting into a debate about tables and indexing, the > > should is extremely appropriate. Think of the case where you have a > > large number of rows in this table, do you expect a user to try a > > bunch of numbers to create a row even if he/she has access to a CLI, > > it will certainly be annoying to have to page through this table > > and get to an available number. > > > > If a user consults the gmplsLabelIndexNext object then creating an > > entry should be easier than not getting the gmplsLabelIndexNext > > object. > > And if the implementation is using correlation of gmplsLabelIndex > with the actual label ("Note that implementations that are > representing 32 bit labels within this table MAY choose to align > this index with the value of the label, but should be aware of the > implications of sparsely populated tables.") then the use of > gmplsLabelIndexNext would be completely inapproproriate because the > correct value (dependent on the label actually assigned in hardware) > comes from a different source. > > The use of "should" would curtail (a.k.a. break :-) this function. Okay, I understand this now, you are suggesting 2 different ways to assign a value for this index. I would expect that an operator would use one or the other for the table (not both), right? If so please modify the DESCRIPTION clause to make that clear, i.e. "The following paragraphs describe 2 methods to assign a value to this index, only one of these methods should be used." Please also add what the value of zero could represent for each method of assigning indexes, i.e. if using the value of the label as an index, than the value of zero, represents .....,... If using the gmplsLabelIndexNext there should be no value of zero (correct?) because gmplsLabelIndexNext returns zero to indicate that the table cannot create a row at this time. The use of "may" is fine. > > > > >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > > > > > > > >Please change the name to: gmplsLabelModuleReadOnlyCompliance > > > >to be consistent with the other MPLS and GMPLS MIB modules. > > > > > > Nack > > > I thought we tried to keep names down to 32 characters. I recall this > > > conversation before. Not mandatory, but desirable. > > > > > > A choice between two desires? > > > > > > > Please refer to Bert's comments on this. > > Agreed. > > > > >41) The ReadOnly compliance for gmplsLabelRowStatus > > > >does NOT have a MIN-ACCESS of read-only. Is this > > > >intentional? > > > > > > ??? > > > Not sure about this. > > > I thought the present of a WRITE-SYNTAX made some difference. > > > > Please refer to Bert's comments on this. > > Tom says he understands this, and will fix it. > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Sep 2005 20:25:42 +0000 Message-ID: <433C4D1A.8090008@grotto-networking.com> Date: Thu, 29 Sep 2005 13:22:50 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: Alok CC: ccamp@ops.ietf.org Subject: Re: questions Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Alok, by "Muxing" below I'm assuming that you're refering to TDM (circuit) multiplexing rather that packet multiplexing or wavelength division multiplexing (WDM)? If so check out the SONET/SDH overview in http://www.ietf.org/internet-drafts/draft-ietf-ccamp-sdhsonet-control-05.txt Greg B. Alok wrote: >I may speak on behalf of a lot of friends/youngsters who do have questions >related to the bases of how Muxing works.. >and trying to understand the various VCs and containers and the reason they >exist. > >Is it ok for new comers, who really dont understand transmissions and all >those VT pointers to ask questions on the list.... > > > >-thanks >Alok > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Sep 2005 18:02:22 +0000 Message-ID: <433C2BD1.4010104@marconi.com> Date: Thu, 29 Sep 2005 14:00:49 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: IETF MPLS List , IETF CCAMP List Subject: Re: Graceful restart - inter-protocol dependencies Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit When processing a loose hop, or even a strict hop with an address that is not an interface-neighbor address, RSVP relies on the route table to determine the next-hop interface (and possibly also the next-hop address.) How is it right to ignore route changes after this? If the route table changes such that the selected next-hop interface is no longer the best (or is no longer valid), should RSVP ignore this? It seems to me like this could end up blackholing traffic in a way that will not be detectable without OAM. The last I heard, network operators were not required to run OAM on every LSP. Has this changed? -- David Alia Atlas wrote: > David, > > In ref to RSVP-TE, a part of the question is who notices the routing > change and does > the reroute. In general, the idea of make-before-break and control by > the ingress apply. > > For a midpoint, a change to an LSP would be triggered by either the RSVP > PATH > message changing or by the selected next-hop interface no longer being > available. > Theoretically, a midpoint LSR could register for route changes to the > specified next-hop, > but to what purpose?? Once the midpoint LSR has determined the next-hop > interface, I'd > expect that to be treated as a strict hop, inside the LSR at least. > > Alia > > > On 9/29/05, *David Charlap* > wrote: > > But RSVP doesn't work this way. It is a soft-state protocol. > > If the route table changes such that the next-hop interface changes, > RSVP is supposed to reroute the connection accordingly. > > This probably won't happen if the next-hop is a strict-hop in an ERO, > but it can easily happen if the next-hop is loose or if the LSP is > signaled without an ERO (meaning routing is consulted to determine the > next-hop to the egress node.) > > If there is a paragraph in an RFC that says RSVP-TE should ignore all > route-table changes once an LSP comes up, I missed it. > > -- David > > Jing Ruiquan wrote: > > I think only the originating node should do the rerouting with > RSVP-TE .At > > the same time, all the nodes will converge their IGP routing data > base. > > > > Rick > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org ] > On Behalf > > Of David Charlap > > Sent: Thursday, September 29, 2005 2:37 AM > > To: IETF MPLS List; IETF CCAMP List > > Subject: Graceful restart - inter-protocol dependencies > > > > Is there any point to implementing RSVP-TE's graceful restart > without also > > implementing graceful restart for routing protocols? > > > > On the one hand, RSVP doesn't require routing to recover > LSPs. It knows the > > next-hop interface, because of the preserved data-plane connection. > > Whatever other information it may need, the switch can either > preserve > > this information or recover it from a neighbor using the > RecoveryPath object > > (draft-ietf-ccamp-rsvo-restart-ext-03). > > > > On the other hand, nodes more than one hop upstream of the > failure will > > detect the loss of routing-connectivity to the failed node if IGP > graceful > > restart is not also implemented. They may reroute the LSP away > from the > > failed node, or tear it down altogether, even though the data > plane is still > > active and RSVP graceful restart is recovering the control-plane > state. > > > > An originating node may consider the destination unreachable, as > a result of > > losing the routes even though the data-plane for the LSP is still > up (which > > can be confirmed via OAM.) > > > > A transit node, when processing an loose ERO-hop, may choose to > reroute or > > fail the LSP if its local topology information says that the > failed (and > > restarting) node is not available. It might even choose to do > this for an > > established LSP, as a result of Path refresh processing. > > > > My questions are: > > > > 1: Does this mean it's pointless to use RSVP graceful restart > without > > also using IGP graceful restart (for whatever IGP is active). > > > > 2: Is IGP graceful restart sufficient to prevent this problem? For > > instance, OSPF's restart procedure requires all preserved > state to > > be thrown away if a topology change is detected. > > > > 3: An originating node can use OAM to validate the data plane of an > > LSP, and choose to ignore what routing tells it about the > > destination's reachability. But what about transit > nodes? As far > > as I know, MPLS doesn't support segment-OAM, and it would be > > prohibitive for every transit node to run its own OAM streams > > to detect self-to-end connectivity. > > > > 4: Are there other solutions to this problem? > > > > One possible solution might be route-pinning, but RSVP doesn't have a > > built-in mechanism for this. The usual workaround (signal the LSP, > > requesting route-recording, then turn the RRO into an ERO for > subsequent > > refreshes) can work, but are there situations where even this > would be > > insufficient to prevent a transit node from rerouting/tearing the > connection > > in this particular situation (where RSVP is doing a graceful > restart but the > > IGP is not)? > > > > -- David > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Sep 2005 16:04:25 +0000 Message-ID: <00d101c5c50f$23320870$300218ac@rs.riverstonenet.com> From: "Alok" To: Subject: questions Date: Thu, 29 Sep 2005 21:32:01 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I may speak on behalf of a lot of friends/youngsters who do have questions related to the bases of how Muxing works.. and trying to understand the various VCs and containers and the reason they exist. Is it ok for new comers, who really dont understand transmissions and all those VT pointers to ask questions on the list.... -thanks Alok Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Sep 2005 15:38:13 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Graceful restart - inter-protocol dependencies Date: Thu, 29 Sep 2005 16:37:04 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A35389118004E7@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Graceful restart - inter-protocol dependencies Thread-Index: AcXFA/+QPkt5glu/Qzm6K/i6F7bBbgAAQZew From: To: , , Thanks David....it's not simply how they *should* work its how they *must* work if one wants to be able to offer network services to customers that have deterministic behaviour, ie one has precise (and it also should be simple) control over traffic/fault/performance management facets. A full service operator like BT needs all 3 networking modes working in concert...and they are for sure different. Understanding *why* they are different at fundamental level has taken us a while to properly figure out. However, the stuff we knew was intuitively right is now getting placed on a far stronger foundation of underlying 'truths' because of the unified modelling work I mentioned (this goes right back to Shannon and Turing stuff...indeed a network is precisely the union of Information Theory and a computing machine). The GMPLS co-cs stuff is largely self-protecting of abuse.....this is down to the nature of the constraints that define this mode (esp the labelling). Same can be said for the cl-ps mode. The major risks arise with the co-ps mode....and one can make life very complex here if one is not careful.....I'll resist the strong temptation to flesh this out wrt comments on MPLS and the PW stuff.=20 However, we do need a correctly specified co-ps mode networking capability because as we sun-set many of our legacy co-cs and co-ps technologies there is a major gap opening for a lower granularity (than SDH VC4) network builder capability....and we have many customers who demand such a network service. regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of David Charlap > Sent: 29 September 2005 15:40 > To: mpls@lists.ietf.org; ccamp@ops.ietf.org > Subject: Re: Graceful restart - inter-protocol dependencies >=20 >=20 > You're absolutely right that this is how co networks should=20 > operate. I=20 > would agree that there is little point to rerouting an LSP that has=20 > data-plane connectivity, even if routing says the path is invalid or=20 > suboptimal. >=20 > Unfortunately, I don't think current MPLS signaling protocols=20 > (RSVP-TE=20 > and LDP) work this way. LDP is explicitly designed to dynamically=20 > change as routing changes. >=20 > RSVP-TE seems (to my best understanding) to also react to routing=20 > changes, except for special cases (like when signaled with an ERO=20 > consisting entirely of strict nodes whose addresses can be=20 > resolved from=20 > interface-neighbor information instead of from routing.) >=20 > -- David >=20 >=20 > neil.2.harrison@bt.com wrote: > > David, > >=20 > > This is a very interesting/thoughtful mail. When I read it I was=20 > > immediately struck by recent discussions some of us have=20 > been having=20 > > on the topic of unified functional modelling within SG15, ie the=20 > > underlying axiomatic truths that stem directly from=20 > Shannon/Turing wrt=20 > > networking and that show how the co-cs, co-ps and cl-ps networking=20 > > modes all have a common root. However, whilst I don't want to get=20 > > into that here I do want to illustrate a key consequence of=20 > this work=20 > > that is particularly relevant to your observations. > >=20 > > In the co modes we have this rather important object called=20 > a trail. =20 > > A trail is, in essence, a concatenated sequence of link-connections=20 > > and nodes (which are the smallest subnetwork connections). =20 > However,=20 > > the key observation is that at the epoch we create the=20 > trail we remove=20 > > all further routing choices from the trail. You can almost=20 > think of=20 > > this as effectively removing the trail from its parent network=20 > > topology (there is a resource accounting issue to deal=20 > with, but that=20 > > is a different point).....and I guess in IETF speak one would call=20 > > this 'route-pinning'. > >=20 > > What this means is that it does not matter what happens to=20 > the routing=20 > > process after this epoch, once the trail is established there is no=20 > > need to move it. And a key example of why this is important is the=20 > > case of augmenting the network topology by adding further=20 > nodes/links. =20 > > Because the network topology has now changed then future routing=20 > > decisions are very likely to alter. But in the co mode=20 > case this does=20 > > not matter....once a trail is created it remains faithful to its=20 > > original routing choice unless we consciously decide to=20 > move it (which=20 > > may of course be the result of failures or planned works). > >=20 > > Now contrast this with the cl mode case. If we augment a cl=20 > network by=20 > > adding new nodes/links then the routing process will update and=20 > > traffic will move in accordance with whatever is the optimal path. > >=20 > > Note a trail has other key properties, eg it allows one to=20 > completely=20 > > decouple a survivability semantic from the QoS semantics of client=20 > > traffic units. This property is rather important when one=20 > offering a=20 > > network builder service to customers. > >=20 > > regards, Neil > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: owner-ccamp@ops.ietf.org > >>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of David Charlap > >>Sent: 28 September 2005 19:37 > >>To: IETF MPLS List; IETF CCAMP List > >>Subject: Graceful restart - inter-protocol dependencies > >> > >> > >>Is there any point to implementing RSVP-TE's graceful=20 > restart without > >>also implementing graceful restart for routing protocols? > >> > >>On the one hand, RSVP doesn't require routing to recover > >>LSPs. It knows=20 > >>the next-hop interface, because of the preserved data-plane=20 > >>connection.=20 > >> Whatever other information it may need, the switch can=20 > >>either preserve=20 > >>this information or recover it from a neighbor using the=20 > RecoveryPath=20 > >>object (draft-ietf-ccamp-rsvo-restart-ext-03). > >> > >>On the other hand, nodes more than one hop upstream of the > >>failure will=20 > >>detect the loss of routing-connectivity to the failed node if IGP=20 > >>graceful restart is not also implemented. They may reroute=20 > >>the LSP away=20 > >>from the failed node, or tear it down altogether, even though=20 > >>the data=20 > >>plane is still active and RSVP graceful restart is recovering the=20 > >>control-plane state. > >> > >>An originating node may consider the destination unreachable, as a > >>result of losing the routes even though the data-plane for=20 > the LSP is=20 > >>still up (which can be confirmed via OAM.) > >> > >>A transit node, when processing an loose ERO-hop, may choose > >>to reroute=20 > >>or fail the LSP if its local topology information says that=20 > >>the failed=20 > >>(and restarting) node is not available. It might even choose=20 > >>to do this=20 > >>for an established LSP, as a result of Path refresh processing. > >> > >>My questions are: > >> > >>1: Does this mean it's pointless to use RSVP graceful=20 > restart without > >> also using IGP graceful restart (for whatever IGP is active). > >> > >>2: Is IGP graceful restart sufficient to prevent this problem? For > >> instance, OSPF's restart procedure requires all=20 > preserved state to > >> be thrown away if a topology change is detected. > >> > >>3: An originating node can use OAM to validate the data plane of an > >> LSP, and choose to ignore what routing tells it about the > >> destination's reachability. But what about transit=20 > nodes? As far > >> as I know, MPLS doesn't support segment-OAM, and it would be > >> prohibitive for every transit node to run its own OAM streams > >> to detect self-to-end connectivity. > >> > >>4: Are there other solutions to this problem? > >> > >>One possible solution might be route-pinning, but RSVP=20 > doesn't have a > >>built-in mechanism for this. The usual workaround (signal the LSP,=20 > >>requesting route-recording, then turn the RRO into an ERO for=20 > >>subsequent=20 > >>refreshes) can work, but are there situations where even this=20 > >>would be=20 > >>insufficient to prevent a transit node from rerouting/tearing the=20 > >>connection in this particular situation (where RSVP is doing=20 > >>a graceful=20 > >>restart but the IGP is not)? > >> > >>-- David > >> > >> >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Sep 2005 14:51:35 +0000 Date: Thu, 29 Sep 2005 10:50:35 -0400 From: Ashok Narayanan To: David Charlap Cc: "'IETF MPLS List'" , "'IETF CCAMP List'" Subject: Re: Graceful restart - inter-protocol dependencies Message-ID: <20050929145035.GP28771@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Strict EROs are used in the vast majority of MPLS/TE deployments. Even Loose ERO hops tend to get expanded into strict EROs (e.g at ASBRs); and extensions such as PCE are all designed to move path calculation to a single point rather than doing it hop-by-hop. The problem with hop-by-hop routing is that you can only have LSPs track the best IP route, rather than the best "engineered" route through the network. However, the problem you've described is an interesting one for regular IPv4 RSVP (for QoS), though not necessarily for MPLS/TE. -Ashok On Thu, Sep 29, 2005 at 10:34:39AM -0400, David Charlap wrote: > But RSVP doesn't work this way. It is a soft-state protocol. > > If the route table changes such that the next-hop interface changes, > RSVP is supposed to reroute the connection accordingly. > > This probably won't happen if the next-hop is a strict-hop in an ERO, > but it can easily happen if the next-hop is loose or if the LSP is > signaled without an ERO (meaning routing is consulted to determine the > next-hop to the egress node.) > > If there is a paragraph in an RFC that says RSVP-TE should ignore all > route-table changes once an LSP comes up, I missed it. > > -- David > > Jing Ruiquan wrote: > >I think only the originating node should do the rerouting with RSVP-TE .At > >the same time, all the nodes will converge their IGP routing data base. > > > >Rick > > > >-----Original Message----- > >From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > >Of David Charlap > >Sent: Thursday, September 29, 2005 2:37 AM > >To: IETF MPLS List; IETF CCAMP List > >Subject: Graceful restart - inter-protocol dependencies > > > >Is there any point to implementing RSVP-TE's graceful restart without also > >implementing graceful restart for routing protocols? > > > >On the one hand, RSVP doesn't require routing to recover LSPs. It knows > >the > >next-hop interface, because of the preserved data-plane connection. > > Whatever other information it may need, the switch can either preserve > >this information or recover it from a neighbor using the RecoveryPath > >object > >(draft-ietf-ccamp-rsvo-restart-ext-03). > > > >On the other hand, nodes more than one hop upstream of the failure will > >detect the loss of routing-connectivity to the failed node if IGP graceful > >restart is not also implemented. They may reroute the LSP away from the > >failed node, or tear it down altogether, even though the data plane is > >still > >active and RSVP graceful restart is recovering the control-plane state. > > > >An originating node may consider the destination unreachable, as a result > >of > >losing the routes even though the data-plane for the LSP is still up (which > >can be confirmed via OAM.) > > > >A transit node, when processing an loose ERO-hop, may choose to reroute or > >fail the LSP if its local topology information says that the failed (and > >restarting) node is not available. It might even choose to do this for an > >established LSP, as a result of Path refresh processing. > > > >My questions are: > > > >1: Does this mean it's pointless to use RSVP graceful restart without > > also using IGP graceful restart (for whatever IGP is active). > > > >2: Is IGP graceful restart sufficient to prevent this problem? For > > instance, OSPF's restart procedure requires all preserved state to > > be thrown away if a topology change is detected. > > > >3: An originating node can use OAM to validate the data plane of an > > LSP, and choose to ignore what routing tells it about the > > destination's reachability. But what about transit nodes? As far > > as I know, MPLS doesn't support segment-OAM, and it would be > > prohibitive for every transit node to run its own OAM streams > > to detect self-to-end connectivity. > > > >4: Are there other solutions to this problem? > > > >One possible solution might be route-pinning, but RSVP doesn't have a > >built-in mechanism for this. The usual workaround (signal the LSP, > >requesting route-recording, then turn the RRO into an ERO for subsequent > >refreshes) can work, but are there situations where even this would be > >insufficient to prevent a transit node from rerouting/tearing the > >connection > >in this particular situation (where RSVP is doing a graceful restart but > >the > >IGP is not)? > > > >-- David -- --- Asok the Intern ---------------------------------------- Ashok Narayanan IOS Network Protocols, Cisco Systems 1414 Mass Ave, Boxborough MA 01719 Ph: 978-936-1608. Fax: 978-936-2218 (Attn: Ashok Narayanan) Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Sep 2005 14:40:44 +0000 Message-ID: <433BFCBC.70002@marconi.com> Date: Thu, 29 Sep 2005 10:39:56 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: mpls@lists.ietf.org, ccamp@ops.ietf.org Subject: Re: Graceful restart - inter-protocol dependencies Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit You're absolutely right that this is how co networks should operate. I would agree that there is little point to rerouting an LSP that has data-plane connectivity, even if routing says the path is invalid or suboptimal. Unfortunately, I don't think current MPLS signaling protocols (RSVP-TE and LDP) work this way. LDP is explicitly designed to dynamically change as routing changes. RSVP-TE seems (to my best understanding) to also react to routing changes, except for special cases (like when signaled with an ERO consisting entirely of strict nodes whose addresses can be resolved from interface-neighbor information instead of from routing.) -- David neil.2.harrison@bt.com wrote: > David, > > This is a very interesting/thoughtful mail. When I read it I was > immediately struck by recent discussions some of us have been having on > the topic of unified functional modelling within SG15, ie the underlying > axiomatic truths that stem directly from Shannon/Turing wrt networking > and that show how the co-cs, co-ps and cl-ps networking modes all have a > common root. However, whilst I don't want to get into that here I do > want to illustrate a key consequence of this work that is particularly > relevant to your observations. > > In the co modes we have this rather important object called a trail. A > trail is, in essence, a concatenated sequence of link-connections and > nodes (which are the smallest subnetwork connections). However, the key > observation is that at the epoch we create the trail we remove all > further routing choices from the trail. You can almost think of this as > effectively removing the trail from its parent network topology (there > is a resource accounting issue to deal with, but that is a different > point).....and I guess in IETF speak one would call this > 'route-pinning'. > > What this means is that it does not matter what happens to the routing > process after this epoch, once the trail is established there is no need > to move it. And a key example of why this is important is the case of > augmenting the network topology by adding further nodes/links. Because > the network topology has now changed then future routing decisions are > very likely to alter. But in the co mode case this does not > matter....once a trail is created it remains faithful to its original > routing choice unless we consciously decide to move it (which may of > course be the result of failures or planned works). > > Now contrast this with the cl mode case. If we augment a cl network by > adding new nodes/links then the routing process will update and traffic > will move in accordance with whatever is the optimal path. > > Note a trail has other key properties, eg it allows one to completely > decouple a survivability semantic from the QoS semantics of client > traffic units. This property is rather important when one offering a > network builder service to customers. > > regards, Neil > > > > >>-----Original Message----- >>From: owner-ccamp@ops.ietf.org >>[mailto:owner-ccamp@ops.ietf.org] On Behalf Of David Charlap >>Sent: 28 September 2005 19:37 >>To: IETF MPLS List; IETF CCAMP List >>Subject: Graceful restart - inter-protocol dependencies >> >> >>Is there any point to implementing RSVP-TE's graceful restart without >>also implementing graceful restart for routing protocols? >> >>On the one hand, RSVP doesn't require routing to recover >>LSPs. It knows >>the next-hop interface, because of the preserved data-plane >>connection. >> Whatever other information it may need, the switch can >>either preserve >>this information or recover it from a neighbor using the RecoveryPath >>object (draft-ietf-ccamp-rsvo-restart-ext-03). >> >>On the other hand, nodes more than one hop upstream of the >>failure will >>detect the loss of routing-connectivity to the failed node if IGP >>graceful restart is not also implemented. They may reroute >>the LSP away >>from the failed node, or tear it down altogether, even though >>the data >>plane is still active and RSVP graceful restart is recovering the >>control-plane state. >> >>An originating node may consider the destination unreachable, as a >>result of losing the routes even though the data-plane for the LSP is >>still up (which can be confirmed via OAM.) >> >>A transit node, when processing an loose ERO-hop, may choose >>to reroute >>or fail the LSP if its local topology information says that >>the failed >>(and restarting) node is not available. It might even choose >>to do this >>for an established LSP, as a result of Path refresh processing. >> >>My questions are: >> >>1: Does this mean it's pointless to use RSVP graceful restart without >> also using IGP graceful restart (for whatever IGP is active). >> >>2: Is IGP graceful restart sufficient to prevent this problem? For >> instance, OSPF's restart procedure requires all preserved state to >> be thrown away if a topology change is detected. >> >>3: An originating node can use OAM to validate the data plane of an >> LSP, and choose to ignore what routing tells it about the >> destination's reachability. But what about transit nodes? As far >> as I know, MPLS doesn't support segment-OAM, and it would be >> prohibitive for every transit node to run its own OAM streams >> to detect self-to-end connectivity. >> >>4: Are there other solutions to this problem? >> >>One possible solution might be route-pinning, but RSVP doesn't have a >>built-in mechanism for this. The usual workaround (signal the LSP, >>requesting route-recording, then turn the RRO into an ERO for >>subsequent >>refreshes) can work, but are there situations where even this >>would be >>insufficient to prevent a transit node from rerouting/tearing the >>connection in this particular situation (where RSVP is doing >>a graceful >>restart but the IGP is not)? >> >>-- David >> >> Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Sep 2005 14:38:13 +0000 Message-ID: <433BFB7F.7050107@marconi.com> Date: Thu, 29 Sep 2005 10:34:39 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: "'IETF MPLS List'" , "'IETF CCAMP List'" Subject: Re: Graceful restart - inter-protocol dependencies Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit But RSVP doesn't work this way. It is a soft-state protocol. If the route table changes such that the next-hop interface changes, RSVP is supposed to reroute the connection accordingly. This probably won't happen if the next-hop is a strict-hop in an ERO, but it can easily happen if the next-hop is loose or if the LSP is signaled without an ERO (meaning routing is consulted to determine the next-hop to the egress node.) If there is a paragraph in an RFC that says RSVP-TE should ignore all route-table changes once an LSP comes up, I missed it. -- David Jing Ruiquan wrote: > I think only the originating node should do the rerouting with RSVP-TE .At > the same time, all the nodes will converge their IGP routing data base. > > Rick > > -----Original Message----- > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf > Of David Charlap > Sent: Thursday, September 29, 2005 2:37 AM > To: IETF MPLS List; IETF CCAMP List > Subject: Graceful restart - inter-protocol dependencies > > Is there any point to implementing RSVP-TE's graceful restart without also > implementing graceful restart for routing protocols? > > On the one hand, RSVP doesn't require routing to recover LSPs. It knows the > next-hop interface, because of the preserved data-plane connection. > Whatever other information it may need, the switch can either preserve > this information or recover it from a neighbor using the RecoveryPath object > (draft-ietf-ccamp-rsvo-restart-ext-03). > > On the other hand, nodes more than one hop upstream of the failure will > detect the loss of routing-connectivity to the failed node if IGP graceful > restart is not also implemented. They may reroute the LSP away from the > failed node, or tear it down altogether, even though the data plane is still > active and RSVP graceful restart is recovering the control-plane state. > > An originating node may consider the destination unreachable, as a result of > losing the routes even though the data-plane for the LSP is still up (which > can be confirmed via OAM.) > > A transit node, when processing an loose ERO-hop, may choose to reroute or > fail the LSP if its local topology information says that the failed (and > restarting) node is not available. It might even choose to do this for an > established LSP, as a result of Path refresh processing. > > My questions are: > > 1: Does this mean it's pointless to use RSVP graceful restart without > also using IGP graceful restart (for whatever IGP is active). > > 2: Is IGP graceful restart sufficient to prevent this problem? For > instance, OSPF's restart procedure requires all preserved state to > be thrown away if a topology change is detected. > > 3: An originating node can use OAM to validate the data plane of an > LSP, and choose to ignore what routing tells it about the > destination's reachability. But what about transit nodes? As far > as I know, MPLS doesn't support segment-OAM, and it would be > prohibitive for every transit node to run its own OAM streams > to detect self-to-end connectivity. > > 4: Are there other solutions to this problem? > > One possible solution might be route-pinning, but RSVP doesn't have a > built-in mechanism for this. The usual workaround (signal the LSP, > requesting route-recording, then turn the RRO into an ERO for subsequent > refreshes) can work, but are there situations where even this would be > insufficient to prevent a transit node from rerouting/tearing the connection > in this particular situation (where RSVP is doing a graceful restart but the > IGP is not)? > > -- David Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 29 Sep 2005 09:45:06 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Graceful restart - inter-protocol dependencies Date: Thu, 29 Sep 2005 10:43:26 +0100 Message-ID: <0536FC9B908BEC4597EE721BE6A3538911790669@i2km07-ukbr.domain1.systemhost.net> Thread-Topic: Graceful restart - inter-protocol dependencies Thread-Index: AcXEW+1F1lvn6K7+Sf+nx1sLCgITFgAeyW6A From: To: , , David, This is a very interesting/thoughtful mail. When I read it I was immediately struck by recent discussions some of us have been having on the topic of unified functional modelling within SG15, ie the underlying axiomatic truths that stem directly from Shannon/Turing wrt networking and that show how the co-cs, co-ps and cl-ps networking modes all have a common root. However, whilst I don't want to get into that here I do want to illustrate a key consequence of this work that is particularly relevant to your observations. In the co modes we have this rather important object called a trail. A trail is, in essence, a concatenated sequence of link-connections and nodes (which are the smallest subnetwork connections). However, the key observation is that at the epoch we create the trail we remove all further routing choices from the trail. You can almost think of this as effectively removing the trail from its parent network topology (there is a resource accounting issue to deal with, but that is a different point).....and I guess in IETF speak one would call this 'route-pinning'. What this means is that it does not matter what happens to the routing process after this epoch, once the trail is established there is no need to move it. And a key example of why this is important is the case of augmenting the network topology by adding further nodes/links. Because the network topology has now changed then future routing decisions are very likely to alter. But in the co mode case this does not matter....once a trail is created it remains faithful to its original routing choice unless we consciously decide to move it (which may of course be the result of failures or planned works). Now contrast this with the cl mode case. If we augment a cl network by adding new nodes/links then the routing process will update and traffic will move in accordance with whatever is the optimal path.=20 Note a trail has other key properties, eg it allows one to completely decouple a survivability semantic from the QoS semantics of client traffic units. This property is rather important when one offering a network builder service to customers. regards, Neil > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of David Charlap > Sent: 28 September 2005 19:37 > To: IETF MPLS List; IETF CCAMP List > Subject: Graceful restart - inter-protocol dependencies >=20 >=20 > Is there any point to implementing RSVP-TE's graceful restart without=20 > also implementing graceful restart for routing protocols? >=20 > On the one hand, RSVP doesn't require routing to recover=20 > LSPs. It knows=20 > the next-hop interface, because of the preserved data-plane=20 > connection.=20 > Whatever other information it may need, the switch can=20 > either preserve=20 > this information or recover it from a neighbor using the RecoveryPath=20 > object (draft-ietf-ccamp-rsvo-restart-ext-03). >=20 > On the other hand, nodes more than one hop upstream of the=20 > failure will=20 > detect the loss of routing-connectivity to the failed node if IGP=20 > graceful restart is not also implemented. They may reroute=20 > the LSP away=20 > from the failed node, or tear it down altogether, even though=20 > the data=20 > plane is still active and RSVP graceful restart is recovering the=20 > control-plane state. >=20 > An originating node may consider the destination unreachable, as a=20 > result of losing the routes even though the data-plane for the LSP is=20 > still up (which can be confirmed via OAM.) >=20 > A transit node, when processing an loose ERO-hop, may choose=20 > to reroute=20 > or fail the LSP if its local topology information says that=20 > the failed=20 > (and restarting) node is not available. It might even choose=20 > to do this=20 > for an established LSP, as a result of Path refresh processing. >=20 > My questions are: >=20 > 1: Does this mean it's pointless to use RSVP graceful restart without > also using IGP graceful restart (for whatever IGP is active). >=20 > 2: Is IGP graceful restart sufficient to prevent this problem? For > instance, OSPF's restart procedure requires all preserved state to > be thrown away if a topology change is detected. >=20 > 3: An originating node can use OAM to validate the data plane of an > LSP, and choose to ignore what routing tells it about the > destination's reachability. But what about transit nodes? As far > as I know, MPLS doesn't support segment-OAM, and it would be > prohibitive for every transit node to run its own OAM streams > to detect self-to-end connectivity. >=20 > 4: Are there other solutions to this problem? >=20 > One possible solution might be route-pinning, but RSVP doesn't have a=20 > built-in mechanism for this. The usual workaround (signal the LSP,=20 > requesting route-recording, then turn the RRO into an ERO for=20 > subsequent=20 > refreshes) can work, but are there situations where even this=20 > would be=20 > insufficient to prevent a transit node from rerouting/tearing the=20 > connection in this particular situation (where RSVP is doing=20 > a graceful=20 > restart but the IGP is not)? >=20 > -- David >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Sep 2005 20:31:16 +0000 Message-ID: <032001c5c46b$d5867230$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Copy of a liaison from ITU-T SG15 to OIF Date: Wed, 28 Sep 2005 21:24:29 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_031B_01C5C473.02837560" This is a multi-part message in MIME format. ------=_NextPart_000_031B_01C5C473.02837560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We have been copied on a liaison from ITU-T SG15 Q12 and Q14 to the OIF. The text is below. I will put a copy on the web at http://www.olddog.co.uk/ccamp.htm No action appears to be required from CCAMP at this stage. Thanks, Adrian =3D=3D=3D=3D=3D=3D=3D Source: ITU-T SG15 Q12, 14/15 Title: Response Liaison Statement to OIF on OIF Demo Finding To: Jim Jones, OIF Technical Committee Chair Cc: IETF CCAMP WG Co-chairs Approval:ITU-T SG15 Q14/15 Interim Meeting, Stuttgart (Germany), 18-22 = July 2005 For: Action Deadline:14 November 2005 Contact:Hing-Kam Lam (hklam@lucent.com) Contact:Malcolm Betts (betts01@nortel.com) =20 Thank you for sharing OIF UNI 2.0 work with SG15. For the Ethernet = feature, we note the alignment with the Ethernet series Recommendations = developed in SG15. We also appreciate the significant effort required = to accomplish the recent OIF Interoperability Demo, and some of the = issues that were identified in your liaison. As requested, please find our replies to the issues below. 1. Call identifier format sent by an originating UNI client. (Q14 only) Q14 agrees that the issue exists in G.7713.2 and accepts the OIF = recommendation to define that message for C-Type=3D0 in a future = G.7713.2 update. It should be noted that while G.7713.2 and RFC3474 = already specify the use C-type=3D0, a request to IANA for C-Type=3D0 was = accidentally neglected when processing RFC3474. This oversight needs to = be resolved. =20 2. Use of the NVC field for VCAT connections (Q14 only) There are two issues that have to be considered in this question. = First, in what order the VCAT vs server layer calls are created, and = second, if the server connections should be co-routed or not. When creating a VCAT call, the request could start from the client layer = which then results in the creation of server layer calls. In this case = when the server layer connections are created, it is known that they = will participate in a VCAT group (VCG). The opposite can also occur = where there are server layer connections are already in place and VCAT = call obtains them for the VCG. Here, no signalling in the server layer = is needed for the server layer calls. In the first case, setting the = NVC field could be done in the server layer calls as it is known that = they will be part of a VCAT call. In the second case, the original = signalling used did not know that the call would be part of a future = VCAT call and hence the NVC field remains zeroed. To accommodate the = case where existing connections are added to a VCG, it appears that the = NVC field is not relevant. In the SONET/SDH TSPEC where NVC is defined, the implied purpose is to = create LSP signalling state for single session that may have multiple = SONET/SDH connections that are in parallel. That is, when NVC is set to = >1, the expectation is that the connections are co-routed and they = follow the same link(s) and tandem switching points. To be able to use = more available bandwidth in the server layer, it is desirable to not = limit the connections in a VCG to be co-routed. In this scenario, each = connection is separately routed and a separate connection state is = needed per connection. To accommodate this degree of freedom, the NVC = field itself does not appear to be relevant to server layer signalling. Regarding H4 byte usage, note that it is the VCAT function that uses = this byte but only after the connection(s) is(are) created. So from a = signalling point of view, the server layer has no need to be aware that = the H4 byte is going to be used. Only the client layer (VCAT) needs to = be aware and trigger the use of the H4 byte. =20 3. TSPEC format to be used for Ethernet connections (Q12 and Q14) Q14 and Q12 think that a new Ethernet Traffic Parameters TSPEC in = RSVP-TE is the best long-term solution for specifying Ethernet bandwidth = service parameters and will request that CCAMP considers the = Q.8011/MEF.6 Ethernet service parameters and construct a suitable TSPEC = for it that can be used in the UNI. We also suggest that the OIF = similarly corresponds with CCAMP. =20 =20 An electronic copy of this liaison statement is available at: = ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICAT= IONS/index.html ------=_NextPart_000_031B_01C5C473.02837560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

We have been copied on a = liaison from=20 ITU-T SG15 Q12 and Q14 to the OIF.

The text is below.

I = will put a=20 copy on the web at http://www.olddog.co.uk/ccamp.htm

No action = appears to=20 be required from CCAMP at this=20 stage.

Thanks,
Adrian

=3D=3D=3D=3D=3D=3D=3D

Sourc= e:  ITU-T SG15=20 Q12, 14/15
Title:   Response Liaison Statement to OIF on = OIF Demo=20 Finding
To:      Jim Jones, OIF Technical = Committee=20 Chair
Cc:      IETF CCAMP WG=20 Co-chairs
Approval:ITU-T SG15 Q14/15 Interim Meeting, Stuttgart = (Germany),=20 18-22 July 2005
For:     Action
Deadline:14 = November=20 2005
Contact:Hing-Kam Lam (hklam@lucent.com)
Contact:Malcolm= =20 Betts (betts01@nortel.com)
 
T= hank you=20 for sharing OIF UNI 2.0 work with SG15.  For the Ethernet feature, = we note=20 the alignment with the Ethernet series Recommendations developed in = SG15. =20 We also appreciate the significant effort required to accomplish the = recent OIF=20 Interoperability Demo, and some of the issues that were identified in = your=20 liaison.

As requested, please find our replies to the issues = below.

1. Call identifier format sent by an originating UNI client. = (Q14=20 only)
Q14 agrees that the issue exists in G.7713.2 and accepts the OIF=20 recommendation to define that message for C-Type=3D0 in a future = G.7713.2 update.=20 It should be noted that while G.7713.2 and RFC3474 already specify the = use=20 C-type=3D0, a request to IANA for C-Type=3D0 was accidentally neglected = when=20 processing RFC3474. This oversight needs to be resolved.
 
2. = Use of=20 the NVC field for VCAT connections (Q14 only)
There are two issues that have to be considered in this = question. =20 First, in what order the VCAT vs server layer calls are created, and = second, if=20 the server connections should be co-routed or not.
When creating a VCAT call, the request could start from the client = layer=20 which then results in the creation of server layer calls.  In this = case=20 when the server layer connections are created, it is known that they = will=20 participate in a VCAT group (VCG).  The opposite can also occur = where there=20 are server layer connections are already in place and VCAT call obtains = them for=20 the VCG.  Here, no signalling in the server layer is needed for the = server=20 layer calls.  In the first case, setting the NVC field could be = done in the=20 server layer calls as it is known that they will be part of a VCAT = call. =20 In the second case, the original signalling used did not know that the = call=20 would be part of a future VCAT call and hence the NVC field remains=20 zeroed.  To accommodate the case where existing connections are = added to a=20 VCG, it appears that the NVC field is not relevant.
In the SONET/SDH TSPEC where NVC is defined, the implied purpose is = to=20 create LSP signalling state for single session that may have multiple = SONET/SDH=20 connections that are in parallel.  That is, when NVC is set to = >1, the=20 expectation is that the connections are co-routed and they follow the = same=20 link(s) and tandem switching points.  To be able to use more = available=20 bandwidth in the server layer, it is desirable to not limit the = connections in a=20 VCG to be co-routed.  In this scenario, each connection is = separately=20 routed and a separate connection state is needed per connection.  = To=20 accommodate this degree of freedom, the NVC field itself does not appear = to be=20 relevant to server layer signalling.
Regarding H4 byte usage, note = that it is=20 the VCAT function that uses this byte but only after the connection(s) = is(are)=20 created.  So from a signalling point of view, the server layer has = no need=20 to be aware that the H4 byte is going to be used.  Only the client = layer=20 (VCAT) needs to be aware and trigger the use of the H4 = byte.
 
3.=20 TSPEC format to be used for Ethernet connections (Q12 and Q14)
Q14 and Q12 think that a new Ethernet Traffic Parameters TSPEC in = RSVP-TE=20 is the best long-term solution for specifying Ethernet bandwidth service = parameters and will request that CCAMP considers the Q.8011/MEF.6 = Ethernet=20 service parameters and construct a suitable TSPEC for it that can be = used in the=20 UNI. We also suggest that the OIF similarly corresponds with=20 CCAMP.
 
 
An electronic copy of this liaison = statement is=20 available at:=20 ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICAT= IONS/index.html=20
------=_NextPart_000_031B_01C5C473.02837560-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Sep 2005 18:38:58 +0000 Message-ID: <433AE2D5.5060405@marconi.com> Date: Wed, 28 Sep 2005 14:37:09 -0400 From: David Charlap Organization: Marconi, Vienna VA User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: IETF MPLS List , IETF CCAMP List Subject: Graceful restart - inter-protocol dependencies Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Is there any point to implementing RSVP-TE's graceful restart without also implementing graceful restart for routing protocols? On the one hand, RSVP doesn't require routing to recover LSPs. It knows the next-hop interface, because of the preserved data-plane connection. Whatever other information it may need, the switch can either preserve this information or recover it from a neighbor using the RecoveryPath object (draft-ietf-ccamp-rsvo-restart-ext-03). On the other hand, nodes more than one hop upstream of the failure will detect the loss of routing-connectivity to the failed node if IGP graceful restart is not also implemented. They may reroute the LSP away from the failed node, or tear it down altogether, even though the data plane is still active and RSVP graceful restart is recovering the control-plane state. An originating node may consider the destination unreachable, as a result of losing the routes even though the data-plane for the LSP is still up (which can be confirmed via OAM.) A transit node, when processing an loose ERO-hop, may choose to reroute or fail the LSP if its local topology information says that the failed (and restarting) node is not available. It might even choose to do this for an established LSP, as a result of Path refresh processing. My questions are: 1: Does this mean it's pointless to use RSVP graceful restart without also using IGP graceful restart (for whatever IGP is active). 2: Is IGP graceful restart sufficient to prevent this problem? For instance, OSPF's restart procedure requires all preserved state to be thrown away if a topology change is detected. 3: An originating node can use OAM to validate the data plane of an LSP, and choose to ignore what routing tells it about the destination's reachability. But what about transit nodes? As far as I know, MPLS doesn't support segment-OAM, and it would be prohibitive for every transit node to run its own OAM streams to detect self-to-end connectivity. 4: Are there other solutions to this problem? One possible solution might be route-pinning, but RSVP doesn't have a built-in mechanism for this. The usual workaround (signal the LSP, requesting route-recording, then turn the RRO into an ERO for subsequent refreshes) can work, but are there situations where even this would be insufficient to prevent a transit node from rerouting/tearing the connection in this particular situation (where RSVP is doing a graceful restart but the IGP is not)? -- David Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Sep 2005 13:46:06 +0000 Message-ID: <020901c5c433$35234fd0$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Thomas D. Nadeau" , Cc: "Wijnen, Bert \(Bert\)" , Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Wed, 28 Sep 2005 14:16:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Again, thanks Joan. I think we are converging quickly. A few responses in the snipped email below. Cheers, Adrian > > >17) object: gmplsInterfaceSignalingCaps OBJECT-TYPE > > > > > > SYNTAX BITS { > > > unknown (0), > > > rsvpGmpls (1), > > > crldpGmpls (2), -- note the use of CR-LDP is deprecated > > > otherGmpls (3) > > > } > > > > > > > > >What is otherGmpls(3)?? > > > > Nack > > > > I'm embarrassed to say that there are other "GMPLS" signaling protocol > > variants that have been developed outside the IETF. This was added in > > response to a WG request. > > > > >Also, this description is confusing. How can unknown(0) and > > >rsvpGmpls(1) be set simultaneously? > > > > Ack > > Will add: > > > > ...but if unknown(0) is set, no other bit may be set. > > > > >Additionally, how can no bits be set? If this is a GMPLS interface, > > >then doesn't one of these bits HAVE to be set? > > > > Ack > > > > As it says... > > > > Setting no bits implies > > that GMPLS signaling cannot be performed on this interface and > > all LSPs must be manually provisioned or that this table entry > > is only present to supplement an entry in the > > mplsInterfaceTable > > by providing the information carried in other objects in this > > row. > > > > This means that we should change gmplsInterfaceEntry to read: > > > > "A conceptual row in this table is created automatically by an > > LSR for each interface that is both capable of supporting > > GMPLS and that is configured to support GMPLS. Note that > > support of GMPLS is not limited to control plane signaling, > > but may include data-plane only function configured through > > SNMP SET commands performed on this MIB module. > > > > A conceptual row in this table may also be created via SNMP > > SET commands or automatically by the LSR to supplement a > > conceptual row in the mplsInterfaceTable where the interface > > is not capable of GMPLS but where the other objects carried > > in this row provide useful additional information for an > > MPLS interface." > > If I could ask you to put your chair hat on for a minute, what are the > co-authors doing to get feedback from the MPLS working group on > objects which may apply to MPLS? > > Additionally, is this draft going to have a last call in the MPLS > working group? (maybe this is a question for the ADs). We can certainly poll the MPLS WG to see: a. if there are other attributes that need to be controlled and could be added to these modules b. if there are any further review comments Since the work form MPLS-TE is split between the MPLS and CCAMP working groups, it is usually assumed that anyone with an interest in MPLS-TE is following both working groups. Further, since GMPLS is a superset of MPLS-TE we can assume that anything that is needed for MPLS-TE is needed for GMPLS. But I will send mail, not as a formal last call, but to see if we can catch any more isues at this time. > Also, it seems this object would be more appropriate in the > GMPLS-TE-STD-MIB. Is there a reason for choosing the > GMPLS-LSR-STD-MIB for this object? The main reason is that this object desribes the capabilities of an LSR's interface. Included in this is the possilibity that the LSR does not support any signaling protocols on the interface but still supports LSPs (a la PVC). This makes this an LSR-related thing. Lastly, this object is part of the gmplsInterfaceTable which is an extension of the mplsInterfaceTable that appears in RFC3813, the MPLS-LSR-STD-MIB. > > >18) gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE > > > "Period, in milliseconds, between sending RSVP Hello messages > > > on > > > this interface. A value of 0 indicates that no Hello messages > > > should be sent on this interface." > > > > > >This object is only valid if the gmplsInterfaceSignalingCaps > > >object is set to rsvpGmpls. Please update the description > > >to reflect that. > > > > Nack > > It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB). > > Why is this object in this MIB as opposed to the GMPLS-TE-STD-MIB? > > I thought that GMPLS-TE-STD-MIB augmented the MPLS-TE-STD-MIB, > is that not the case? Exactly the point. RFC3812 does not contain per-interface objects. These are in RFC3813 in the MPLS-LSR-STD-MIB. You are correct that this object is protocol dependent and would not be used unless a TE protocol was in use (specifically RSVP-TE) unlike the previous object. Thus, we could introduce a per-interface table within the GMPLS-TE-STD-MIB to contain only this object, or we could leave it where it is with all of the other per-interface objects. Had there been more similar objects, I think we might have opted for this approach, but for one object it did not seem worth it. Do you feel strongly? > > >23) gmplsOutSegmentEntry OBJECT-TYPE > > >Same comments as with gmplsInSegmentEntry > > > > Nack > > Same answer > > Think you mean ack here? Oops, yes. > > >Section 8. GMPLS-LABEL-STD-MIB > > >=================================== > > > >31) gmplsLabelTable OBJECT-TYPE > > > > > >The last part of the last paragraph is awkward: > > > > > > "... Labels in the tables in other MIBs are referred to using > > > row pointer into this table. The indexing of this table > > > provides > > > for arbitrary indexing and also for concatenation of labels." > > > > > >Are you saying that other MIBs can use a row pointer to point to > > >this table? Why would they do that if they could just use the > > >indices directly? Also, I don't follow the comment about > > >concatenation of labels. Could you explain this? > > > > Nack > > Yes we are saying that other MIB modules can use a row pointer to > > point to this table. > > Yes they could use indices. This was the subject of a very lengthy > > discussion between the co-authors, etc., but in the end we > > observed that mplsInSegmentLabelPtr and mplsOutSegmentLabelPtr > > (RFC3813) are rowPointers so we had better support being pointed to. > > > > We could soften the language here by replacing "are" with "may". > > Yes, please. > > > Note, we should change this to say "MIB modules" > > > > good. > > > For an example of label concatenation see RFC3945 section 7.1. In > > essence, a GMPLS label may be composite in order to identify a set > > of resources in the data plane. Practial examples are timeslots > > and wavelength sets (which are not contiguous like wavebands). > > > > The indexing mechanism allows multiple entries in this table to be > > seen as a sequence of labels that should be concatenated. Ordering > > is potentially very sensitive for concatenation. > > > > It would be nice if you could add the above 2 paragraphs to the > DESCRIPTION. OK, will do. > > >32) gmplsLabelEntry OBJECT-TYPE > > > > > >The last sentence of the DESCRIPTION, please remove > > >the word "more" from the phrase "is more persistent." > > > > >I still don't understand how the subindex provides a way > > >to concatenate the labels. Could you give an example? > > > > Nack > > If you are asking for an example in the I-D, I don't think it is > > necessary. > > > > For your information, the composite label {{A}, {B}, {C}} might be > > constructed as... > > > > gmplsLabelInterface = 1 > > gmplsLabelIndex = 1 > > gmplsLabelSubindex = 1 > > gmplsLabelFreeform = A > > > > gmplsLabelInterface = 1 > > gmplsLabelIndex = 1 > > gmplsLabelSubindex = 2 > > gmplsLabelFreeform = B > > > > gmplsLabelInterface = 1 > > gmplsLabelIndex = 1 > > gmplsLabelSubindex = 3 > > gmplsLabelFreeform = C > > This is a good example and would, I think, be helpful someplace in the > document. This is only a suggestion however, and not a blocking issue. OK. We'll look at how to include an example in the pre-amble text (not the Description clasue). > > >34) gmplsLabelInterface OBJECT-TYPE > > > > > >DESCRIPTION also needs to specify that zero may be > > >used to indicate that the InterfaceIndex is not known > > >or that an InterfaceIndex exists but it is not important > > >wrt this implementation so zero is used. > > > > Nack > > The use of zero is very precisely specified at the moment. > > The reasons for setting zero that you cite are: > > - the InterfaceIndex is not known > > You cannot have a per-interface label space without knowing the > > interface to which it applies. > > - InterfaceIndex exists but it is not important wrt this > > implementation > > That is exactly the case of the global label space, and is already > > stated. > > I think you need to list all the reasons under which zero could be a > valid value for this index. You have listed more above which are not > specified in the description. Erm, but of the two reasons given above I have refuted one, and the other is specified in the descritpion. I can't think of a meaningful way to change the existing text. DESCRIPTION "The interface on which this label is used. If the label has or could have applicability across the whole system, this object SHOULD be set to zero." Perhaps we can re-order the words... DESCRIPTION "The interface on which this label is used. If this object is set to zero, the label has or could have applicability across the whole system and is not limited to a single interface." Does that help? > > > 35) gmplsLabelIndex OBJECT-TYPE > > > SYNTAX Unsigned32 (0..4294967295) > > > >36b)Please change the "may" to "should" in this statement: > > > A management application may read the gmplsLabelIndexNext > > > object to find a suitable value for this object." > > > > Nack > > Why "should" it do this? This is a convenience offered to it. It may > > use any mechanism it chooses including the one suggested in the > > quoted paragraph above. > > Without getting into a debate about tables and indexing, the > should is extremely appropriate. Think of the case where you have a > large number of rows in this table, do you expect a user to try a > bunch of numbers to create a row even if he/she has access to a CLI, > it will certainly be annoying to have to page through this table > and get to an available number. > > If a user consults the gmplsLabelIndexNext object then creating an > entry should be easier than not getting the gmplsLabelIndexNext > object. And if the implementation is using correlation of gmplsLabelIndex with the actual label ("Note that implementations that are representing 32 bit labels within this table MAY choose to align this index with the value of the label, but should be aware of the implications of sparsely populated tables.") then the use of gmplsLabelIndexNext would be completely inapproproriate because the correct value (dependent on the label actually assigned in hardware) comes from a different source. The use of "should" would curtail (a.k.a. break :-) this function. > > >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > > > > > >Please change the name to: gmplsLabelModuleReadOnlyCompliance > > >to be consistent with the other MPLS and GMPLS MIB modules. > > > > Nack > > I thought we tried to keep names down to 32 characters. I recall this > > conversation before. Not mandatory, but desirable. > > > > A choice between two desires? > > > > Please refer to Bert's comments on this. Agreed. > > >41) The ReadOnly compliance for gmplsLabelRowStatus > > >does NOT have a MIN-ACCESS of read-only. Is this > > >intentional? > > > > ??? > > Not sure about this. > > I thought the present of a WRITE-SYNTAX made some difference. > > Please refer to Bert's comments on this. Tom says he understands this, and will fix it. Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Sep 2005 13:45:57 +0000 Message-ID: <020801c5c433$3358f010$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: Subject: GMPLS MIBs are related to MPLS-TE Date: Wed, 28 Sep 2005 13:45:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, During MIB Doctor review of the GMPLS MIB modules it was pointed out that we have introduced new objects that may be useful extensions to the management of MPLS-TE systems that used the existing MPLS MIB modules (RFC3811 onwards). For example, we have the ability to configure/examine the Hello interval on a per-interface basis in an extension to the LSR MIB's mplsInterfaceTable. Since there will be a brief hiatus while the I-Ds are updated after MIB Doctor review, now would be a good opportunity for members of the MPLS community who have not been following the development of the GMPLS MIB modules within the CCAMP working group to comment on the documents. Of particular interest to the authors are two questions: - Are the MPLS-TE features that we have covered handled correctly? - Are there any MPLS-TE features that we have not included that you feel should be included? You can see the three GMPLS MIB documents at: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-07.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-08.txt http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-09.txt You can see the MIB Doctor's comments in the CCAMP mailing list archive. Many thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Sep 2005 12:25:42 +0000 Message-ID: <01d601c5c427$e012e330$be849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Wed, 28 Sep 2005 13:22:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks for your thoroughness, Joan. All points agreed. Adrian ----- Original Message ----- From: To: ; ; Cc: ; Sent: Wednesday, September 28, 2005 2:38 AM Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > Hi Adrian, > > A couple of minor comments inline below. > > thanks, > Joan > > > > > ----- Original Message ----- > > From: Adrian Farrel > > To: tnadeau@cisco.com ; ccamp@ops.ietf.org ; jcucchiara@mindspring.com > > Cc: bwijnen@lucent.com ; jcucchiara@mindspring.com > > Sent: Saturday, September 24, 2005 6:02 AM > > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > > > > > > Hi Joan, > > > > Thanks for the rapid convergence. > > > > In-line... > > > > Cheers, > > Adrian > > > > > >> 3*) Question if these documents should have a > > > >> contributors section. It violates the guidelines > > > >> of "RFC Editorial Guidelines and Procedures" > > > >> http://www.rfc-editor.org/policy.html#policy.auth2 > > > >> > > > >> There are many people listed under > > > >> Authors but not listed on the front page, > > > >> so how about adding a Contributors Section? > > > > > > > >Ack > > > >We will change the title of "Authors' Addresses" section to be "Contact > > > >Details". > > > > > > According to the rfc-editor website above, > > > this should be "Contact Information", is this what you mean? > > > > Yes, in deed. And Henrick's little tool catches this admirably. > > > > > >> draft-ietf-ccamp-gmpls-tc-mib-07.txt > > > >> ====================================== > > > >> > > > >> Section 3. GMPLS Textual Conventions MIB Definitions > > > >> --------------------------------------------------- > > > > > > >> 1) GmplsFreeformLabel TC > > > > > > >> 1c) The DESCRIPTION needs a little work: > > > >> DESCRIPTION > > > >> "This value represents a freeform generalized MPLS Label. This > > > >> can be used to represent label types which are not standard > in > > > >> the drafts. It may also be used by systems that do not wish > to > > > >> represent the labels using the specific label types." > > > >> > > > >> Please reword to something like: > > > >> > > > >> "This value represents a freeform GMPLS label. A freeform > GMPLS > > > >> label is specified by the system which uses it. In other > words, > > > >> the freeform GMPLS label is not a standard GMPLS label type, > > > >> but is created by the system which uses it." > > > > > > > >Nack > > > >The text as originally stated is correct and your revision is wrong. > That > > > >is, the freeform label MAY also be used to represent standard labels > > > >as octet strings. > > > >This is a popular way to handle the management of multiple different > > types > > > >of labels. > > > > > > > >Will change to: > > > > "This value represents a freeform GMPLS Label. This can be used > > > > to represent label that have label types which are not > > > > standardised. It may also be used by systems that do not wish > to > > > > represent labels that have standardised label types using the > > > > type-specific objects in this table." > > > > > > Sorry, I'm still a little foggy on what this TC is, partly because the > > > description is referring to "objects in this table" which is confusing > > > in a TC DESCRIPTION, and also the definition of the freeform label > > > used here and used in the GmplsGeneralizedLabelType enum seems be > > > defined slightly differently. > > > > Good point about "objects in this table." That needs to be removed. > > > > So, the description of GmplsGeneralizedLabelTypes should be changed to > > read... > > Determines the interpretation that should be applied to an > > object that encodes a label. > > > > But I don't see anything else in the GmplsGeneralizedLabelType enum that > > presents any interpretation of the freeform object. > > > > > A freeform label as described in the DESCRIPTION clause > > > could contain the value of any GMPLS/MPLS labels, > > > right? > > > > Right. > > > > How about... > > "This Textual Convention can be used as the syntax of an object > > that contains any GMPLS label. Objects with this syntax can be > > used to represent labels that have label types that are not > > standardised. The freeform GMPLS Label may also be used by > > systems that do not wish to represent labels that have > > standardised label types using type-specific syntaxes." > > > > Instead of saying "not standardised" could you say "not defined in any > RFCs"? > This is a small point but not sure if a label in a "proposed standard" > is considered "standardised" yet. > > Similarly, with the second use of "standarised" could you say "defined"? > > > > > > > >> 2) GmplsGeneralizedLabelTypes TC > > > > > > >> 2b) Could the SYNTAX order be changed? > > > >> > > > >> Currently: > > > >> > > > >> SYNTAX INTEGER { > > > >> gmplsMplsLabel(1), > > > >> gmplsPortWavelengthLabel(2), > > > >> gmplsFreeformGeneralizedLabel(3), > > > >> gmplsSonetLabel(4), > > > >> gmplsSdhLabel(5), > > > >> gmplsWavebandLabel(6) > > > >> } > > > >> > > > >> Proposed (NOTE also some of the names have been changed): > > > >> > > > >> SYNTAX INTEGER { > > > >> gmplsFreeformLabelOrOther(1), > > > >> gmplsMplsLabel(2), > > > >> gmplsPortAndWavelengthLabel(3), > > > >> gmplsSonetLabel(4), > > > >> gmplsSdhLabel(5), > > > >> gmplsWavebandLabel(6) > > > >> } > > > > > > > >Nack > > > >i. "FreeformOrOther" What other? There is just freeform. > > > > > > Aren't the label types: gmplsMplsLabel(2), > > > gmplsPortAndWavelengthLabel(3), > > > gmplsSonetLabel(4), > > > gmplsSdhLabel(5), > > > gmplsWavebandLabel(6) > > > also a kind of freeform GMPLS label (as indicated by the DESCRIPTION > > > clause in GmplsFreeformLabel)? > > > > It is all to do with the encodings of objects (i.e. the syntaxes) not the > > use to which the labels can be put. Thus, a normal 20-bit MPLS label an be > > encoded in an object with syntax MPLSLabel or in an object with syntax > > GMPLSFreeformLabel. In the former case it is presented as an Unsigned32. > In > > the latter case it is presented as an OCTET STRING. > > > > > >ii. Why re-order? The new order seems to have no more logic than the > > > > old order. > > > > > > Partly depends on the answer to above i. question. > > > If the labels are a kind of freeform label, > > > then a better style would be to list > > > gmplsFreeformLabel first. Admittedly, this is a NIT. > > > > > > Also, please add into the DESCRIPTION clause > > > a definition for each enum (an example would > > > be MplsLspType in RFC3811). > > > > Yes. That is a good idea. > > > > Description will now read... > > > > DESCRIPTION > > > > "Determines the interpretation that should be applied to an > > object that encodes a label. The possible types are: > > > > gmplsMplsLabel(1) - The label is an MPLS packet, cell, > > or frame label and is encoded as > > described for the Textual > Convention > > MPLSLabel defined in RFC 3811. > > Should be "MplsLabel" > > > > > > gmplsPortWavelengthLabel(2) - The label is a port or wavelength > > label as defined in RFC 3741. > > > > gmplsFreeformGeneralizedLabel(3) - The label is any form of label > > encoded > > as an OCTET STRING using the > Textual > > Convention GMPLSFreeformLabel. > > Please rename this enum to: gmplsFreeformLabel > which will match the GmplsFreeformLabel TC. (Also, GMPLSFreeformLabel > should be GmplsFreeformLabel.) > > > > > gmplsSonetLabel(4) - The label is a SONET label as > defined > > in RFC 3946. > > > > gmplsSdhLabel(5) - The label is an SDH label as > defined > > in > > RFC 3946. > > > > gmplsWavebandLabel(6) - The label is a waveband label as > > defined > > in RFC 3471." > > > > Please be sure to include all the above referenced RFCs in the > REFERENCE Clause of this object (and also in the Normative References > Section of this draft). > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Sep 2005 03:12:27 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=feDTD4SLz+yj4gL19HS/YRQCg8JIHaAgR3kPNHwJ/B0U60eJLbvMlhV0B3u5z/QT; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <012601c5c3da$b3441ec0$0500a8c0@jlucianilaptop> From: To: "Adrian Farrel" , , Cc: , Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Tue, 27 Sep 2005 23:14:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Adrian, I have snipped parts where we are in agreement. Please see inline comments. thanks, Joan ----- Original Message ----- From: Adrian Farrel To: ; ; Cc: ; Sent: Thursday, September 22, 2005 8:55 AM Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt > Hi again Joan, > > This is the response to your excellent review of the GMPLS LSR MIB module. > > As before, I have indicated Ack or Nack for each point you raised. Where > there is a Nack I have indicated either our reasoning or a proposed > alternate solution. > > Feel free to snip in any response you send. > > Once we have closure on a few remaining issues we will respin applying > David's > comments on the TE MIB here as well. > > Cheers, > Adrian > > >Section 4.1.2 Summary of GMPLS Label MIB Module > >------------------------------------------------- > > > >4) "Generalized Labels can be of variable length and have distinct > > bit-by-bit interpretations according to the use that is made of > > them." > > > >Please change the above to: > > > > "Generalized Labels can be of variable length and have distinct > > bit-by-bit interpretations depending upon how they are defined > > by the specific service provider." > > Nack. > Nothing to do with the service provider. > Will change to: > > "Generalized Labels can be of variable length and have distinct > bit-by-bit interpretations depending upon how they are defined > for the specific technology in which they are used. For example, > labels used for MPLS packet switching are different in length > and content from labels used in TDM timeslot switching." Good. Thanks. > >17) object: gmplsInterfaceSignalingCaps OBJECT-TYPE > > > > SYNTAX BITS { > > unknown (0), > > rsvpGmpls (1), > > crldpGmpls (2), -- note the use of CR-LDP is deprecated > > otherGmpls (3) > > } > > > > > >What is otherGmpls(3)?? > > Nack > > I'm embarrassed to say that there are other "GMPLS" signaling protocol > variants that have been developed outside the IETF. This was added in > response to a WG request. > > >Also, this description is confusing. How can unknown(0) and > >rsvpGmpls(1) be set simultaneously? > > Ack > Will add: > > ...but if unknown(0) is set, no other bit may be set. > > >Additionally, how can no bits be set? If this is a GMPLS interface, > >then doesn't one of these bits HAVE to be set? > > Ack > > As it says... > > Setting no bits implies > that GMPLS signaling cannot be performed on this interface and > all LSPs must be manually provisioned or that this table entry > is only present to supplement an entry in the mplsInterfaceTable > by providing the information carried in other objects in this > row. > > This means that we should change gmplsInterfaceEntry to read: > > "A conceptual row in this table is created automatically by an > LSR for each interface that is both capable of supporting > GMPLS and that is configured to support GMPLS. Note that > support of GMPLS is not limited to control plane signaling, > but may include data-plane only function configured through > SNMP SET commands performed on this MIB module. > > A conceptual row in this table may also be created via SNMP > SET commands or automatically by the LSR to supplement a > conceptual row in the mplsInterfaceTable where the interface > is not capable of GMPLS but where the other objects carried > in this row provide useful additional information for an > MPLS interface." If I could ask you to put your chair hat on for a minute, what are the co-authors doing to get feedback from the MPLS working group on objects which may apply to MPLS? Additionally, is this draft going to have a last call in the MPLS working group? (maybe this is a question for the ADs). Also, it seems this object would be more appropriate in the GMPLS-TE-STD-MIB. Is there a reason for choosing the GMPLS-LSR-STD-MIB for this object? > > >18) gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE > > "Period, in milliseconds, between sending RSVP Hello messages on > > this interface. A value of 0 indicates that no Hello messages > > should be sent on this interface." > > > >This object is only valid if the gmplsInterfaceSignalingCaps > >object is set to rsvpGmpls. Please update the description > >to reflect that. > > Nack > It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB). Why is this object in this MIB as opposed to the GMPLS-TE-STD-MIB? I thought that GMPLS-TE-STD-MIB augmented the MPLS-TE-STD-MIB, is that not the case? > > We can add: > This object is not valid if gmplsInterfaceSignalingCaps is > set to crldpGmpls (2) > > > > >22) gmplsInSegmentExtraParamsPtr OBJECT-TYPE > > SYNTAX RowPointer > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Some Tunnels will run over transports that can usefully support > > technology-specific additional parameters (for example, SONET > > resource usage). Such can be supplied from an external table and > > referenced from here. A value of zeroDotzero in this attribute > > indicates that there is no such additional information." > > DEFVAL { zeroDotZero } > > ::= { gmplsInSegmentEntry 2 } > > > >What is meant by "external table"? If this is an enterprise-specific > >table, then is it necessary to have this object in the MIB. In other > >words, why is this MIB dictating that a row-pointer be used when > >an enterprise-specific MIB may which to simply use indices. > > > >I think this object is unnecessary, but maybe I don't understand > >something. > > Nack > > rowPointers are typically used when there may be a many-to-one mapping. > This is appropriate for traffic parameters because there may be a few > service > categories defined in a traffic parameters table, and multiple LSPs may > use > those parameters. > > Compare with mplsInSegmentTrafficParamPtr in RFC3813. > > Now, in this case no such traffic parameters table has been supplied. To > some extent > we are guilty of future-proofing. We are aware that such tables will need > to be > added for TDM (quite soon), for lambda (possibly), and for Ethernet > (almost certainly). > > Although it would be possible to leave this out, we feel that the > necessary single-object > extension that would need to be created later would be messy. okay. > > >23) gmplsOutSegmentEntry OBJECT-TYPE > >Same comments as with gmplsInSegmentEntry > > Nack > Same answer Think you mean ack here? > > >24) gmplsOutSegmentDirection OBJECT-TYPE > >Same comment as with gmplsInSegmentDirection > > Ack > > >27) gmplsOutSegmentExtraParamsPtr OBJECT-TYPE > > > >Same comment as with gmplsInSegmentExtraParamsPtr > > Nack > Same answer > okay. > >28) Compliance Statements > > > >I believe that gmplsInSegmentExtraParamsPtr and > >gmplsOutSegmentExtraParamsPtr do not need to be > >supported, so these maybe should be optional. > > Ack > > >Section 8. GMPLS-LABEL-STD-MIB > >=================================== > >31) gmplsLabelTable OBJECT-TYPE > > > >The last part of the last paragraph is awkward: > > > > "... Labels in the tables in other MIBs are referred to using > > row pointer into this table. The indexing of this table provides > > for arbitrary indexing and also for concatenation of labels." > > > >Are you saying that other MIBs can use a row pointer to point to > >this table? Why would they do that if they could just use the > >indices directly? Also, I don't follow the comment about > >concatenation of labels. Could you explain this? > > Nack > Yes we are saying that other MIB modules can use a row pointer to > point to this table. > Yes they could use indices. This was the subject of a very lengthy > discussion between the co-authors, etc., but in the end we > observed that mplsInSegmentLabelPtr and mplsOutSegmentLabelPtr > (RFC3813) are rowPointers so we had better support being pointed to. > > We could soften the language here by replacing "are" with "may". > Yes, please. > Note, we should change this to say "MIB modules" > good. > For an example of label concatenation see RFC3945 section 7.1. In essence, > a GMPLS label may be composite in order to identify a set of resources in > the data plane. Practial examples are timeslots and wavelength sets (which > are not contiguous like wavebands). > > The indexing mechanism allows multiple entries in this table to be seen > as a sequence of labels that should be concatenated. Ordering is > potentially > very sensitive for concatenation. > It would be nice if you could add the above 2 paragraphs to the DESCRIPTION. > I don't believe we need to add text or references for concatenated labels > since they are part of the architecture. > > >32) gmplsLabelEntry OBJECT-TYPE > > > >The last sentence of the DESCRIPTION, please remove > >the word "more" from the phrase "is more persistent." > > Nack. > The Textual Convention gives us degrees. That is, 'readOnly' is more > durable than 'permanent' which is more durable than 'nonNolatile' which > is more durable than 'volatile'. > We need to convey that there is a ranked inheritance. > "Persistence" is acceptable in a comparative. > > >I still don't understand how the subindex provides a way > >to concatenate the labels. Could you give an example? > > Nack > If you are asking for an example in the I-D, I don't think it is > necessary. > > For your information, the composite label {{A}, {B}, {C}} might be > constructed > as... > > gmplsLabelInterface = 1 > gmplsLabelIndex = 1 > gmplsLabelSubindex = 1 > gmplsLabelFreeform = A > > gmplsLabelInterface = 1 > gmplsLabelIndex = 1 > gmplsLabelSubindex = 2 > gmplsLabelFreeform = B > > gmplsLabelInterface = 1 > gmplsLabelIndex = 1 > gmplsLabelSubindex = 3 > gmplsLabelFreeform = C > This is a good example and would, I think, be helpful someplace in the document. This is only a suggestion however, and not a blocking issue. > >33) please switch RowStatus and StorageType (this will > >more closely match the other MPLS MIBs). > > Ack > > >34) gmplsLabelInterface OBJECT-TYPE > > > >DESCRIPTION also needs to specify that zero may be > >used to indicate that the InterfaceIndex is not known > >or that an InterfaceIndex exists but it is not important > >wrt this implementation so zero is used. > > Nack > The use of zero is very precisely specified at the moment. > The reasons for setting zero that you cite are: > - the InterfaceIndex is not known > You cannot have a per-interface label space without knowing the > interface to which it applies. > - InterfaceIndex exists but it is not important wrt this implementation > That is exactly the case of the global label space, and is already > stated. > I think you need to list all the reasons under which zero could be a valid value for this index. You have listed more above which are not specified in the description. > >35) gmplsLabelIndex OBJECT-TYPE > > SYNTAX Unsigned32 (0..4294967295) > > > >36a) I was expecting the SYNTAX to be IndexInteger due > >to the gmplsLabelIndexNext in the DESCRIPTION. > >Please explain why the use of zero is needed. You > >explain the use of zero in the gmplsLabelInterface > >and gmplsLabelSubindex indices. > > Nack > > This is explained by the paragraph: > > Note that implementations that are representing 32 bit labels > within this table MAY choose to align this index with the value > of the label, but should be aware of the implications of > sparsely populated tables. > > We believe it would be inappropriate to use IndexInteger to have greater > meaning than just an index. > > But anyway, IndexInteger is Unsigned32 (1..4294967295) and the quoted > paragraph > must allow zero as well. Yes, it is fine to allow zero, I was just trying to understand when it should be zero (under what conditions)? > > >36b)Please change the "may" to "should" in this statement: > > A management application may read the gmplsLabelIndexNext > > object to find a suitable value for this object." > > Nack > Why "should" it do this? This is a convenience offered to it. It may use > any > mechanism it chooses including the one suggested in the quoted paragraph > above. Without getting into a debate about tables and indexing, the should is extremely appropriate. Think of the case where you have a large number of rows in this table, do you expect a user to try a bunch of numbers to create a row even if he/she has access to a CLI, it will certainly be annoying to have to page through this table and get to an available number. If a user consults the gmplsLabelIndexNext object then creating an entry should be easier than not getting the gmplsLabelIndexNext object. > > >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > > > >Please change the name to: gmplsLabelModuleReadOnlyCompliance > >to be consistent with the other MPLS and GMPLS MIB modules. > > Nack > I thought we tried to keep names down to 32 characters. I recall this > conversation before. Not mandatory, but desirable. > > A choice between two desires? > Please refer to Bert's comments on this. > >41) The ReadOnly compliance for gmplsLabelRowStatus > >does NOT have a MIN-ACCESS of read-only. Is this > >intentional? > > ??? > Not sure about this. > I thought the present of a WRITE-SYNTAX made some difference. > Please refer to Bert's comments on this. > >42) Also, (related to the above) > > OBJECT gmplsLabelRowStatus > > SYNTAX RowStatus { > > active(1), > > notInService(2) > > } > > > > WRITE-SYNTAX RowStatus { > > active(1), > > notInService(2), > > createAndGo(4), > > destroy(6) > > } > > DESCRIPTION > > "Support for notInService, createAndWait and notReady is not > > required." > > > >The DESCRIPTION clause conflicts with the WRITE-SYNTAX. > >Please clarify the intentions for this ReadOnly compliance > >object. > > Ack > There is an error here. > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 28 Sep 2005 01:37:33 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MG8DpLez+THIpwfbkHxWc6mEl0ULGTrN5TFA4S3ZronH8lV8LUvaKs4hOlGsHm50; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <009801c5c3cd$43d56e20$0500a8c0@jlucianilaptop> From: To: , , Cc: , Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Tue, 27 Sep 2005 21:38:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Adrian, A couple of minor comments inline below. thanks, Joan > ----- Original Message ----- > From: Adrian Farrel > To: tnadeau@cisco.com ; ccamp@ops.ietf.org ; jcucchiara@mindspring.com > Cc: bwijnen@lucent.com ; jcucchiara@mindspring.com > Sent: Saturday, September 24, 2005 6:02 AM > Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > > > Hi Joan, > > Thanks for the rapid convergence. > > In-line... > > Cheers, > Adrian > > > >> 3*) Question if these documents should have a > > >> contributors section. It violates the guidelines > > >> of "RFC Editorial Guidelines and Procedures" > > >> http://www.rfc-editor.org/policy.html#policy.auth2 > > >> > > >> There are many people listed under > > >> Authors but not listed on the front page, > > >> so how about adding a Contributors Section? > > > > > >Ack > > >We will change the title of "Authors' Addresses" section to be "Contact > > >Details". > > > > According to the rfc-editor website above, > > this should be "Contact Information", is this what you mean? > > Yes, in deed. And Henrick's little tool catches this admirably. > > > >> draft-ietf-ccamp-gmpls-tc-mib-07.txt > > >> ====================================== > > >> > > >> Section 3. GMPLS Textual Conventions MIB Definitions > > >> --------------------------------------------------- > > > > >> 1) GmplsFreeformLabel TC > > > > >> 1c) The DESCRIPTION needs a little work: > > >> DESCRIPTION > > >> "This value represents a freeform generalized MPLS Label. This > > >> can be used to represent label types which are not standard in > > >> the drafts. It may also be used by systems that do not wish to > > >> represent the labels using the specific label types." > > >> > > >> Please reword to something like: > > >> > > >> "This value represents a freeform GMPLS label. A freeform GMPLS > > >> label is specified by the system which uses it. In other words, > > >> the freeform GMPLS label is not a standard GMPLS label type, > > >> but is created by the system which uses it." > > > > > >Nack > > >The text as originally stated is correct and your revision is wrong. That > > >is, the freeform label MAY also be used to represent standard labels > > >as octet strings. > > >This is a popular way to handle the management of multiple different > types > > >of labels. > > > > > >Will change to: > > > "This value represents a freeform GMPLS Label. This can be used > > > to represent label that have label types which are not > > > standardised. It may also be used by systems that do not wish to > > > represent labels that have standardised label types using the > > > type-specific objects in this table." > > > > Sorry, I'm still a little foggy on what this TC is, partly because the > > description is referring to "objects in this table" which is confusing > > in a TC DESCRIPTION, and also the definition of the freeform label > > used here and used in the GmplsGeneralizedLabelType enum seems be > > defined slightly differently. > > Good point about "objects in this table." That needs to be removed. > > So, the description of GmplsGeneralizedLabelTypes should be changed to > read... > Determines the interpretation that should be applied to an > object that encodes a label. > > But I don't see anything else in the GmplsGeneralizedLabelType enum that > presents any interpretation of the freeform object. > > > A freeform label as described in the DESCRIPTION clause > > could contain the value of any GMPLS/MPLS labels, > > right? > > Right. > > How about... > "This Textual Convention can be used as the syntax of an object > that contains any GMPLS label. Objects with this syntax can be > used to represent labels that have label types that are not > standardised. The freeform GMPLS Label may also be used by > systems that do not wish to represent labels that have > standardised label types using type-specific syntaxes." > Instead of saying "not standardised" could you say "not defined in any RFCs"? This is a small point but not sure if a label in a "proposed standard" is considered "standardised" yet. Similarly, with the second use of "standarised" could you say "defined"? > > >> 2) GmplsGeneralizedLabelTypes TC > > > > >> 2b) Could the SYNTAX order be changed? > > >> > > >> Currently: > > >> > > >> SYNTAX INTEGER { > > >> gmplsMplsLabel(1), > > >> gmplsPortWavelengthLabel(2), > > >> gmplsFreeformGeneralizedLabel(3), > > >> gmplsSonetLabel(4), > > >> gmplsSdhLabel(5), > > >> gmplsWavebandLabel(6) > > >> } > > >> > > >> Proposed (NOTE also some of the names have been changed): > > >> > > >> SYNTAX INTEGER { > > >> gmplsFreeformLabelOrOther(1), > > >> gmplsMplsLabel(2), > > >> gmplsPortAndWavelengthLabel(3), > > >> gmplsSonetLabel(4), > > >> gmplsSdhLabel(5), > > >> gmplsWavebandLabel(6) > > >> } > > > > > >Nack > > >i. "FreeformOrOther" What other? There is just freeform. > > > > Aren't the label types: gmplsMplsLabel(2), > > gmplsPortAndWavelengthLabel(3), > > gmplsSonetLabel(4), > > gmplsSdhLabel(5), > > gmplsWavebandLabel(6) > > also a kind of freeform GMPLS label (as indicated by the DESCRIPTION > > clause in GmplsFreeformLabel)? > > It is all to do with the encodings of objects (i.e. the syntaxes) not the > use to which the labels can be put. Thus, a normal 20-bit MPLS label an be > encoded in an object with syntax MPLSLabel or in an object with syntax > GMPLSFreeformLabel. In the former case it is presented as an Unsigned32. In > the latter case it is presented as an OCTET STRING. > > > >ii. Why re-order? The new order seems to have no more logic than the > > > old order. > > > > Partly depends on the answer to above i. question. > > If the labels are a kind of freeform label, > > then a better style would be to list > > gmplsFreeformLabel first. Admittedly, this is a NIT. > > > > Also, please add into the DESCRIPTION clause > > a definition for each enum (an example would > > be MplsLspType in RFC3811). > > Yes. That is a good idea. > > Description will now read... > > DESCRIPTION > > "Determines the interpretation that should be applied to an > object that encodes a label. The possible types are: > > gmplsMplsLabel(1) - The label is an MPLS packet, cell, > or frame label and is encoded as > described for the Textual Convention > MPLSLabel defined in RFC 3811. Should be "MplsLabel" > > gmplsPortWavelengthLabel(2) - The label is a port or wavelength > label as defined in RFC 3741. > > gmplsFreeformGeneralizedLabel(3) - The label is any form of label > encoded > as an OCTET STRING using the Textual > Convention GMPLSFreeformLabel. Please rename this enum to: gmplsFreeformLabel which will match the GmplsFreeformLabel TC. (Also, GMPLSFreeformLabel should be GmplsFreeformLabel.) > > gmplsSonetLabel(4) - The label is a SONET label as defined > in RFC 3946. > > gmplsSdhLabel(5) - The label is an SDH label as defined > in > RFC 3946. > > gmplsWavebandLabel(6) - The label is a waveband label as > defined > in RFC 3471." > Please be sure to include all the above referenced RFCs in the REFERENCE Clause of this object (and also in the Normative References Section of this draft). Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 27 Sep 2005 17:37:43 +0000 Date: Tue, 27 Sep 2005 10:33:40 -0700 (PDT) From: Arthi Ayyangar To: Igor Bryskin cc: ccamp@ops.ietf.org Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt Message-ID: <20050927101912.W4485@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi Igor, Thanks for your comments. See my replies inline. > I have a few minor comments. > > 1. forwarding adjacency. > > The term is used in a sense of a data plane adjacency between two nodes > that could be used to send data directly to each other, which literally > means "forwarding adjacency" :=). Unfortunately the term is widely used in a > different sense - as a certain control plane quality of a TE link. I'd > recommend to use term "data plane adjacency" instead of "forwarding > adjacency" in this document. -----> I agree with your comment and in fact we started with the term data plane adjacency. But changed it to the well-established term of "forwarding adjacency". As you point out it also has a "well-established" control plane connotation...so to avoid any confusion we'll change this to data plane adjacency, where applicable. > 2. regular, basic TE link > > These terms are not clear and not defined anywhere. I'd suggest to use term > " TE link associated with statically configured data link(s)" ----> Okay. > 3. > > " > E.g. one suggested usage in case of P2MP RSVP > LSPs ([7]) is the use of LSP stitching to stitch a P2MP RSVP LSP to > an LSP segment between P2MP capable LSRs in the network. The LSP > segment would traverse legacy LSRs that may be incapable of acting as > P2MP branch points, thereby shielding them from the P2MP control and > data path.This statement is not quite accurate. Stitching segments as > well as H-LSPs help to use legacy non-P2MP capable (not branch incapable) > nodes as intermediate nodes of P2MP tunnels. This is not about branching > capability that legacy LSRs lack - this is about P2MP signaling capability. ---> Yes, this needs to be cleaned up. It was meant to deal with LSRs lacking P2MP control plane (signaling) capability. thanks, -arthi > Igor > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, September 23, 2005 3:50 PM > Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt > > >> 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 : Label Switched Path Stitching with Generalized MPLS Traffic > Engineering >> Author(s) : A. Ayyangar, J. Vasseur >> Filename : draft-ietf-ccamp-lsp-stitching-02.txt >> Pages : 19 >> Date : 2005-9-23 >> >> In certain scenarios, there may be a need to combine together >> different Generalized Multi-Protocol Label Switching (GMPLS) Label >> Switched Paths (LSPs) such that in the data plane, a single end-to- >> end (e2e) LSP is realized and all traffic from one LSP is switched >> onto the other LSP. We will refer to this as "LSP stitching". This >> document covers cases where: a) the node performing the stitching >> does not require configuration of every LSP pair to be stitched >> together b) the node performing the stitching is not the egress of >> any of the LSPs c) LSP stitching not only results in an end-to-end >> LSP in the data plane, but there is also a corresponding end-to-end >> LSP (RSVP session) in the control plane. >> >> It may be possible to configure a GMPLS node to switch the traffic >> from an LSP for which it is the egress, to another LSP for which it >> is the ingress, without requiring any signaling or routing extensions >> whatsoever, completely transparent to other nodes. This will also >> result in LSP stitching in the data plane. However, this document >> does not cover this scenario of LSP stitching. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-02.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the body of the > message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >> to change your subscription settings. >> >> >> 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-lsp-stitching-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-lsp-stitching-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. >> > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Sep 2005 19:18:18 +0000 Message-ID: <015b01c5c2ce$d0242b50$7a1810ac@movaz.com> From: "Igor Bryskin" To: Subject: Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt Date: Mon, 26 Sep 2005 15:16:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi. I'd like to recognize the good effort by the authors to bring the document into its current shape. I have a few minor comments. 1. forwarding adjacency. The term is used in a sense of a data plane adjacency between two nodes that could be used to send data directly to each other, which literally means "forwarding adjacency" :=). Unfortunately the term is widely used in a different sense - as a certain control plane quality of a TE link. I'd recommend to use term "data plane adjacency" instead of "forwarding adjacency" in this document. 2. regular, basic TE link These terms are not clear and not defined anywhere. I'd suggest to use term " TE link associated with statically configured data link(s)" 3. " E.g. one suggested usage in case of P2MP RSVP LSPs ([7]) is the use of LSP stitching to stitch a P2MP RSVP LSP to an LSP segment between P2MP capable LSRs in the network. The LSP segment would traverse legacy LSRs that may be incapable of acting as P2MP branch points, thereby shielding them from the P2MP control and data path.This statement is not quite accurate. Stitching segments as well as H-LSPs help to use legacy non-P2MP capable (not branch incapable) nodes as intermediate nodes of P2MP tunnels. This is not about branching capability that legacy LSRs lack - this is about P2MP signaling capability. Igor ----- Original Message ----- From: To: Cc: Sent: Friday, September 23, 2005 3:50 PM Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt > 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 : Label Switched Path Stitching with Generalized MPLS Traffic Engineering > Author(s) : A. Ayyangar, J. Vasseur > Filename : draft-ietf-ccamp-lsp-stitching-02.txt > Pages : 19 > Date : 2005-9-23 > > In certain scenarios, there may be a need to combine together > different Generalized Multi-Protocol Label Switching (GMPLS) Label > Switched Paths (LSPs) such that in the data plane, a single end-to- > end (e2e) LSP is realized and all traffic from one LSP is switched > onto the other LSP. We will refer to this as "LSP stitching". This > document covers cases where: a) the node performing the stitching > does not require configuration of every LSP pair to be stitched > together b) the node performing the stitching is not the egress of > any of the LSPs c) LSP stitching not only results in an end-to-end > LSP in the data plane, but there is also a corresponding end-to-end > LSP (RSVP session) in the control plane. > > It may be possible to configure a GMPLS node to switch the traffic > from an LSP for which it is the egress, to another LSP for which it > is the ingress, without requiring any signaling or routing extensions > whatsoever, completely transparent to other nodes. This will also > result in LSP stitching in the data plane. However, this document > does not cover this scenario of LSP stitching. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-lsp-stitching-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-lsp-stitching-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. > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 26 Sep 2005 11:26:34 +0000 Message-ID: <15be01c5c28d$36fdff00$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Wijnen, Bert \(Bert\)" , , , Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Mon, 26 Sep 2005 12:17:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Bert. Thanks. If 32 chars is no longer a limit, we should make the suggested change. I agree that consistency and comprehensibility of names are important. Wrt compliance statements etc. I will try to wrap my brain around this, but will probably need to bounce the resulting work off you and Joan. Cheers, Adrian ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "Adrian Farrel" ; ; ; Sent: Sunday, September 25, 2005 10:13 PM Subject: RE: review of draft-ietf-ccamp-lsr-mib-08.txt > W.r.t. > > >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > > > > > >Please change the name to: gmplsLabelModuleReadOnlyCompliance > > >to be consistent with the other MPLS and GMPLS MIB modules. > > > > Nack > > I thought we tried to keep names down to 32 characters. I recall this > > conversation before. Not mandatory, but desirable. > > > > The "rule" of less than 32 has long ago been relaxed. > I personally feel it is more important to be consistent in naming than > having less than 32 chars. > > See RFC4181 sect 4.2 > > But I agree it is not a fatal flaw, so we won't block on it. > > > A choice between two desires? > > > > >41) The ReadOnly compliance for gmplsLabelRowStatus > > >does NOT have a MIN-ACCESS of read-only. Is this > > >intentional? > > > > ??? > > Not sure about this. > > I thought the present of a WRITE-SYNTAX made some difference. > > > > If you have a MODULE-COMPLIANCE statement as you do: > > gmplsLabelModuleROCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Compliance requirement for implementations that only > provide read-only support for GMPLS-LABEL-STD-MIB. Such > devices can then be monitored but cannot be configured > using this MIB modules." > > So both the descriptor and the DESCRIPTION state that this is for > read-only support, then it feels VERY WEIRD to me (actually it > feels BROKEN to me) to not have all RowStatus objects be listed > with MIN-ACCESS read-only. And having a WRITE-SYNTAX feels > similarly weird. > > > >42) Also, (related to the above) > > > OBJECT gmplsLabelRowStatus > > > SYNTAX RowStatus { > > > active(1), > > > notInService(2) > > > } > > > > > > WRITE-SYNTAX RowStatus { > > > active(1), > > > notInService(2), > > > createAndGo(4), > > > destroy(6) > > > } > > > DESCRIPTION > > > "Support for notInService, createAndWait and notReady is not > > > required." > > > > > >The DESCRIPTION clause conflicts with the WRITE-SYNTAX. > > >Please clarify the intentions for this ReadOnly compliance > > >object. > > > > Ack > > There is an error here. > > > > See my comment above. I think it should be MIN-ACCESS read-only > and SYNTAX { active }. I do not see any other status to make sense. > > > > >Section 12.2 Informational References > > >--------------------------------------- > > > > > >43a) The title of this section should be > > >Informative. > > > > Ack/Nack > > > > I am aware of the RFC Editor's preferences. > > Unfortunately these references are only informative if you read an > > understand them (and > > even then not always :-), but they are informational even if you don't > > read or > > understand them. > > > > I know that RFC-editor uses a tool that prefers "informative". > But it is probably not mandatory. > > > Bert > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Sep 2005 23:07:39 +0000 Message-ID: <43372D62.5010501@psg.com> Date: Mon, 26 Sep 2005 01:06:10 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: inter-domain framework Content-Type: multipart/mixed; boundary="------------020900020408000800080201" This is a multi-part message in MIME format. --------------020900020408000800080201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian scanning section 2.3 on LSP stitching and in particular the following part of it "LSP stitching can be used in support of inter-domain TE LSPs. In particular, an LSP segment may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the LSP segment could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain." i came with the following question why the LSP tail-end can not terminate on a node outside of the head-end domain ? the definition as it reads to me precludes to stitch an inter-area LSP segment (starting/ ending at the ingress/egress node of an AS) as part of an inter-AS LSP segment for instance; this case does not seem to be covered and i fail to see what specifically forbids such construction ... in case of agreement, i would be please to provide the appropriate piece of text note: modelling LSP segment as TE link is a consequence of establishing them (as currently stated) within a single TE domain but there is no apparent reason why further use of LSP segment must be restricted now on to such construction --------------020900020408000800080201 Content-Type: text/plain; charset=UTF-8; name="www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-framework-04.txt" Network Working Group Adrian Farrel IETF Internet Draft Olddog Consulting Proposed Status: Informational Expires: January 2006 Jean-Philippe Vasseur Cisco Systems, Inc. Arthi Ayyangar Juniper Networks July 2005 A Framework for Inter-Domain MPLS Traffic Engineering draft-ietf-ccamp-inter-domain-framework-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document provides a framework for establishing and controlling Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) Label Switched Paths (LSPs) in multi-domain networks. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Farrel, Vasseur and Ayyangar Page 1 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 Contents 1. Introduction ............................................... 3 1.1. Nested Domains ......................................... 3 1.2. Conventions used in this document ...................... 4 2. Signaling Options .......................................... 4 2.1. LSP Nesting ............................................ 4 2.2. Contiguous LSP ......................................... 5 2.3. LSP Stitching .......................................... 5 2.4. Hybrid Methods ......................................... 6 2.5. Control of Downstream Choice of Signaling Method ....... 6 3. Path Computation Techniques ................................ 6 3.1. Management Configuration ............................... 7 3.2. Head End Computation ................................... 7 3.2.1. Multi-Domain Visibility Computation ................ 7 3.2.2. Partial Visibility Computation ..................... 7 3.2.3. Local Domain Visibility Computation ................ 8 3.3. Domain Boundary Computation ............................ 8 3.4. Path Computation Element ............................... 9 3.4.1. Multi-Domain Visibility Computation ................ 9 3.4.2. Path Computation Use of PCE When Preserving Confidentiality ................................... 10 3.4.3. Per-Domain Computation Servers .................... 10 3.5. Optimal Path Computation .............................. 10 4. Distributing Reachability and TE Information .............. 11 5. Comments on Advanced Functions ............................ 12 5.1. LSP Re-Optimization ................................... 12 5.2. LSP Setup Failure ..................................... 13 5.3. LSP Repair ............................................ 13 5.4. Fast Reroute .......................................... 14 5.5. Comments on Path Diversity ............................ 15 5.6. Domain-Specific Constraints ........................... 15 5.7. Policy Control ........................................ 16 5.8. Inter-domain OAM ...................................... 16 5.9. Point-to-Multipoint ................................... 16 5.10. Applicability to Non-Packet Technologies ............. 17 6. Security Considerations ................................... 17 7. IANA Considerations ....................................... 17 8. Acknowledgements .......................................... 17 9. Intellectual Property Considerations ...................... 17 10. Normative References ..................................... 18 11. Informational References ................................. 18 12. Authors' Addresses ....................................... 20 13. Full Copyright Statement ................................. 20 Farrel, Vasseur and Ayyangar Page 2 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 1. Introduction The Traffic Engineering Working Group has developed requirements for inter-area and inter-AS MPLS Traffic Engineering in [INTER-AREA] and [INTER-AS]. Various proposals have subsequently been made to address some or all of these requirements through extensions to the RSVP-TE and IGP (ISIS, OSPF) protocols and procedures. This document introduces the techniques for establishing Traffic Engineered (TE) Label Switched Paths (LSPs) across multiple domains. In this context and within the remainder of this document, we consider all source-based and constraint-based routed LSPs and refer to them interchangeably as "TE LSPs" or "LSPs". The functional components of these techniques are separated into the mechanisms for discovering reachability and TE information, for computing the paths of LSPs, and for signaling the LSPs. Note that the aim of this document is not to detail each of those techniques which are covered in separate documents referenced from the sections of this document that introduce the techniques, but rather to propose a framework for inter-domain MPLS Traffic Engineering. Note that in the remainder of this document, the term "MPLS Traffic Engineering" is used equally to apply to MPLS and GMPLS traffic. Specific issues pertaining to the use of GMPLS in inter-domain environments (for example, policy implications of the use of the Link Management Protocol [LMP] on inter-domain links) these are covered in separate documents such as [GMPLS-AS]. For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. Wholly or partially overlapping domains (e.g. path computation sub-domains of areas or ASs) are not within the scope of this document. 1.1. Nested Domains Nested domains are outside the scope of this document. It may be that some domains that are nested administratively or for the purposes of address space management can be considered as adjacent domains for the purposes of this document, however the fact that the domains are nested is then immaterial. In the context of MPLS TE, domain A is considered to be nested within domain B if domain A is wholly contained in Domain B, and domain B is fully or partially aware of the TE characteristics and topology of domain A. Farrel, Vasseur and Ayyangar Page 3 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 1.2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Signaling Options Three distinct options for signaling TE LSPs across multiple domains are identified. The choice of which options to use may be influenced by the path computation technique used (see section 3), although some path computation techniques may apply to multiple signaling options. The choice may further depend on the application to which the TE LSPs are put and the nature, topology and switching capabilities of the network. A comparison of the usages of the different signaling options is beyond the scope of this document and should be the subject of a separate applicability statement. 2.1. LSP Nesting Hierarchical LSPs form a fundamental part of MPLS [RFC3031] and are discussed in further detail in [HIER]. Hierarchical LSPs may optionally be advertised as TE links. Note that a hierarchical LSP that spans multiple domains cannot be advertised in this way because there is no concept of TE information that spans domains. Hierarchical LSPs can be used in support of inter-domain TE LSPs. In particular, a hierarchical LSP may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the hierarchical LSP could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain. The technique of carrying one TE LSP within another is termed LSP nesting. A hierarchical LSP may provide a TE LSP tunnel to transport (i.e. nest) multiple TE LSPs along a common part of their paths. Alternatively, a TE LSP may carry (i.e. nest) a single LSP in a one-to-one mapping. The signaling trigger for the establishment of a hierarchical LSP may be the receipt of a signaling request for the TE LSP that it will carry, or may be a management action to "pre-engineer" a domain to be crossed by TE LSPs that would be used as hierarchical LSPs by the traffic that has to traverse the domain. Furthermore, the mapping (inheritance rules) between attributes of the nested and the hierarchical LSPs (including bandwidth) may be statically pre-configured or, for on-demand hierarchical LSPs, may be dynamic according to the properties of the nested LSPs. Even in the dynamic case inheritance from the properties of the nested LSP(s) can be Farrel, Vasseur and Ayyangar Page 4 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 complemented by local or domain-wide policy rules. Note that a hierarchical LSP may be constructed to span multiple domains or parts of domains. However, such an LSP cannot be advertised as a TE link that spans domains. The end points of a hierarchical LSP are not necessarily on domain boundaries, so nesting is not limited to domain boundaries. Note also that the IGP/EGP routing topology is maintained unaffected by the LSP connectivity and TE links introduced by hierarchical LSPs even if they are advertised as TE links. That is, the routing protocols do not exchange messages over the hierarchical LSPs, and LSPs are not used to create routing adjacencies between routers. During the operation of establishing a nested LSP that uses a hierarchical LSP, the SENDER_TEMPLATE and SESSION objects remain unchanged along the entire length of the nested LSP, as do all other objects that have end-to-end significance. 2.2. Contiguous LSP A single contiguous LSP is established from ingress to egress in a single signaling exchange. No further LSPs are required to be established to support this LSP so that hierarchical or stitched LSPs are not needed. A contiguous LSP uses the same Session/LSP ID along the whole of its path (that is, at each LSR). The notions of "splicing" together different LSPs, or of "shuffling" Session or LSP identifiers is not considered. 2.3. LSP Stitching LSP Stitching is described in [STITCH]. In the LSP stitching model separate LSPs (referred to as a TE LSP segments) are established and are "stitched" together in the data plane so that a single end-to-end label switched path is achieved. The distinction is that the component LSP segments are signaled as distinct TE LSPs in the control plane. Each signaled TE LSP segment has a different source and destination. LSP stitching can be used in support of inter-domain TE LSPs. In particular, an LSP segment may be used to achieve connectivity between any pair of LSRs within a domain. The ingress and egress of the LSP segment could be the edge nodes of the domain in which case connectivity is achieved across the entire domain, or they could be any other pair of LSRs in the domain. Farrel, Vasseur and Ayyangar Page 5 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 The signaling trigger for the establishment of a TE LSP segment may be the establishment of the previous TE LSP segment, the receipt of a setup request for TE LSP that it plans to stitch to a local TE LSP segment, or may be a management action. LSP segments may be managed and advertised as TE links. 2.4. Hybrid Methods There is nothing to prevent the mixture of signaling methods described above when establishing a single, end-to-end, inter-domain TE LSP. It may be desirable in this case for the choice of the various methods to be reported along the path, perhaps through the RRO. If there is a desire to restrict which methods are used, this MUST be signaled as described in the next section. 2.5. Control of Downstream Choice of Signaling Method Notwithstanding the previous section, an ingress LSR MAY wish to restrict the signaling methods applied to a particular LSP at domain boundaries across the network. Such control, where it is required, may be achieved by the definition of appropriate new flags in the SESSION-ATTRIBUTE object or the Attributes Flags TLV of the LSP_ATTRIBUTES object [ATTRIB]. Before defining a mechanism to provide this level of control, the functional requirement to control the way in which the network delivers a service must be established and due consideration must be given to the impact on interoperability since new mechanisms must be backwards compatible, and care must be taken to avoid allowing standards-conformant implementations each supporting a different functional subset such that they are not capable of estbalishing LSPs. 3. Path Computation Techniques The discussion of path computation techniques within this document is limited significantly to the determination of where computation may take place and what components of the full path may be determined. The techniques used are closely tied to the signaling methodologies described in the previous section in that certain computation techniques may require the use of particular signaling approaches and vice versa. Any discussion of the appropriateness of a particular path computation technique in any given circumstance is beyond the scope of this document and should be described in a separate applicability statement. Path computation algorithms are firmly out of scope of this document. Farrel, Vasseur and Ayyangar Page 6 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 3.1. Management Configuration Path computation may be performed by offline tools or by a network planner. The resultant path may be supplied to the ingress LSR as part of the TE LSP or service request, and encoded by the ingress LSR as an ERO on the Path message that is sent out. There is no reason why the path provided by the operator should not span multiple domains if the relevant information is available to the planner or the offline tool. The definition of what information is needed to perform this operation and how that information is gathered, is outside the scope of this document. 3.2. Head End Computation The head end, or ingress, LSR may assume responsibility for path computation when the operator supplies part or none of the explicit path. The operator MUST, in any case, supply at least the destination address (egress) of the LSP. 3.2.1. Multi-Domain Visibility Computation If the ingress has sufficient visibility of the topology and TE information for all of the domains across which it will route the LSP to its destination then it may compute and provide the entire path. The quality of this path (that is, its optimality as discussed in section 3.5) can be better if the ingress has full visibility into all relevant domains rather than just sufficient visibility to provide some path to the destination. Extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4. 3.2.2. Partial Visibility Computation It may be that the ingress does not have full visibility of the topology of all domains, but does have information about the connectedness of the domains and the TE resource availability across the domains. In this case, the ingress is not able to provide a fully specified strict explicit path from ingress to egress. However, for example, the ingress might supply an explicit path that comprises: - explicit hops from ingress to the local domain boundary - loose hops representing the domain entry points across the network - a loose hop identifying the egress. Alternatively, the explicit path might be expressed as: - explicit hops from ingress to the local domain boundary - strict hops giving abstract nodes representing each domain in turn - a loose hop identifying the egress. Farrel, Vasseur and Ayyangar Page 7 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 These two explicit path formats could be mixed according to the information available resulting in different combinations of loose hops and abstract nodes. This form of explicit path relies on some further computation technique being applied at the domain boundaries. See section 3.3. As with the multi-domain visibility option, extreme caution must be exercised in consideration of the distribution of the requisite TE information. See section 4. 3.2.3. Local Domain Visibility Computation A final possibility for ingress-based computation is that the ingress LSR has visibility only within its own domain, and connectivity information only as far as determining one or more domain exit points that may be suitable for carrying the LSP to its egress. In this case the ingress builds an explicit path that comprises just: - explicit hops from ingress to the local domain boundary - a loose hop identifying the egress. 3.3. Domain Boundary Computation If the partial explicit path methods described in sections 3.2.2 or 3.2.3 are applied then the LSR at each domain boundary is responsible for ensuring that there is sufficient path information added to the Path message to carry it at least to the next domain boundary (that is, out of the new domain). If the LSR at the domain boundary has full visibility to the egress then it can supply the entire explicit path. Note however, that the ERO processing rules of [RFC3209] state that it SHOULD only update the ERO as far as the next specified hop (that is, the next domain boundary if one was supplied in the original ERO) and, of course, MUST NOT insert ERO subobjects immediately before a strict hop. If the LSR at the domain boundary has only partial visibility (using the definitions of section 3.2.2) it will fill in the path as far as the next domain boundary, and will supply further domain/domain boundary information if not already present in the ERO. If the LSR at the domain boundary has only local visibility into the immediate domain it will simply add information to the ERO to carry the Path message as far as the next domain boundary. Domain boundary path computations are performed independently from each other. Domain boundary LSRs may have different computation capabilities, run different path computation algorithms, apply different sets of constraints and optimization criteria, and so forth, which might result in path segment quality which is Farrel, Vasseur and Ayyangar Page 8 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 unpredictable to and out of the control of the ingress LSR. A solution to this issue lies in enhancing the informaiton signaled during LSP setup to include a larger set of constraints and to include the paths of related LSPs (such as diverse protected LSPs) as described in [GMPLS-E2E]. It is also the case that paths generated on domain boundaries may produce loops. Specifically, the paths computed may loop back into a domain that has already been crossed by the LSP. This may, or may not be a problem, and might even be desirable, but could also give rise to real loops. This can be avoided by using the recorded route (RRO) to provide exclusions within the path computation algorithm, but in the case of lack of trust between domains it may be necessary for the RRO to indicate the previously visited domains. Even this solution is not available where the RRO is not available on a Path message. Note that when an RRO is used to provide exclusions, and a loop-free path is found to be not available by the computation at a downstream border node, crankback [CRANKBACK] may enable an upstream border node to select an alternate path. 3.4. Path Computation Element The computation techniques in sections 3.2 and 3.3 rely on topology and TE information being distributed to the ingress LSR and those LSRs at domain boundaries. These LSRs are responsible for computing paths. Note that there may be scaling concerns with distributing the required information - see section 4. An alternative technique places the responsibility for path computation with a Path Computation Element (PCE) [PCE]. There may be either a centralized PCE, or multiple PCEs (each having local visibility and collaborating in a distributed fashion to compute an end-to-end path) across the entire network and even within any one domain. The PCE may collect topology and TE information from the same sources as would be used by LSRs in the previous paragraph, or though other means. Each LSR called upon to perform path computation (and even the offline management tools described in section 3.1) may abdicate the task to a PCE of its choice. The selection of PCE(s) may be driven by static configuration or the dynamic discovery. 3.4.1. Multi-Domain Visibility Computation A PCE may have full visibility, perhaps through connectivity to multiple domains. In this case it is able to supply a full explicit path as in section 3.2.1. Farrel, Vasseur and Ayyangar Page 9 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 3.4.2. Path Computation Use of PCE When Preserving Confidentiality Note that although a centralized PCE or multiple collaborative PCEs may have full visibility into one or more domains, it may be desirable (e.g to preserve confidentiality) that the full path is not provided to the ingress LSR. Instead, a partial path is supplied (as in section 3.2.2 or 3.2.3) and the LSRs at each domain boundary are required to make further requests for each successive segment of the path. In this way an end-to-end path may be computed using the full network capabilities, but confidentiality between domains may be preserved. Optionally, the PCE(s) may compute the entire path at the first request and hold it in storage for subsequent requests, or it may recompute each leg of the path on each request or at regular intervals until requested by the LSRs establishing the LSP. It may be the case that the centralized PCE or the collaboration between PCEs may define a trust relationship greater than that normally operational between domains. 3.4.3. Per-Domain Computation Elements A third way that PCEs may be used is simply to have one (or more) per domain. Each LSR within a domain that wishes to derive a path across the domain may consult its local PCE. This mechanism could be used for all path computations within the domain, or specifically limited to computations for LSPs that will leave the domain where external connectivity information can then be restricted to just the PCE. 3.5. Optimal Path Computation There are many definitions of an optimal path depending on the constraints applied to the path computation. In a multi-domain environment the definitions are multiplied so that an optimal route might be defined as the route that would be computed in the absence of domain boundaries. Alternatively, another constraint might be applied to the path computation to reduce or limit the number of domains crossed by the LSP. It is easy to construct examples that show that partitioning a network into domains, and the resulting loss or aggregation of routing information may lead to the computation of routes that are other than optimal. It is impossible to guarantee optimal routing in the presence of aggregation / abstraction / summarization of routing information. It is beyond the scope of this document to define what is an optimum path for an inter-domain TE LSP. This debate is abdicated in favor of Farrel, Vasseur and Ayyangar Page 10 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 requirements documents and applicability statements for specific deployment scenarios. Note, however, that the meaning of certain computation metrics may differ between domains (see section 5.6). 4. Distributing Reachability and TE Information Traffic Engineering information is collected into a TE Database (TED) on which path computation algorithms operate either directly or by first constructing a network graph. The path computation techniques described in the previous section make certain demands upon the distribution of reachability information and the TE capabilities of nodes and links within domains as well as the TE connectivity across domains. Currently, TE information is distributed within domains by additions to IGPs [RFC3630], [RFC3784]. In cases where two domains are interconnected by one or more links (that is, the domain boundary falls on a link rather than on a node), there SHOULD be a mechanism to distribute the TE information associated with the inter-domain links to the corresponding domains. This would facilitate better path computation and reduce TE-related crankbacks on these links. Where a domain is a subset of an IGP area, filtering of TE information may be applied at the domain boundary. This filtering may be one way, or two way. Where information needs to reach a PCE that spans multiple domains, the PCE may snoop on the IGP traffic in each domain, or play an active part as an IGP-capable node in each domain. The PCE might also receive TED updates from a proxy within the domain. It could be possible that an LSR that performs path computation (for example, an ingress LSR) obtains the topology and TE information of not just its own domain, but other domains as well. This information may be subject to filtering applied by the advertising domain (for example, the information may be limited to FAs across other domains, or the information may be aggregated or abstracted). Before starting work on any protocols or protocol extensions to enable cross-domain reachability and TE advertisement in support of inter-domain TE, the requirements and and benefits must be clearly established. This has not been done to date. Where any cross-domain reachability and TE information needs to be advertised, consideration must be given to TE extensions to existing protocols such as BGP, and how the information advertised may be fed to the IGPs. It must be noted that any extensions that cause a significant increase in the amount of processing (such as aggregation computation) at domain boundaries, or a significant increase in the amount of information Farrel, Vasseur and Ayyangar Page 11 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 flooded (such as detailed TE information) need to be treated with extreme caution and compared carefully with the scaling requirements expressed in [INTER-AREA] and [INTER-AS]. 5. Comments on Advanced Functions This section provides some non-definitive comments on the constraints placed on advanced MPLS TE functions by inter-domain MPLS. It does not attempt to state the implications of using one inter-domain technique or another. Such material is deferred to appropriate applicability statements where statements about the capabilities of existing or future signaling, routing and computation techniques to deliver the functions listed should be made. 5.1. LSP Re-Optimization Re-optimization is the process of moving a TE LSP from one path to another, more preferable path (where no attempt is made in this document to define "preferable" as no attempt was made to define "optimal"). Make-before-break techniques are usually applied to ensure that traffic is disrupted as little as possible. The Shared Explicit style is usually used to avoid double booking of network resources. Re-optimization may be available within a single domain. Alternatively, re-optimization may involve a change in route across several domains or might involve a choice of different transit domains. Re-optimization requires that all or part of the path of the LSP be re-computed. The techniques used may be selected as described in section 3, and this will influence whether the whole or part of the path is re-optimized. The trigger for path computation and re-optimization may be an operator request, a timer, information about a change in availability of network resources, or a change in operational parameters (for example bandwidth) of an LSP. This trigger MUST be applied to the point in the network that requests re-computation and controls re-optimization and may require additional signaling. Note also that where multiple mutually-diverse paths are applied end-to-end (i.e. not simply within protection domains - see section 5.5) the point of calculation for re-optimization (whether it is PCE, ingress, or domain entry point) needs to know all such paths before attempting re-optimization of any one path. Mutual diversity here means that a set of computed paths have no commonality. Such diversity might be link, node, SRLG or even domain disjointedness according to circumstances and the service being delivered. Farrel, Vasseur and Ayyangar Page 12 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 It may be the case that re-optimization is best achieved by recomputing the paths of multiple LSPs at once. Indeed, this can be shown to be most efficient when the paths of all LSPs are known, not simply those LSPs that originate at a particular ingress. While this problem is inherited from single domain re-optimization and is out of scope within this document, it should be noted that the problem grows in complexity when LSPs wholly within one domain affect the re-optimization path calculations performed in another domain. 5.2. LSP Setup Failure When an inter-domain LSP setup fails in some domain other than the first, various options are available for reporting and retrying the LSP. In the first instance, a retry may be attempted within the domain that contains the failure. That retry may be attempted by nodes wholly within the domain, or the failure may be referred back to the LSR at the domain boundary. If the failure cannot be bypassed within the domain where the failure occurred (perhaps there is no suitable alternate route, perhaps rerouting is not allowed by domain policy, or perhaps the Path message specifically bans such action), the error MUST be reported back to the previous or head-end domain. Subsequent repair attempts may be made by domains further upstream, but will only be properly effective if sufficient information about the failure and other failed repair attempts is also passed back upstream [CRANKBACK]. Note that there is a tension between this requirement and that of confidentiality although crankback aggregation may be applicable at domain boundaries. Further attempts to signal the failed LSP may apply the information about the failures as constraints to path computation, or may signal them as specific path exclusions [EXCLUDE]. When requested by signaling, the failure may also be systematically reported to the head-end LSR. 5.3. LSP Repair An LSP that fails after it has been established may be repaired dynamically by re-routing. The behavior in this case is either like that for re-optimization, or for handling setup failures (see previous two sections). Fast Reroute may also be used (see below). Farrel, Vasseur and Ayyangar Page 13 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 5.4. Fast Reroute MPLS Traffic Engineering Fast Reroute ([FRR]) defines local protection schemes intended to provide fast recovery (in 10s of msecs) of fast-reroutable packet-based TE LSPs upon link/SRLG/Node failure. A backup TE LSP is configured and signaled at each hop, and activated upon detecting or being informed of a network element failure. The node immediately upstream of the failure (called the PLR - Point of Local Repair) reroutes the set of protected TE LSPs onto the appropriate backup tunnel(s) and around the failed resource. In the context of inter-domain TE, there are several different failure scenarios that must be analyzed. Provision of suitable solutions may be further complicated by the fact that [FRR] specifies two distinct modes of operation referred to as the "one to one mode" and the "facility back-up mode". The failure scenarios specific to inter-domain TE are as follows: - Failure of a domain edge node that is present in both domains. There are two sub-cases: - The PLR and the MP are in the same domain - The PLR and the MP are in different domains. - Failure of a domain edge node that is only present in one of the domains. - Failure of an inter-domain link. Although it may be possible to apply the same techniques for FRR to the different methods of signaling inter-domain LSPs described in section 2, the results of protection may be different when it is the boundary nodes that need to be protected, and when they are the ingress and egress of a hierarchical LSP or stitched LSP segment. In particular, the choice of Point of Local Repair (PLR) and Merge Point (MP) may be different, and the length of the protection path may be greater. These use of FRR techniques should be explained further in applicability statements or, in the case of a change in base behavior, in implementation guidelines specific to the signaling techniques. Note that after local repair has been performed, it may be desirable to re-optimize the LSP (see section 5.1). If the point of re-optimization (for example the ingress LSR) lies in a different domain to the failure, it may rely on the delivery of a PathErr or Notify message to inform it of the local repair event. It is important to note that Fast Reroute techniques are only applicable to packet switching networks because other network Farrel, Vasseur and Ayyangar Page 14 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 technologies cannot apply label stacking within the same switching type. Segment protection [SEG-PROT] provides a suitable alternative that is applicable to packet and non-packet networks. 5.5. Comments on Path Diversity Diverse paths may be required in support of load sharing and/or protection. Such diverse paths may be required to be node diverse, link diverse, fully path diverse (that is, link and node diverse), or SRLG diverse. Diverse path computation is a classic problem familiar to all graph theory majors. The problem is compounded when there are areas of "private knowledge" such as when domains do not share topology information. The problem can be resolved more efficiently (e.g. avoiding the "trap problem") when mutually resource disjoint paths can be computed "simultaneously" on the fullest set of information. That being said, various techniques (out of the scope of this document) exist to ensure end-to-end path diversity across multiple domains. Many network technologies utilize "protection domains" because they fit well with the capabilities of the technology. As a result, many domains are operated as protection domains. In this model, protection paths converge at domain boundaries. Note that the question of SRLG identification is not yet fully answered. There are two classes of SRLG: - those that indicate resources that are all contained witin one domain - those that span domains. The former might be identified using a combination of a globally scoped domain ID, and an SRLG ID that is administered by the domain. The latter requires a global scope to the SRLG ID. Both schemes, therefore, require external administration. The former is able to leverage existing domain ID administration (for example, area and AS numbers), but the latter would require a new administrative policy. 5.6. Domain-Specific Constraints While the meaning of certain constraints, like bandwidth, can be assumed to be constant across different domains, other TE constraints (such as resource affinity, color, metric, priority, etc.) may have different meanings in different domains and this may impact the ability to support DiffServ-aware MPLS, or to manage pre-emption. Farrel, Vasseur and Ayyangar Page 15 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 In order to achieve consistent meaning and LSP establishment, this fact must be considered when performing constraint-based path computation or when signaling across domain boundaries. A mapping function can be derived for most constraints based on policy agreements between the Domain administrators. The details of such a mapping function are outside the scope of this document, but it is important to note that the default behavior MUST either be that a constant mapping is applied or that any requirement to apply these constraints across a domain boundary must fail in the absence of explicit mapping rules. 5.7. Policy Control Domain boundaries are natural points for policy control. There is little to add on this subject except to note that a TE LSP that cannot be established on a path through one domain because of a policy applied at the domain boundary, may be satisfactorily established using a path that avoids the demurring domain. In any case, when a TE LSP signaling attempt is rejected due to non-compliance with some policy constraint, this SHOULD be reflected to the ingress LSR. 5.8. Inter-domain OAM Some elements of OAM may be intentionally confined within a domain. Others (such as end-to-end liveness and connectivity testing) clearly need to span the entire multi-domain TE LSP. Where issues of confidentiality are strong, collaboration between PCEs or domain boundary nodes might be required in order to provide end-to-end OAM, and a significant issue to be resolved is to ensure that the end-points support the various OAM capabilities. The different signaling mechanisms described above may need refinements to [LSPPING], and [BFD-MPLS], etc., to gain full end-to-end visibility. These protocols should, however, be considered in the light of confidentiality requirements. Route recording is a commonly used feature of signaling that provides OAM information about the path of an established LSP. When an LSP traverses a domain boundary, the border node may remove or aggregate some of the recorded information for confidentiality or other policy reasons. 5.9. Point-to-Multipoint Inter-domain point-to-multipoint (P2MP) requirements are explicitly out of scope of this document. They may be covered by other documents dependent on the details of MPLS TE P2MP solutions. Farrel, Vasseur and Ayyangar Page 16 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 5.10. Applicability to Non-Packet Technologies Non-packet switching technologies may present particular issues for inter-domain LSPs. While packet switching networks may utilize control planes built on MPLS or GMPLS technology, non-packet networks are limited to GMPLS. On the other hand, some problems such as Fast Re-Route on domain boundaries (see section 5.4) may be handled by the GMPLS technique of segment protection [GMPLS-SEG] that is applicable to both packet and non-packet switching technologies. The specific architectural considerations and requirements for inter-domain LSP setup in non-packet networks are covered in a separate document [GMPLS-AS]. 6. Security Considerations Requirements for security within domains are unchanged from [RFC3209] and [RFC3473], but requirements for inter-domain security are, if anything, more significant. Authentication techniques identified for use with RSVP-TE can only operate across domain boundaries if there is coordination between the administrators of those domains. Confidentiality may also be considered to be security factors. Applicability statements for particular combinations of signaling, routing and path computation techniques are expected to contain detailed security sections. 7. IANA Considerations This document makes no requests for any IANA action. 8. Acknowledgements The authors would like to extend their warmest thanks to Kireeti Kompella for convincing them to expend effort on this document. Grateful thanks to Dimitri Papadimitriou, Tomohiro Otani and Igor Bryskin for their review and suggestions on the text. 9. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has Farrel, Vasseur and Ayyangar Page 17 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3209] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 11. Informational References [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF Version 2", RFC 3630, September 2003 [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", RFC 3784, June 2004. Farrel, Vasseur and Ayyangar Page 18 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 [ATTRIB] A. Farrel, D. Papadimitriou, JP. Vasseur, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using RSVP-TE", draft-ietf-mpls-rsvpte-attributes, work in progress. [BFD-MPLS] R. Aggarwal and K. Kompella, "BFD For MPLS LSPs", work in progress. [CRANKBACK] Farrel, A., et al., "Crankback Signaling Extensions for MPLS Signaling", draft-ietf-ccamp-crankback, work in progress. [EXCLUDE] Lee et all, Exclude Routes - Extension to RSVP-TE, draft-ietf-ccamp-rsvp-te-exclude-route, work in progress. [FRR] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute, work in progress. [GMPLS-AS] Otani, T., Kumaki, K., and Okamoto, S., "GMPLS Inter-AS Traffic Engineering Requirements", draft-otani-ccamp-interas-GMPLS-TE, work in progress. [GMPLS-E2E] Lang, J.P., Rekhter, Y., Papadimitriou, D., Editors, "RSVP-TE Extensions in support of End-to-End GMPLS-based Recovery", draft-lang-ccamp-gmpls-recovery-e2e-signaling, work in progress. [HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy, work in progress. [INTER-AREA] Le Roux, Vasseur et Boyle, "Requirements for support of Inter-Area and Inter-AS MPLS Traffic Engineering", draft-ietf-tewg-interarea-mpls-te-req, work in progress. [INTER-AS] Zhang, R., Vasseur, JP. et al, "MPLS Inter-AS Traffic Engineering requirements", draft-ietf-tewg-interas-mpls-te-req, work in progress. [LSPPING] Kompella, K., et al., " Detecting Data Plane Liveliness in MPLS", draft-ietf-mpls-lsp-ping, work in progress. [OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay Model", draft-ietf-ccamp-gmpls-overlay, work in progress. Farrel, Vasseur and Ayyangar Page 19 draft-ietf-ccamp-inter-domain-framework-04.txt July 2005 [PCE] Ash, G., Farrel, A., and Vasseur, JP., "Path Computation Element (PCE) Architecture", draft-ietf-pce-architecture, work in progress. [SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D. and Farrel, A., "GMPLS Based Segment Recovery", draft-ietf-ccamp-gmpls-segment-recovery, work in progress. [STITCH] Ayyangar, A., and Vasseur, JP., "LSP Stitching with Generalized MPLS TE", draft-ietf-ccamp-lsp-stitching, work in progress. 12. Authors' Addresses Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: jpv@cisco.com Arthi Ayyangar Juniper Networks, Inc 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA Email: arthi@juniper.net 13. Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Farrel, Vasseur and Ayyangar Page 20 --------------020900020408000800080201-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 25 Sep 2005 21:16:53 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15508234609@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Adrian Farrel , tnadeau@cisco.com, ccamp@ops.ietf.org, jcucchiara@mindspring.com Subject: RE: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Sun, 25 Sep 2005 23:13:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" W.r.t. > >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > > > >Please change the name to: gmplsLabelModuleReadOnlyCompliance > >to be consistent with the other MPLS and GMPLS MIB modules. > > Nack > I thought we tried to keep names down to 32 characters. I recall this > conversation before. Not mandatory, but desirable. > The "rule" of less than 32 has long ago been relaxed. I personally feel it is more important to be consistent in naming than having less than 32 chars. See RFC4181 sect 4.2 But I agree it is not a fatal flaw, so we won't block on it. > A choice between two desires? > > >41) The ReadOnly compliance for gmplsLabelRowStatus > >does NOT have a MIN-ACCESS of read-only. Is this > >intentional? > > ??? > Not sure about this. > I thought the present of a WRITE-SYNTAX made some difference. > If you have a MODULE-COMPLIANCE statement as you do: gmplsLabelModuleROCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for GMPLS-LABEL-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB modules." So both the descriptor and the DESCRIPTION state that this is for read-only support, then it feels VERY WEIRD to me (actually it feels BROKEN to me) to not have all RowStatus objects be listed with MIN-ACCESS read-only. And having a WRITE-SYNTAX feels similarly weird. > >42) Also, (related to the above) > > OBJECT gmplsLabelRowStatus > > SYNTAX RowStatus { > > active(1), > > notInService(2) > > } > > > > WRITE-SYNTAX RowStatus { > > active(1), > > notInService(2), > > createAndGo(4), > > destroy(6) > > } > > DESCRIPTION > > "Support for notInService, createAndWait and notReady is not > > required." > > > >The DESCRIPTION clause conflicts with the WRITE-SYNTAX. > >Please clarify the intentions for this ReadOnly compliance > >object. > > Ack > There is an error here. > See my comment above. I think it should be MIN-ACCESS read-only and SYNTAX { active }. I do not see any other status to make sense. > >Section 12.2 Informational References > >--------------------------------------- > > > >43a) The title of this section should be > >Informative. > > Ack/Nack > > I am aware of the RFC Editor's preferences. > Unfortunately these references are only informative if you read an > understand them (and > even then not always :-), but they are informational even if you don't > read or > understand them. > I know that RFC-editor uses a tool that prefers "informative". But it is probably not mandatory. Bert Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 24 Sep 2005 10:33:56 +0000 Message-ID: <141f01c5c0f3$90e2b650$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Sat, 24 Sep 2005 11:02:24 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_13F6_01C5C0F7.717C8C10" This is a multi-part message in MIME format. ------=_NextPart_000_13F6_01C5C0F7.717C8C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joan, Thanks for the rapid convergence. In-line... Cheers, Adrian > >> 3*) Question if these documents should have a > >> contributors section. It violates the guidelines > >> of "RFC Editorial Guidelines and Procedures" > >> http://www.rfc-editor.org/policy.html#policy.auth2 > >> > >> There are many people listed under > >> Authors but not listed on the front page, > >> so how about adding a Contributors Section? > > > >Ack > >We will change the title of "Authors' Addresses" section to be = "Contact > >Details". >=20 > According to the rfc-editor website above, > this should be "Contact Information", is this what you mean? Yes, in deed. And Henrick's little tool catches this admirably. > >> draft-ietf-ccamp-gmpls-tc-mib-07.txt > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> Section 3. GMPLS Textual Conventions MIB Definitions > >> --------------------------------------------------- >=20 > >> 1) GmplsFreeformLabel TC >=20 > >> 1c) The DESCRIPTION needs a little work: > >> DESCRIPTION > >> "This value represents a freeform generalized MPLS Label. = This > >> can be used to represent label types which are not standard = in > >> the drafts. It may also be used by systems that do not wish = to > >> represent the labels using the specific label types." > >> > >> Please reword to something like: > >> > >> "This value represents a freeform GMPLS label. A freeform = GMPLS > >> label is specified by the system which uses it. In other = words, > >> the freeform GMPLS label is not a standard GMPLS label type, > >> but is created by the system which uses it." > > > >Nack > >The text as originally stated is correct and your revision is wrong. = That > >is, the freeform label MAY also be used to represent standard labels > >as octet strings. > >This is a popular way to handle the management of multiple different = types > >of labels. > > > >Will change to: > > "This value represents a freeform GMPLS Label. This can be = used > > to represent label that have label types which are not > > standardised. It may also be used by systems that do not = wish to=20 > > represent labels that have standardised label types using = the=20 > > type-specific objects in this table." >=20 > Sorry, I'm still a little foggy on what this TC is, partly because the > description is referring to "objects in this table" which is confusing > in a TC DESCRIPTION, and also the definition of the freeform label > used here and used in the GmplsGeneralizedLabelType enum seems be > defined slightly differently.=20 Good point about "objects in this table." That needs to be removed. So, the description of GmplsGeneralizedLabelTypes should be changed to = read... Determines the interpretation that should be applied to an object that encodes a label. But I don't see anything else in the GmplsGeneralizedLabelType enum that = presents any interpretation of the freeform object. > A freeform label as described in the DESCRIPTION clause > could contain the value of any GMPLS/MPLS labels,=20 > right? Right. How about... "This Textual Convention can be used as the syntax of an object that contains any GMPLS label. Objects with this syntax can be used to represent labels that have label types that are not standardised. The freeform GMPLS Label may also be used by=20 systems that do not wish to represent labels that have standardised label types using type-specific syntaxes." > >> 2) GmplsGeneralizedLabelTypes TC >=20 > >> 2b) Could the SYNTAX order be changed? > >> > >> Currently: > >> > >> SYNTAX INTEGER { > >> gmplsMplsLabel(1), > >> gmplsPortWavelengthLabel(2), > >> gmplsFreeformGeneralizedLabel(3), > >> gmplsSonetLabel(4), > >> gmplsSdhLabel(5), > >> gmplsWavebandLabel(6) > >> } > >> > >> Proposed (NOTE also some of the names have been changed): > >> > >> SYNTAX INTEGER { > >> gmplsFreeformLabelOrOther(1), > >> gmplsMplsLabel(2), > >> gmplsPortAndWavelengthLabel(3), > >> gmplsSonetLabel(4), > >> gmplsSdhLabel(5), > >> gmplsWavebandLabel(6) > >> } > > > >Nack > >i. "FreeformOrOther" What other? There is just freeform. >=20 > Aren't the label types: gmplsMplsLabel(2), > gmplsPortAndWavelengthLabel(3), > gmplsSonetLabel(4), > gmplsSdhLabel(5), > gmplsWavebandLabel(6) > also a kind of freeform GMPLS label (as indicated by the DESCRIPTION > clause in GmplsFreeformLabel)? It is all to do with the encodings of objects (i.e. the syntaxes) not = the use to which the labels can be put. Thus, a normal 20-bit MPLS label = an be encoded in an object with syntax MPLSLabel or in an object with = syntax GMPLSFreeformLabel. In the former case it is presented as an = Unsigned32. In the latter case it is presented as an OCTET STRING. > >ii. Why re-order? The new order seems to have no more logic than the > > old order. >=20 > Partly depends on the answer to above i. question. =20 > If the labels are a kind of freeform label,=20 > then a better style would be to list=20 > gmplsFreeformLabel first. Admittedly, this is a NIT. >=20 > Also, please add into the DESCRIPTION clause > a definition for each enum (an example would > be MplsLspType in RFC3811). =20 Yes. That is a good idea. Description will now read... DESCRIPTION "Determines the interpretation that should be applied to an object that encodes a label. The possible types are: gmplsMplsLabel(1) - The label is an MPLS packet, = cell, or frame label and is encoded as=20 described for the Textual = Convention MPLSLabel defined in RFC 3811. gmplsPortWavelengthLabel(2) - The label is a port or wavelength label as defined in RFC 3741. gmplsFreeformGeneralizedLabel(3) - The label is any form of label = encoded as an OCTET STRING using the = Textual Convention GMPLSFreeformLabel. gmplsSonetLabel(4) - The label is a SONET label as = defined in RFC 3946. gmplsSdhLabel(5) - The label is an SDH label as = defined in RFC 3946. gmplsWavebandLabel(6) - The label is a waveband label as = defined in RFC 3471." ------=_NextPart_000_13F6_01C5C0F7.717C8C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Joan,
 
Thanks for the rapid = convergence.
 
In-line...
 
Cheers,
Adrian
 
> >> 3*) Question if these = documents=20 should have a
> >>    contributors = section.  It=20 violates the guidelines
> >>    of "RFC = Editorial=20 Guidelines and Procedures"
> >>    http://www.rfc-editor.org/policy.html#policy.auth2> >>
> >>    = There are=20 many people listed under
> >>    Authors but = not=20 listed on the front page,
> >>    so how = about adding=20 a Contributors Section?
> >
> >Ack
> >We will = change=20 the title of "Authors' Addresses" section to be "Contact
>=20 >Details".
>
> According to the rfc-editor website=20 above,
> this should be "Contact Information", is this what you=20 mean?
 
Yes, in deed. And Henrick's little = tool catches=20 this admirably.

>=20 >> draft-ietf-ccamp-gmpls-tc-mib-07.txt
> >>=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >>
> = >> Section=20 3. GMPLS Textual Conventions MIB Definitions
> >>=20 ---------------------------------------------------
>
> = >> 1)=20 GmplsFreeformLabel TC
>
> >> 1c) The DESCRIPTION = needs a=20 little work:
> >>     = DESCRIPTION
>=20 >>        "This value = represents a=20 freeform generalized MPLS Label. This
>=20 >>         can be used to=20 represent label types which are not standard in
>=20 >>         the drafts. It = may also=20 be used by systems that do not wish to
>=20 >>         represent the = labels=20 using the specific label types."
> >>
>=20 >>      Please reword to something = like:
>=20 >>
> >>       "This = value=20 represents a freeform GMPLS label.  A freeform GMPLS
>=20 >>        label is specified by = the=20 system which uses it.  In other words,
>=20 >>        the freeform GMPLS = label is=20 not a standard GMPLS label type,
>=20 >>        but is created by the = system=20 which uses it."
> >
> >Nack
> >The text as = originally=20 stated is correct and your revision is wrong. That
> = >is, the=20 freeform label MAY also be used to represent standard = labels
> >as octet strings.
> = >This is a=20 popular way to handle the management of multiple different types
> = >of labels.
> >
> >Will change to:
>=20 >        "This value represents a = freeform=20 GMPLS Label. This can be used
>=20 >         to represent label = that=20 have label types which are not
>=20 >         standardised. It = may also=20 be used by systems that do not wish to
>=20 >         represent labels = that have=20 standardised label types using the
>=20 >         type-specific = objects in=20 this table."
>
> Sorry, I'm still a little foggy on what = this TC=20 is, partly because the
> description is referring to "objects in = this=20 table" which is confusing
> in a TC DESCRIPTION, and also the = definition=20 of the freeform label
> used here and used in the=20 GmplsGeneralizedLabelType enum seems be
> defined slightly = differently.=20
 
Good point about "objects in this = table." That=20 needs to be removed.
 
So, the description of = GmplsGeneralizedLabelTypes=20 should be changed to read...
       =20 Determines the interpretation that should be applied to=20 an
        object that encodes a=20 label.
 
But I don't see anything else in the=20 GmplsGeneralizedLabelType enum that presents any interpretation of the = freeform=20 object.

> A freeform label as described in the = DESCRIPTION=20 clause
> could contain the value of any GMPLS/MPLS labels, =
>=20 right?
 
Right.
 
How about...
  "This Textual Convention can = be used as=20 the syntax of an object
   that contains any = GMPLS label.=20 Objects with this syntax can be
   used to represent labels = that have=20 label types that are not
   standardised. The freeform = GMPLS=20 Label may also be used by
   systems that do not wish = to represent labels that = have
   standardised label types = using type-specific=20 syntaxes."
> >> 2) = GmplsGeneralizedLabelTypes =20 TC
>
> >> 2b)  Could the SYNTAX order be=20 changed?
> >>
> >>    =20 Currently:
> >>
> >>     = SYNTAX=20 INTEGER {
> >>       =20 gmplsMplsLabel(1),
> = >>       =20 gmplsPortWavelengthLabel(2),
>=20 >>       =20 gmplsFreeformGeneralizedLabel(3),
>=20 >>        = gmplsSonetLabel(4),
>=20 >>        = gmplsSdhLabel(5),
>=20 >>        = gmplsWavebandLabel(6)
>=20 >>      }
> >>
>=20 >>     Proposed (NOTE also some of the names = have been=20 changed):
> >>
> >>    SYNTAX = INTEGER=20 {
> >>       =20 gmplsFreeformLabelOrOther(1),
>=20 >>        = gmplsMplsLabel(2),
>=20 >>       =20 gmplsPortAndWavelengthLabel(3),
>=20 >>        = gmplsSonetLabel(4),
>=20 >>        = gmplsSdhLabel(5),
>=20 >>        = gmplsWavebandLabel(6)
>=20 >>      }
> >
> = >Nack
>=20 >i.  "FreeformOrOther" What other? There is just = freeform.
>=20
> Aren't the label types: gmplsMplsLabel(2),
>=20 gmplsPortAndWavelengthLabel(3),
> gmplsSonetLabel(4),
>=20 gmplsSdhLabel(5),
> gmplsWavebandLabel(6)
> also a kind of = freeform=20 GMPLS label (as indicated by the DESCRIPTION
> clause in=20 GmplsFreeformLabel)?
 
It is all to do with the encodings of = objects=20 (i.e. the syntaxes) not the use to which the labels can be put. Thus, a = normal=20 20-bit MPLS label an be encoded in an object with syntax MPLSLabel or in = an=20 object with syntax GMPLSFreeformLabel. In the former case it is = presented as an=20 Unsigned32. In the latter case it is presented as an OCTET = STRING.
 
> >ii. Why re-order? The new = order seems to=20 have no more logic than the
> >    old = order.
>=20
> Partly depends on the answer to above i. question.  =
> If=20 the labels are a kind of freeform label,
> then a better style = would be=20 to list
> gmplsFreeformLabel first.  Admittedly, this is a=20 NIT.
>
> Also, please add into the DESCRIPTION = clause
> a=20 definition for each enum (an example would
> be MplsLspType in=20 RFC3811). 
 
Yes. That is a good = idea.
 
Description will now = read...
 
 DESCRIPTION
   "Determines the = interpretation=20 that should be applied to an
    object that = encodes a=20 label. The possible types are:
 
      =20     gmplsMplsLabel(1)    =20     - The label is an MPLS packet, cell,
           &n= bsp;           &nb= sp;           &nbs= p; =20  or frame label and is encoded as
           &n= bsp;           &nb= sp;           &nbs= p;  =20 described for the Textual Convention
           &n= bsp;           &nb= sp;           &nbs= p; =20  MPLSLabel defined in RFC 3811.

   =20 gmplsPortWavelengthLabel(2)      - The label is = a port=20 or wavelength
           &n= bsp;           &nb= sp;           &nbs= p; =20  label as defined in RFC 3741.
 
    gmplsFreeformGeneralizedLabel(3) - The label is = any form=20 of label encoded
           &n= bsp;           &nb= sp;           &nbs= p;   as=20 an OCTET STRING using the Textual
           &n= bsp;           &nb= sp;           &nbs= p;  =20 Convention GMPLSFreeformLabel.

   =20 gmplsSonetLabel(4)         &= nbsp;    =20 - The label is a SONET label as defined
           &n= bsp;           &nb= sp;           &nbs= p;   in=20 RFC 3946.
   =20 gmplsSdhLabel(5)         &nb= sp;      =20 - The label is an SDH label as defined in
           &n= bsp;           &nb= sp;           &nbs= p;  =20 RFC 3946.

   =20 gmplsWavebandLabel(6)        &nbs= p;  =20 - The label is a waveband label as defined
           &n= bsp;           &nb= sp;           &nbs= p;  =20 in RFC 3471."
 
------=_NextPart_000_13F6_01C5C0F7.717C8C10-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Sep 2005 19:51:21 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-02.txt Message-Id: Date: Fri, 23 Sep 2005 15:50:01 -0400 --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 : Label Switched Path Stitching with Generalized MPLS Traffic Engineering Author(s) : A. Ayyangar, J. Vasseur Filename : draft-ietf-ccamp-lsp-stitching-02.txt Pages : 19 Date : 2005-9-23 In certain scenarios, there may be a need to combine together different Generalized Multi-Protocol Label Switching (GMPLS) Label Switched Paths (LSPs) such that in the data plane, a single end-to- end (e2e) LSP is realized and all traffic from one LSP is switched onto the other LSP. We will refer to this as "LSP stitching". This document covers cases where: a) the node performing the stitching does not require configuration of every LSP pair to be stitched together b) the node performing the stitching is not the egress of any of the LSPs c) LSP stitching not only results in an end-to-end LSP in the data plane, but there is also a corresponding end-to-end LSP (RSVP session) in the control plane. It may be possible to configure a GMPLS node to switch the traffic from an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever, completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-lsp-stitching-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-lsp-stitching-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: <2005-9-23111314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lsp-stitching-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-23111314.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Sep 2005 16:13:32 +0000 Message-Id: <3.0.1.32.20050923120504.01564e90@pop.mindspring.com> Date: Fri, 23 Sep 2005 12:05:04 -0400 To: adrian@olddog.co.uk,tnadeau@cisco.com,ccamp@ops.ietf.org From: jcucchiara@mindspring.com Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Cc: bwijnen@lucent.com,jcucchiara@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Adrian, Thank you for the quick turn around. I have removed issues where we are in agreement (both the ack'd and nack'd) and will comment only on those ones which might need further discussion (both ack'd and nack'd). Please see comments inline. thanks, Joan At 01:49 PM 9/22/05 +0100, Adrian Farrel wrote: >Hi Joan, > >Thanks again for the thorough review. > >Please see below our responses on the general comments and the TC MIB >module. > >I have indicated Ack or Nack for each point you raised. Where there is a >Nack I have indicated either our reasoning or a proposed alternate >solution. > >Cheers, >Adrian > >> General comments for all 3 drafts: >> ================================================ > >> 3*) Question if these documents should have a >> contributors section. It violates the guidelines >> of "RFC Editorial Guidelines and Procedures" >> http://www.rfc-editor.org/policy.html#policy.auth2 >> >> There are many people listed under >> Authors but not listed on the front page, >> so how about adding a Contributors Section? > >Ack >We will change the title of "Authors' Addresses" section to be "Contact >Details". >That covers all According to the rfc-editor website above, this should be "Contact Information", is this what you mean? > > >> draft-ietf-ccamp-gmpls-tc-mib-07.txt >> ====================================== >> >> Section 3. GMPLS Textual Conventions MIB Definitions >> --------------------------------------------------- >> 1) GmplsFreeformLabel TC >> >> 1c) The DESCRIPTION needs a little work: >> DESCRIPTION >> "This value represents a freeform generalized MPLS Label. This >> can be used to represent label types which are not standard in >> the drafts. It may also be used by systems that do not wish to >> represent the labels using the specific label types." >> >> Please reword to something like: >> >> "This value represents a freeform GMPLS label. A freeform GMPLS >> label is specified by the system which uses it. In other words, >> the freeform GMPLS label is not a standard GMPLS label type, >> but is created by the system which uses it." > >Nack >The text as originally stated is correct and your revision is wrong. That >is, >the freeform label MAY also be used to represent standard labels as octet >strings. >This is a popular way to handle the management of multiple different types >of >labels. > >Will change to: > "This value represents a freeform GMPLS Label. This can be used > to represent label that have label types which are not >standardised. > It may also be used by systems that do not wish to represent >labels > that have standardised label types using the type-specific >objects > in this table." > Sorry, I'm still a little foggy on what this TC is, partly because the description is referring to "objects in this table" which is confusing in a TC DESCRIPTION, and also the definition of the freeform label used here and used in the GmplsGeneralizedLabelType enum seems be defined slightly differently. A freeform label as described in the DESCRIPTION clause could contain the value of any GMPLS/MPLS labels, right? >> 2) GmplsGeneralizedLabelTypes TC >> 2b) Could the SYNTAX order be changed? >> >> Currently: >> >> SYNTAX INTEGER { >> gmplsMplsLabel(1), >> gmplsPortWavelengthLabel(2), >> gmplsFreeformGeneralizedLabel(3), >> gmplsSonetLabel(4), >> gmplsSdhLabel(5), >> gmplsWavebandLabel(6) >> } >> >> Proposed (NOTE also some of the names have been changed): >> >> SYNTAX INTEGER { >> gmplsFreeformLabelOrOther(1), >> gmplsMplsLabel(2), >> gmplsPortAndWavelengthLabel(3), >> gmplsSonetLabel(4), >> gmplsSdhLabel(5), >> gmplsWavebandLabel(6) >> } > >Nack >i. "FreeformOrOther" What other? There is just freeform. Aren't the label types: gmplsMplsLabel(2), gmplsPortAndWavelengthLabel(3), gmplsSonetLabel(4), gmplsSdhLabel(5), gmplsWavebandLabel(6) also a kind of freeform GMPLS label (as indicated by the DESCRIPTION clause in GmplsFreeformLabel)? >ii. Why re-order? The new order seems to have no more logic than the > old order. Partly depends on the answer to above i. question. If the labels are a kind of freeform label, then a better style would be to list gmplsFreeformLabel first. Admittedly, this is a NIT. Also, please add into the DESCRIPTION clause a definition for each enum (an example would be MplsLspType in RFC3811). Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Sep 2005 12:53:37 +0000 Message-ID: <133f01c5c03e$32bd2890$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: New temporary registry Date: Fri, 23 Sep 2005 13:56:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Arthi pointed out that there were some conflicts in the early assignments of Error Values for the Error Code "Routing Problem". In order to make this a bit smoother I have set up a temporary registry of pre-IANA allocations of Error Values for this Error Code at http://www.olddog.co.uk/ccamp.htm Please let me know if you see any problems or want any additions made. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Sep 2005 12:51:28 +0000 Message-ID: <133501c5c03d$ba40e3c0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Bill Fenner" , "'Kireeti Kompella'" Subject: draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt now back with AD Date: Fri, 23 Sep 2005 13:29:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex, We held a further WG last call on this I-D after updating it to Proposed Standard as you requested. No-one objected to this change, so the I-D is now back with you for approval. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Wednesday, September 07, 2005 9:48 PM Subject: Short further last call on draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > Hi, > > Alex has reviewed this I-D as AD and says it is fine, but he thinks we > should take it down the standards track as Proposed Standard not BCP as it > was previously marked. > > This revision changes: > - proposed status > - IPR boilerplate > - IANA clause to be a little more (about 10 words) detailed > > Since we have changed the proposed status, we need to check back with you > guys. > > Let's have a two week last call on this change. > > If you do spot other issues as you go, then I guess we can handle them > too. > > Last call will end 12 noon GMT on Thursday 22nd September. > > Thanks, > Adrian > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Wednesday, September 07, 2005 8:50 PM > Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > > > > 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 : Node ID based RSVP Hello: A Clarification Statement > > Author(s) : Z. Ali, et al. > > Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > > Pages : 7 > > Date : 2005-9-7 > > > > Use of Node-ID based RSVP Hello messages is implied in a number of > > cases, e.g., when data and control plan are separated, when TE links > > are unnumbered. Furthermore, when link level failure detection is > > performed by some means other than exchanging RSVP Hello messages, > > use of Node-ID based Hello session is optimal for detecting signaling > > adjacency failure for Resource reSerVation Protocol-Traffic > > Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear > > and this document formalizes use of Node-ID based RSVP Hello session > > as a best current practice (BCP) in some scenarios. The procedure > > described in this document applies to both Multi-Protocol Label > > Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > 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-rsvp-node-id-based-hello-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-rsvp-node-id-based-hello-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. > > > > > ------------------------------------------------------------------------ -- > ------ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Sep 2005 11:48:33 +0000 Message-ID: <130f01c5c034$ead335f0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada Date: Fri, 23 Sep 2005 12:44:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit FYI ----- Original Message ----- From: To: Sent: Friday, September 23, 2005 5:00 AM Subject: Internet-Drafts Submission Cutoff Dates for the 64th IETF Meeting in Vancouver, British Columbia, Canada > > There are two (2) Internet-Draft cutoff dates for the 64th > IETF Meeting in Vancouver, British Columbia, Canada: > > October 17th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > October 17th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > October 10th at 9:00 AM ET. > > October 24th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, October 24th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, November 7th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 64th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_64.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 23 Sep 2005 07:52:24 +0000 Message-ID: <051e01c5bc8e$3d00aec0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" Subject: Implementations for draft-ietf-ccamp-gmpls-segment-recovery and draft-ietf-ccamp-gmpls-recovery-e2e-signaling Date: Sun, 18 Sep 2005 14:38:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, The AD is asking Kireeti and me to supply an informal report on the status of implementations of these two I-Ds. So, please send me/Kireeti private email that will allow us to answer Alex's questions. Which features in the drafts have you implemented? Have you done any interop work? Thanks, Adrian [Alex] > > >> >> what's the implementation status for these? [Adrian] > > >> > For certain I know of two implementations of segment recovery and one of > > >> > e2e recovery. I suspect another one of each. > > >> > > > >> > Is that enough or would you like me to pursue this a bit further? [Alex] > > >> What we need at this point is that all features in the doc have been > > >> implemented and whether the implementations are known to interop. [Kireeti] > > > Do you want a formal implementation report? Or a "verbal" statement > > > from the relevant parties? [Alex] > > An e-mail from you guys would suffice. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Sep 2005 23:49:07 +0000 Message-ID: <119a01c5bf74$096235f0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Thu, 22 Sep 2005 13:49:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Joan, Thanks again for the thorough review. Please see below our responses on the general comments and the TC MIB module. I have indicated Ack or Nack for each point you raised. Where there is a Nack I have indicated either our reasoning or a proposed alternate solution. Cheers, Adrian > General comments for all 3 drafts: > ================================================ > 1*) Suggestion only: > When submitting these 3 GMPLS MIBs > you may want to ask RFC-editor > to give the GMPLS-TC-STD-MIB document the first > RFC number, and that all 3 GMPLS MIB docs appear > contiguously numbered. > > If you would like to incorporate this suggestion > then you'd need to add a paragraph to the > IANA Considerations section and put the usual > RFC-editor disclaimers around your request, such > as: > > > (Note to RFC-Editor:) > We request that you assign the first RFC number > to the draft-ietf-ccamp-gmpls-tc-mib, and also > assign contiguous numbers to all three GMPLS MIB > docs, i.e. draft-ietf-ccamp-gmpls-tc-mib, > draft-ietf-ccamp-gmpls-lsr-mib, and > draft-ietf-ccamp-gmpls-te-mib. > (Please remove this note prior to publication.) Ack > 2*) Table of Contents is incorrect, please > regenerate it, (e.g. The SNMP Management Framework > should be The Internet-Standard Management Framework). Ack > 3*) Question if these documents should have a > contributors section. It violates the guidelines > of "RFC Editorial Guidelines and Procedures" > http://www.rfc-editor.org/policy.html#policy.auth2 > > There are many people listed under > Authors but not listed on the front page, > so how about adding a Contributors Section? Ack We will change the title of "Authors' Addresses" section to be "Contact Details". That covers all > 4*) Tom's Contact info needs to be updated to > Boxborough. Ack > 5*) would be clearer to be consistent about > referring to MIB modules and always use the entire MIB name > and site the reference: > e.g. MPLS LSR MIB module or LSR MIB module, > should be MPLS-LSR-STD-MIB module [RFC3813] > > e.g. GMPLS LSR MIB module, should be > GMPLS-LSR-STD-MIB module [RFCXXX] (NOTE to RFC-Editor: > please fill in XXX with the RFC name for > draft-ietf-ccamp-gmpls-lsr-mib and remove this note.) Ack > 6*) The term "extends" is used and since this term is applied > to GMPLS interfaces, the more appropriate phrase is > 'sparse augments'. Please change this in the text. Ack > 7*) ORGANIZATION, please add IETF > as in "IETF Common Control and ...." Ack > 8*) DESCRIPTION > Please change the first paragraph to: > > Copyright (C) The Internet Society (2005). This version of > this MIB module is part of RFC XXX; see the RFC itself for > full legal notices. > > The exception to this is the IANA-GMPLS-MIB module, which should > include: > > "Copyright (C) The Internet Society (2005). The initial version > of this MIB module was published in RFC XXXX. For full legal > notices see the RFC itself. Supplementary information > may be available on: > http://www.ietf.org/copyrights/ianamib.html Ack > 9*) Please make sure to ask RFC-Editor to remove comments > prior to publication, e.g. > > -- RFC Editor's Note (to be removed prior to publication): > > "Initial version published as part of RFC XXXX." > -- replace XXX with actual RFC number & remove this note. Ack > 10*) Acknowledgements Section > Please start off this section with: > > This document is a product of the CCAMP Working Group. > > and remove: > > This draft is the work of the five authors listed in the next > section. Ack > 11*) Please change "Informational References" > to "Informative References" Bleagh Ack > 12*) There are a number of references (as discovered by > Bert) that aren't in the RFC expected format. > Please review all the references in this document and > the other GMPLS MIB docs. > Please see comments in the review of the > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > examples of references in the RFC format. Ack > draft-ietf-ccamp-gmpls-tc-mib-07.txt > ====================================== > > Section 3. GMPLS Textual Conventions MIB Definitions > --------------------------------------------------- > > 1) GmplsFreeformLabel TC > > 1a) Could the REFERENCE include section(s)? > I suspect that this is referring to the Generalized Label > described in section 3.2.1, is this correct? Ack All of the labels are Generalized Labels! > 1b) Please explain why this is 0..64 ? > RFC3471 states that the Generalized label can be > variable length, so wondering if this should be made > larger? Nack 64 is safely larger than will ever be used. > 1c) The DESCRIPTION needs a little work: > DESCRIPTION > "This value represents a freeform generalized MPLS Label. This > can be used to represent label types which are not standard in > the drafts. It may also be used by systems that do not wish to > represent the labels using the specific label types." > > Please reword to something like: > > "This value represents a freeform GMPLS label. A freeform GMPLS > label is specified by the system which uses it. In other words, > the freeform GMPLS label is not a standard GMPLS label type, > but is created by the system which uses it." Nack The text as originally stated is correct and your revision is wrong. That is, the freeform label MAY also be used to represent standard labels as octet strings. This is a popular way to handle the management of multiple different types of labels. Will change to: "This value represents a freeform GMPLS Label. This can be used to represent label that have label types which are not standardised. It may also be used by systems that do not wish to represent labels that have standardised label types using the type-specific objects in this table." > 2) GmplsGeneralizedLabelTypes TC > > 2a) Could you change the name of the TC > GmplsGeneralizedLabelTypes to > > GmplsLabelType > > It is more appropriate to have it singular when > Imported and used in other MIBs, and dropping the > word Generalized, because you already have the > prefix Gmpls. Ack > 2b) Could the SYNTAX order be changed? > > Currently: > > SYNTAX INTEGER { > gmplsMplsLabel(1), > gmplsPortWavelengthLabel(2), > gmplsFreeformGeneralizedLabel(3), > gmplsSonetLabel(4), > gmplsSdhLabel(5), > gmplsWavebandLabel(6) > } > > Proposed (NOTE also some of the names have been changed): > > SYNTAX INTEGER { > gmplsFreeformLabelOrOther(1), > gmplsMplsLabel(2), > gmplsPortAndWavelengthLabel(3), > gmplsSonetLabel(4), > gmplsSdhLabel(5), > gmplsWavebandLabel(6) > } Nack i. "FreeformOrOther" What other? There is just freeform. ii. Why re-order? The new order seems to have no more logic than the old order. > Section 4. Security Considerations > ------------------------------------- > > 3) Change MPLS to GMPLS in the following statement: > > "This module does not define any management objects. Instead, it > defines a set of textual conventions which may be used by other MPLS > MIB modules to define management objects." Ack > Section 5. IANA Considerations > ------------------------------------- > > 4) Section 5. IANA Considerations > RFC Editor's Note (to be removed prior to publication): > the IANA is requested to assign a value for "XXX" under > the mib-2/mplsStdMIB subtree and to record the assignment > in the SMI Numbers registry. > When the assignment has been made, the RFC Editor is > asked to replace the "XXX" (here and in the MIB module) with > the assigned value and to remove this note. Ack > 5) Section 5. IANA Considerations > > Please remove the last sentence of this section: > > "The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB." Ack > Section 6.2 Informational References. > --------------------------------------- > > 6) Section 6.2 Informational References. > Please change to "Informative". Grrrrrr. Ack > 7) I believe the following references should be moved > to the Normative section: > > [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), > "Generalized MPLS Signaling - CR-LDP Extensions", > RFC 3472, January 2003. Nack In fact not referenced and should be deleted. > [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - > RSVP-TE Extensions", RFC 3473 January 2003. Nack In fact not referenced and should be deleted. > [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual > Conventions and for Multiprotocol Label Switching > (MPLS) Management", RFC 3811, June 2004. Ack > [RFC3945] Mannie, E. (Editor), "Generalized Multiprotocol > Label Switching (GMPLS) Architecture", RFC 3945, > October 2004. Ack > [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), > "Generalized Multi-Protocol Label Switching > Extensions for SONET and SDH Control", > draft-ietf-ccamp-gmpls-sonet-sdh, work in progress. > > (the above is now RFC 3946) > [GMPLS-SONET] Mannie, E. and D. Papadimitriou, "Generalized Multi- > Protocol Label Switching (GMPLS) Extensions for > Synchronous Optical Network (SONET) and Synchronous > Digital Hierarchy (SDH) Control", RFC 3946, October > 2004. Nack In fact not referenced and should be deleted. > Also, as previously mentioned, need to check > on the format of these References. > Please see comments in the review of the > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > examples of references in the RFC format. Ack Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Sep 2005 23:38:31 +0000 Message-ID: <119b01c5bf74$daed3f20$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , Subject: Re: review of draft-ietf-ccamp-lsr-mib-08.txt Date: Thu, 22 Sep 2005 13:55:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi again Joan, This is the response to your excellent review of the GMPLS LSR MIB module. As before, I have indicated Ack or Nack for each point you raised. Where there is a Nack I have indicated either our reasoning or a proposed alternate solution. Feel free to snip in any response you send. Once we have closure on a few remaining issues we will respin applying David's comments on the TE MIB here as well. Cheers, Adrian >Section 1.1 Migration Strategy >-------------------------------- > >1) Does the following statement refer to the >GMPLS LSR MIB module? > > "The GMPLS Label MIB module may be referenced using a row pointer from > objects within the LSR MIB module." > ^^^^ >As previously mentioned, using the entire MIB module name >would be clearer. Ack >Section 4. Outline >--------------------- > >2) Need to clarify the phrase "this MIB module" because >there are 2 MIB modules in this document. > > > "- Enabling GMPLS on GMPLS capable interfaces using this MIB module." > >(which is referring to the GMPLS-LSR-STD-MIB module??) > >... > > "- Optionally setting up labels in the label table in this MIB module > if the textual convention MplsLabel is not capable of holding the > required label (for example, if the label requires more than 32 > bits to encode it), or if the operator wishes to disambiguate > GMPLS label types." > >The phrase, "in this MIB module", needs to be clarified since there >are 2 mib modules in this document. Here, I think you are >referring to the GMPLS-LABEL-STD-MIB, but prior to this you use >a similar phrase and are referring the the GMPLS-LSR-STD-MIB. >Please consistently specify the MIB modules by using their >names. Ack. >3) Please move section, 4.1 MIB Modules to section 1.1, Migration >Strategy. There is much overlap in these 2 sections so please >combine them. Ack >Section 4.1.2 Summary of GMPLS Label MIB Module >------------------------------------------------- > >4) "Generalized Labels can be of variable length and have distinct > bit-by-bit interpretations according to the use that is made of > them." > >Please change the above to: > > "Generalized Labels can be of variable length and have distinct > bit-by-bit interpretations depending upon how they are defined > by the specific service provider." Nack. Nothing to do with the service provider. Will change to: "Generalized Labels can be of variable length and have distinct bit-by-bit interpretations depending upon how they are defined for the specific technology in which they are used. For example, labels used for MPLS packet switching are different in length and content from labels used in TDM timeslot switching." >5) Same section, 4.1.2 Summary of GMPLS Label MIB Module > >Please remove this last sentence: > > These tables are described in the subsequent sections. Ack. >6) "This MIB module..." > >Please clarify which MIB module, i.e. The GMPLS-LSR-STD-MIB module Ack >7) Please specifically call out which term you will be using in >this document. Beginning with the 3rd paragraph, there is much >terminology, so please add some statement such as: > >"In this document, the terms 'forward' and 'reverse' will be used. Ack >Section 6. Example of LSP Setup >------------------------------- > >8) First and second sentences: > "In this section we provide a brief example of using the MIB objects > described in sections 7 and 8 to set up an LSP. While this example is > not meant to illustrate every nuance of the MIB, it is intended as an > aid to understanding some of the key concepts..." > >The phrase, "every nuance of the MIB" should probably be >"every nuance of the MIB modules" since you are referring to both >of the MIB modules (sections 7 and 8). Ack >9) Typo: gmplsLableTable Ack >10) Typo: accesible (in several places) Ack >Section 7. GMPLS-LSR-STD-MIB >====================== > >11) smicngpro gives the following: > >E: f(GMPLS-LSR-STD-MIB), (315,8) Item "ifGeneralInformationGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (316,8) Item "ifCounterDiscontinuityGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (322,8) Item "mplsInterfaceGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (323,8) Item "mplsInSegmentGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (324,8) Item "mplsOutSegmentGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (325,8) Item "mplsXCGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (326,8) Item "mplsPerfGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (327,8) Item "mplsLsrNotificationGroup" should be IMPORTed >W: f(GMPLS-LSR-STD-MIB), (358,18) For "gmplsOutSegmentTTLDecrement", syntax is identical >E: f(GMPLS-LSR-STD-MIB), (378,8) Item "ifGeneralInformationGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (379,8) Item "ifCounterDiscontinuityGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (385,8) Item "mplsInterfaceGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (386,8) Item "mplsInSegmentGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (387,8) Item "mplsOutSegmentGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (388,8) Item "mplsXCGroup" should be IMPORTed >E: f(GMPLS-LSR-STD-MIB), (389,8) Item "mplsPerfGroup" should be IMPORTed >W: f(GMPLS-LSR-STD-MIB), (404,14) For "gmplsInterfaceSignalingCaps", syntax is identical >W: f(GMPLS-LSR-STD-MIB), (415,18) For "gmplsInterfaceRsvpHelloPeriod", syntax is identical >W: f(GMPLS-LSR-STD-MIB), (431,18) For "gmplsInSegmentExtraParamsPtr", syntax is identical >W: f(GMPLS-LSR-STD-MIB), (447,18) For "gmplsOutSegmentTTLDecrement", syntax is identical >W: f(GMPLS-LSR-STD-MIB), (454,18) For "gmplsOutSegmentExtraParamsPtr", syntax is identical > > >Please correct the above. > >Also, please change the following 2 statements (which appear twice) >to remove the SYNTAX, since this is redundant, unless there is >a reason why you prefer to leave it. > > OBJECT gmplsInSegmentDirection > SYNTAX GmplsSegmentDirection > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required. Only forward(1) needs to be > supported by implementations that only support unidirectional > LSPs." > > > OBJECT gmplsOutSegmentDirection > SYNTAX GmplsSegmentDirection > MIN-ACCESS read-only > DESCRIPTION > "Write access is not required. Only forward(1) needs to be > supported by implementations that only support unidirectional > LSPs." > >Compiles cleanly with smilint. Ack. (I wish smilint caught the other errors.) >12) DESCRIPTION > Please change the first paragraph to (this comment applies to > the other MIB modules also.) > > Copyright (C) The Internet Society (2005). This version of > this MIB module is part of RFC XXX; see the RFC itself for > full legal notices. Ack >13) Change the following: > > GmplsSegmentDirection > FROM GMPLS-TC-STD-MIB -- GMPLSTCMIB > -- RFC-Editor please resolve the reference above > >TO: > > GmplsSegmentDirection > FROM GMPLS-TC-STD-MIB -- RFCXXXX > -- RFC-Editor please resolve the reference above > -- and remove this note. Ack >14) Please remove: > > -- Notifications > -- no notifications are currently defined. > gmplsLsrNotifications OBJECT IDENTIFIER ::= { gmplsLsrStdMIB 0 } > >(You don't need to change any numbering, but no sense defining >a number you don't need). Ack >15) Please remove comments such as (this request is made > for all MIB modules in all 3 documents): > -- Top level components of this MIB module. > -- Tables, Scalars > -- Conformance > -- GMPLS Interface Table. > > -- End of gmplsInterfaceTable > > -- In-segment table. > >etc. Ack >16) gmplsInterfaceEntry OBJECT-TYPE > > "A conceptual row in this table is created automatically by an > LSR for every interface capable of supporting GMPLS and which > is configured to do so." > >Please change first sentence: > > "A conceptual row in this table is created automatically by an > LSR when the interface is capable of supporting GMPLS and is > correctly configured to do so." Nack Agree original is not perfect, but replacement says "the interface" without specifying which interface. Will change to: "A conceptual row in this table is created automatically by an LSR for each interface that is both capable of supporting GMPLS and that is configured to support GMPLS." > .... > >Please change the first sentence of the last paragraph: > > "The indexing is the same as that for mplsInterfaceTable." > >to: > > "The indexing is the same as the mplsInterfaceTable." Nack. Will change to: "The indexes are the same as for the mplsInterfaceTable." >17) object: gmplsInterfaceSignalingCaps OBJECT-TYPE > > SYNTAX BITS { > unknown (0), > rsvpGmpls (1), > crldpGmpls (2), -- note the use of CR-LDP is deprecated > otherGmpls (3) > } > > >What is otherGmpls(3)?? Nack I'm embarrassed to say that there are other "GMPLS" signaling protocol variants that have been developed outside the IETF. This was added in response to a WG request. >Also, this description is confusing. How can unknown(0) and >rsvpGmpls(1) be set simultaneously? Ack Will add: ...but if unknown(0) is set, no other bit may be set. >Additionally, how can no bits be set? If this is a GMPLS interface, >then doesn't one of these bits HAVE to be set? Ack As it says... Setting no bits implies that GMPLS signaling cannot be performed on this interface and all LSPs must be manually provisioned or that this table entry is only present to supplement an entry in the mplsInterfaceTable by providing the information carried in other objects in this row. This means that we should change gmplsInterfaceEntry to read: "A conceptual row in this table is created automatically by an LSR for each interface that is both capable of supporting GMPLS and that is configured to support GMPLS. Note that support of GMPLS is not limited to control plane signaling, but may include data-plane only function configured through SNMP SET commands performed on this MIB module. A conceptual row in this table may also be created via SNMP SET commands or automatically by the LSR to supplement a conceptual row in the mplsInterfaceTable where the interface is not capable of GMPLS but where the other objects carried in this row provide useful additional information for an MPLS interface." >18) gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE > "Period, in milliseconds, between sending RSVP Hello messages on > this interface. A value of 0 indicates that no Hello messages > should be sent on this interface." > >This object is only valid if the gmplsInterfaceSignalingCaps >object is set to rsvpGmpls. Please update the description >to reflect that. Nack It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB). We can add: This object is not valid if gmplsInterfaceSignalingCaps is set to crldpGmpls (2) >19) gmplsInSegmentEntry OBJECT-TYPE > "An entry in this table extends the representation of an incoming > segment represented by an entry in mplsInSegmentTable. An entry > can be created by a network administrator or an SNMP agent, or a > GMPLS signaling protocol. > >Please use the phrase: "via SNMP SET commands to create an entry" >in place of "SNMP agent". Ack >20) same entry, gmplsInSegmentEntry > > Note that the storage type for this entry SHOULD be inherited > from the corresponding entry in the mplsInSegmentTable given by > the value of the mplsInSegmentStorageType object." > >Please change to: > >Note that the storage type for this entry is given by the value >of mplsInSegmentStorageType in the corresponding entry of the >mplsInSegmentTable. Ack >21) gmplsInSegmentDirection OBJECT-TYPE > >Please use "corresponding" instead of "associated" Ack >22) gmplsInSegmentExtraParamsPtr OBJECT-TYPE > SYNTAX RowPointer > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Some Tunnels will run over transports that can usefully support > technology-specific additional parameters (for example, SONET > resource usage). Such can be supplied from an external table and > referenced from here. A value of zeroDotzero in this attribute > indicates that there is no such additional information." > DEFVAL { zeroDotZero } > ::= { gmplsInSegmentEntry 2 } > >What is meant by "external table"? If this is an enterprise-specific >table, then is it necessary to have this object in the MIB. In other >words, why is this MIB dictating that a row-pointer be used when >an enterprise-specific MIB may which to simply use indices. > >I think this object is unnecessary, but maybe I don't understand >something. Nack rowPointers are typically used when there may be a many-to-one mapping. This is appropriate for traffic parameters because there may be a few service categories defined in a traffic parameters table, and multiple LSPs may use those parameters. Compare with mplsInSegmentTrafficParamPtr in RFC3813. Now, in this case no such traffic parameters table has been supplied. To some extent we are guilty of future-proofing. We are aware that such tables will need to be added for TDM (quite soon), for lambda (possibly), and for Ethernet (almost certainly). Although it would be possible to leave this out, we feel that the necessary single-object extension that would need to be created later would be messy. >23) gmplsOutSegmentEntry OBJECT-TYPE >Same comments as with gmplsInSegmentEntry Nack Same answer >24) gmplsOutSegmentDirection OBJECT-TYPE >Same comment as with gmplsInSegmentDirection Ack >25) gmplsOutSegmentTTLDecrement OBJECT-TYPE > > "This object indicates the amount by which to decrement the TTL > of any payload packets forwarded on this segment if per-hop > decrementing is being done. > >Please change above to: > >This object indicates the amount to decrement the TTL... Nack If we want to be picky, even Webster doesn't recognise "decrement" as a verb. But this is a particularly useful verbization that is is common usage. But I also believe in the use of prepositions. So no change. >26) same object's gmplsOutSegmentTTLDecrement OBJECT-TYPE > > A value of zero indicates that no decrement should be made or > that per-hop decrementing is not in force. > >Please change: in force to enforced. Nack Will change to "in use" >27) gmplsOutSegmentExtraParamsPtr OBJECT-TYPE > >Same comment as with gmplsInSegmentExtraParamsPtr Nack Same answer >28) Compliance Statements > >I believe that gmplsInSegmentExtraParamsPtr and >gmplsOutSegmentExtraParamsPtr do not need to be >supported, so these maybe should be optional. Ack >Section 8. GMPLS-LABEL-STD-MIB >=================================== >smicngPRO gives the following: > >E: f(GMPLS-LABEL-STD-MIB), (21,13) Module "MPLS-TC-STD-MIB" has already been specified in IMPORTS clause Ack >E: f(GMPLS-LABEL-STD-MIB), (481,12) Group "gmplsLabelTableGroup" is both a MANDATORY and conditional group for module "GMPLS-LABEL-STD-MIB" Ack >Compiles cleanly with smilint. > >Also, disconnect in the numbering of the >gmplsLabelTable: > > | \-v-1 gmplsLabelInterface, name "InterfaceIndexOrZero", na, current > | |-2 gmplsLabelIndex, Unsigned32(0..4294967295), na, current > | |-3 gmplsLabelSubindex, Unsigned32(0..4294967295), na, current > | |-4 gmplsLabelType, name "GmplsGeneralizedLabelTypes", rc, current > >---> 5 is missing Ack >29) DESCRIPTION > Please change the first paragraph to (this comment applies to > the other MIB modules also.) > > Copyright (C) The Internet Society (2005). This version of > this MIB module is part of RFC XXX; see the RFC itself for > full legal notices. Ack >30) Please remove these statements (don't need to change any numbers). > > -- Notifications > -- no notifications are currently defined. > gmplsLabelNotifications OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 0 } Ack >31) gmplsLabelTable OBJECT-TYPE > >The last part of the last paragraph is awkward: > > "... Labels in the tables in other MIBs are referred to using > row pointer into this table. The indexing of this table provides > for arbitrary indexing and also for concatenation of labels." > >Are you saying that other MIBs can use a row pointer to point to >this table? Why would they do that if they could just use the >indices directly? Also, I don't follow the comment about >concatenation of labels. Could you explain this? Nack Yes we are saying that other MIB modules can use a row pointer to point to this table. Yes they could use indices. This was the subject of a very lengthy discussion between the co-authors, etc., but in the end we observed that mplsInSegmentLabelPtr and mplsOutSegmentLabelPtr (RFC3813) are rowPointers so we had better support being pointed to. We could soften the language here by replacing "are" with "may". Note, we should change this to say "MIB modules" For an example of label concatenation see RFC3945 section 7.1. In essence, a GMPLS label may be composite in order to identify a set of resources in the data plane. Practial examples are timeslots and wavelength sets (which are not contiguous like wavebands). The indexing mechanism allows multiple entries in this table to be seen as a sequence of labels that should be concatenated. Ordering is potentially very sensitive for concatenation. I don't believe we need to add text or references for concatenated labels since they are part of the architecture. >32) gmplsLabelEntry OBJECT-TYPE > >The last sentence of the DESCRIPTION, please remove >the word "more" from the phrase "is more persistent." Nack. The Textual Convention gives us degrees. That is, 'readOnly' is more durable than 'permanent' which is more durable than 'nonNolatile' which is more durable than 'volatile'. We need to convey that there is a ranked inheritance. "Persistence" is acceptable in a comparative. >I still don't understand how the subindex provides a way >to concatenate the labels. Could you give an example? Nack If you are asking for an example in the I-D, I don't think it is necessary. For your information, the composite label {{A}, {B}, {C}} might be constructed as... gmplsLabelInterface = 1 gmplsLabelIndex = 1 gmplsLabelSubindex = 1 gmplsLabelFreeform = A gmplsLabelInterface = 1 gmplsLabelIndex = 1 gmplsLabelSubindex = 2 gmplsLabelFreeform = B gmplsLabelInterface = 1 gmplsLabelIndex = 1 gmplsLabelSubindex = 3 gmplsLabelFreeform = C >33) please switch RowStatus and StorageType (this will >more closely match the other MPLS MIBs). Ack >34) gmplsLabelInterface OBJECT-TYPE > >DESCRIPTION also needs to specify that zero may be >used to indicate that the InterfaceIndex is not known >or that an InterfaceIndex exists but it is not important >wrt this implementation so zero is used. Nack The use of zero is very precisely specified at the moment. The reasons for setting zero that you cite are: - the InterfaceIndex is not known You cannot have a per-interface label space without knowing the interface to which it applies. - InterfaceIndex exists but it is not important wrt this implementation That is exactly the case of the global label space, and is already stated. >35) gmplsLabelIndex OBJECT-TYPE > SYNTAX Unsigned32 (0..4294967295) > >36a) I was expecting the SYNTAX to be IndexInteger due >to the gmplsLabelIndexNext in the DESCRIPTION. >Please explain why the use of zero is needed. You >explain the use of zero in the gmplsLabelInterface >and gmplsLabelSubindex indices. Nack This is explained by the paragraph: Note that implementations that are representing 32 bit labels within this table MAY choose to align this index with the value of the label, but should be aware of the implications of sparsely populated tables. We believe it would be inappropriate to use IndexInteger to have greater meaning than just an index. But anyway, IndexInteger is Unsigned32 (1..4294967295) and the quoted paragraph must allow zero as well. >36b)Please change the "may" to "should" in this statement: > A management application may read the gmplsLabelIndexNext > object to find a suitable value for this object." Nack Why "should" it do this? This is a convenience offered to it. It may use any mechanism it chooses including the one suggested in the quoted paragraph above. >37) gmplsLabelType OBJECT-TYPE > > of gmplsMplsLabel (1) denotes that a 23 bit MPLS packet label is > present, but does not describe whether this is signaled using > MPLS or GMPLS. > >Is this 23 bit value correct? Is this a FrameRelay DLCI label? Ack This is terrible text! Yes. 23 bits is FrameRelay. This text should be much more expansive allowing a 20 bit MPLS label, a 10 or 23 bit FR label, or a 28 bit ATM label. It should also refer to the gmplsLabelMplsLabel object. >38) gmplsLabelRowStatus OBJECT-TYPE >MUST explain which columns must be properly configured >before the row can be made active (as per RFC2579) Ack >39) Please clarify in the DESCRIPTION of each of >the following groups, if the group is optional >or needs to be supported by such implementations: > GROUP gmplsLabelPacketGroup > DESCRIPTION > "This group extends gmplsLabelTableGroup for implementations that > support packet labels." > > GROUP gmplsLabelPortWavelengthGroup > DESCRIPTION > "This group extends gmplsLabelTableGroup for implementations that > support port and wavelength labels." > > GROUP gmplsLabelFreeformGroup > DESCRIPTION > "This group extends gmplsLabelTableGroup for implementations that > support freeform labels." > > GROUP gmplsLabelSonetSdhGroup > DESCRIPTION > "This group extends gmplsLabelTableGroup for implementations that > support SONET or SDH labels." > > GROUP gmplsLabelWavebandGroup > DESCRIPTION > "This group extends gmplsLabelTableGroup for implementations that > support Waveband labels." Ack >40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE > >Please change the name to: gmplsLabelModuleReadOnlyCompliance >to be consistent with the other MPLS and GMPLS MIB modules. Nack I thought we tried to keep names down to 32 characters. I recall this conversation before. Not mandatory, but desirable. A choice between two desires? >41) The ReadOnly compliance for gmplsLabelRowStatus >does NOT have a MIN-ACCESS of read-only. Is this >intentional? ??? Not sure about this. I thought the present of a WRITE-SYNTAX made some difference. >42) Also, (related to the above) > OBJECT gmplsLabelRowStatus > SYNTAX RowStatus { > active(1), > notInService(2) > } > > WRITE-SYNTAX RowStatus { > active(1), > notInService(2), > createAndGo(4), > destroy(6) > } > DESCRIPTION > "Support for notInService, createAndWait and notReady is not > required." > >The DESCRIPTION clause conflicts with the WRITE-SYNTAX. >Please clarify the intentions for this ReadOnly compliance >object. Ack There is an error here. >Section 12.2 Informational References >--------------------------------------- > >43a) The title of this section should be >Informative. Ack/Nack I am aware of the RFC Editor's preferences. Unfortunately these references are only informative if you read an understand them (and even then not always :-), but they are informational even if you don't read or understand them. >43b) Please move the following from >Informative to Normative. > > [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol > Label Switching (GMPLS) Signaling Functional > Description", RFC 3471, January 2003. > > [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), > "Generalized MPLS Signaling - CR-LDP Extensions", > RFC 3472, January 2003. > > [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - > RSVP-TE Extensions", RFC 3473 January 2003. > > [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), > "Generalized Multi-Protocol Label Switching > Extensions for SONET and SDH Control", > draft-ietf-ccamp-gmpls-sonet-sdh, work in progress. Ack. >43c) The above reference now appears to be RFC 3946. > >Please change the above (NOTE also the changes in the >reference itself, more on the Reference format next): > > [GMPLS-SONET] Mannie, E. and D. Papadimitriou, "Generalized Multi- > Protocol Label Switching (GMPLS) Extensions for > Synchronous Optical Network (SONET) and Synchronous > Digital Hierarchy (SDH) Control", RFC 3946, October > 2004. Ack. My how time flies. >44) There are a number of references (as discovered by >Bert) that aren't in the RFC expected format. >Please review all the references in this document and >the other GMPLS MIB docs. > >Here are some to change. One suggestion is to copy a reference >(if possible) from an existing RFC. Sometimes a date is missing >and sometimes the authors/editors names do not appear as >expected. Also, titles need to appear exactly as on >the RFC. Please check the other GMPLS docs also. >(NOTE: see also draft-rfc-editor-rfc2223bis-08.txt) Ack >Please change: > [RFC2026] S. Bradner, "The Internet Standards Process -- > Revision 3", RFC 2026, October 1996. > >to: > > [RFC2026] Bradner, S., "The Internet Standards Process -- > Revision 3," BCP 9, RFC 2026, October 1996. > >Please change: > > [RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces > Group MIB", RFC 2863, June 2000. > >to (author name misspelled): > > [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group > MIB", RFC 2863, June 2000. > >Please change: > > [RFC3032] Rosen, E. et al, "MPLS Label Stack Encoding", > RFC 3032, January 2001. > >to: > > [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., > Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack > Encoding", RFC 3032, January 2001. > > >Please change: > > [RFC3212] Jamoussi, B., Aboul-Magd, O., Andersson, L., > Ashwood-Smith, P., Hellstrand, F., Sundell, K., > Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, > T., Feldman, N., Fredette, A., Girish, M., Gray, > E., Halpern, J., Heinanen, J., Kilty, T., Malis, > A., and P. Vaananen, "Constraint-Based LSP Setup > using LDP", RFC 3212, December 2001." > >to: > > [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., > Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., > Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. > Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, > January 2002. > > >Please change: > > [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An > Architecture for Describing Simple Network > Management Protocol (SNMP) Management Frameworks", > RFC 3411, December 2002. > >to: > [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An > Architecture for Describing Simple Network > Management Protocol (SNMP) Management > Frameworks", STD 62, RFC 3411, December 2002. > >Please change: > > [RFC3413] Levi, D., Meyer, P., Stewart, B., "SNMP > Applications", RFC 3413, December 2002. >to: > [RFC3413] Levi, D., Meyers, P. and B. Stewart, "Simple Network > Management Protocol (SNMP) Applications", STD 62, RFC > 3413, December 2002. > > >Please change: > [RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) > Processing in Multi-Protocol Label Switching > (MPLS) Networks", RFC 3443, January 2003. > >to: > [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) > Processing in Multi-Protocol Label Switching > (MPLS) Networks", RFC 3443, January 2003. > > >Please change: > [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol > Label Switching (GMPLS) Signaling Functional > Description", RFC 3471, January 2003. > > >to: > [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol > Label Switching (GMPLS) Signaling Functional > Description", RFC 3471, January 2003. > > >Please change: > > [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), > "Generalized MPLS Signaling - CR-LDP Extensions", > RFC 3472, January 2003. > >to: > [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, > "Generalized Multi-Protocol Label > Switching (GMPLS) Signaling Constraint-based > Routed Label Distribution Protocol (CR-LDP) > Extensions", RFC 3472, January 2003. > >Please change: > > [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - > RSVP-TE Extensions", RFC 3473 January 2003. > >to: > [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol > Label Switching (GMPLS) Signaling - Resource > ReserVation Protocol-Traffic Engineering (RSVP-TE) > Extensions", RFC 3473, January 2003. Ack Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Sep 2005 23:37:58 +0000 Message-ID: <11aa01c5bf75$b2750720$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , Cc: , Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Date: Thu, 22 Sep 2005 13:59:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Joan, Last but not least, the GMPLS TE MIB module. > Here are some comments on draft-ietf-ccamp-gmpls-te-mib-09.txt. > All 3 docs show a good deal of work. Yes, but fortunatley most of the work appears to be editorial with only very minor changes to the basis of the module. Please find acks and nacks in line below. We will also include the comments made by David and Tom Petch. Cheers, Adrian > Section 1.1 Migration Strategy > ------------------------------ > > 1) Please remove "and OBJECT-IDENTIFIERS" > > Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] > and [GMPLSTCMIB]. Ack > Section 5.4 gmplsTunnelCHoptable > --------------------------------- > > 2) Please capitalize Table in the Section's title. Ack > Section 8. GMPLS Traffic Engineering MIB Module > ----------------------------------------------- > > smicngPRO gives the following: > > W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should have > SIZE specified Ack Understood this to be optional, but planning to add size as per David's comments > W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is > identical > W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is > identical > W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is > identical > W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax is > identical > W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", syntax > is identical Nack Meaningless warning message. Cannot fix without explanation. > Disconnect of numbering in the Conformance Section > \-3 gmplsTeConformance > \-v-1 gmplsTeGroups > | \-v-1 gmplsTunnelGroup > > 2 is missing Ack > 3) gmplsTunnelsConfigured OBJECT-TYPE > SYNTAX Unsigned32 > > SYNTAX should be Gauge32 Ack > 4) gmplsTunnelsActive OBJECT-TYPE > SYNTAX Unsigned32 > > SYNTAX should be Gauge32 Ack > 5) gmplsTunnelTable > > DESCRIPTION > > "The row status of an entry in this table is controlled by > mplsTunnelRowStatus in the corresponding entry in > mplsTunnelTable. That is, it is not permitted to create a row in > this table, nor to modify an existing row, when the > corresponding mplsTunnelRowStatus has value active(1).... > > The sentence beginning with "That is," is awkward. Could you say > something like: A row in this table is created when a row is created > in the mplsTunnelTable. Entries in this table cannot be modified > when the corresponding mplsTunnelRowStatus has a value of active(1). > The exception.... > > Please also update this other places in this MIB (e.g gmplsTunnelHopTable). Nack "A row in this table is created when a row is created in the mplsTunnelTable" is false. Will attempt to reword to make this clearer. > 6) gmplsTunnelEntry > DESCRIPTION: > "... > An entry can be created by a network administrator or by an SNMP > agent as instructed by a signaling protocol." > > Please change the above to: > > "An entry can be created by a network administrator via SNMP SET commands, or > by the network management entity as instructed by a signaling > protocol." Nack "network management entity" implies a remote entity such as an NMS. Will change to: "An entry can be created by a network administrator via SNMP SET commands, or in response to signaling protocol events." > 7) gmplsTunnelUnnumIf > > What IF-MIB object are referring to in the DESCRIPTION? > Could you state which object in the description? Ack An entry in ifTable. > 8) gmplsTunnelAttributes > Could you specify what happens when the bit is set (i.e. 1) > vs. 0? Ack Don't want to restate the protocol I-D, so this text will simply replace "This flag indicates that" with "This flag is set to indicate that" > 9) gmplsTunnelLSPEncoding > > The DESCRIPTION states: > ...A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling is > not in use. Some objects in this MIB module may be of use for > MPLS signaling extensions that do not use GMPLS signaling. By > setting this object to 'tunnelLspNotGmpls', an application may > indicate that only those objects meaningful in MPLS should be > examined.... > > I believe that such objects should be put in to an MPLS MIB module > and not included in this GMPLS MIB module. This is also true with > the gmplsTunnelErrorTable. Nack We strongly disagree with any implication that MPLS and GMPLS should be separated in this way. GMPLS protocol extensions are likely to be moved into MPLS implementations piecemeal and there is no clear separation that you imply. The G in GMPLS stands for "generalized". Can you please indicate whether this is a sticking point for you. > 10) gmplsTunnelLinkProtection > Same comment as with gmplsTunnelAttributes. Ack Same answer. > 11) gmplsTunnelPathComp > > DESCRIPTION states: > This object deprecates mplsTunnelHopEntryPathComp." > > The term "deprecates" is loaded. Perhaps something like, > this object takes precedence over mplsTunnelHopEntryPathComp. > In other words, for GMPLS tunnels, the value of > mplsTunnelHopEntryPathComp is meaningless. Ack > 12) gmplsTunnelUpNotRecip > > Need to use InetAddressType and InetAddress. IpAddress > is not used in MIBs anymore. Please be sure to support > both v4 and v6 IP address Types. If you can't support > v6 for some reason, that should be stated clearly. Ack per exchange with David. > Please change the name of this object to: > gmplsTunnelUpstreamRecipientForNotify Nack We are trying to keep to the (mythical?) 32 character limit. How about: gmplsTunnelUpNotifyRecipient > 13) gmplsTunnelDownNotRecip > Same comment as above wrt to IpAddress. Ack > Please change the name to gmplsTunnelDownstreamRecipientForNotify Nack as above How about: gmplsTunnelDownNotifyRecipient > 14) gmplsTunnelAdminStatusFlags (please see comments > regarding the name of this TC and make adjustments > to the name and DESCRIPTION of this object as appropriate). Ack > 15) gmplsTunnelExtraParamsPtr OBJECT-TYPE > > This object does not seem appropriate for this MIB. > It would seem an enterprise MIB could do something > like this (and possibly not use a RowPointer) so > please explain what the intention is. Nack See discussions of rowPointer in the LSR MIB. We need to be easily extensible to standard MIB modules that will provide additional parameters as described in the DESCRIPTION clause. Such MIB modules will contain tables the entries of which will each be used by multiple tunnels. In this context a row pointer is appropriate. > 16) gmplsTunnelHopTable OBJECT-TYPE > The storage type for an entry in this table is inherited from > mplsTunnelHopStorageType in the corresponding entry in > mplsTunnelHopTable. > > Please change to: > > The storage type for this entry is given by the value > of mplsTunnelHopStorageType in the corresponding entry in the > mplsTunnelHopTable. Ack > 17) gmplsTunnelHopExpLabel OBJECT-TYPE > > DESCRIPTION > "If gmplsTunnelHopLabelStatuses object indicates that a forward > label is present and gmplsTunnelHopExpLabelPtr contains the > value zeroDotZero, then the label to use on this hop is found in > object encoded within a 32-bit integer." > > Think the last part of this sentence is awkward: > > ...to use on this hop is represented by the value of this object. Ack > 18) gmplsTunnelHopExpLabel and gmplsTunnelHopExpLabelPtr > > Need to add the word "Forward" in here as in > gmplsTunnelHopExpForwardLabel and gmplsTunnelHopExpForwardLabelPtr > > That way it will be consistent with the Reverse counterparts. Nack Please see point 21 about name lengths. We will insert "Fwd" > 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpReverseLabelPtr > > Please change Rvrs to Reverse. Nack Please see point 21 about name lengths > 20) gmplsTunnelHopLabelStatuses and gmplsTunnelARHopLabelStatuses > > Please change Statuses to State. Nack Status is the correct word. State would be incorrect. > 21) gmplsTunnelARHopExpLable and gmplsTunnelARHopExpLabelPtr > > Need to add the word "Forward" in here as in > gmplsTunnelARHopExpForwardLabel and gmplsTunnelARHopExpForwardLabelPtr Nack Would excede 32 characters. Will use "Fwd" > 22) gmplsTunnelARHopExpRvrsLabel and gmplsTunnelARHopExpRvrsLabelPtr > > Please change Rvrs to Reverse Nack See point 21 > 23) gmplsTunnelARHopProtection OBJECT-TYPE > > Please add what the BIT set (i.e. 1) vs. 0 means in the > DESCRIPTION. Ack Limited change as before. > 24) gmplsTunnelCHopLabelTable objects > > Similar comments regarding the objects in this table > to those above with regard to naming > conventions (Forward and Reverse) and DESCRIPTIONs. Will not repeat the > details, please refer to above comments on the > prior 2 tables. Nack Same answers as before. Will use "Fwd" > 25) gmplsTunnelReversePerfTable > Please add to the DESCRIPTION how a user knows if > this is a bidirectional tunnel (i.e. what object > or objects in the gmplsTunnelTable need to have > what values?). Ack > 26) gmplsTunnelReversePerfPackets > > Does this object represent the 32-bit > value of the least significant part of the > 64-bit value (which is contained in gmplsTunnelReversePerfHCPackets)? Ack > 27) gmplsTunnelReversePerfBytes > > Does this object represent the 32-bit > value of the least significant part of the > 64-bit value (which is contained in gmplsTunnelReversePerfHCBytes)? Ack > 28) gmplsTunnelErrorTable OBJECT-TYPE > > Since this table applies to MPLS, it should be > put in a separate MIB module which is MPLS specific. The > prefix of gmpls could be confusing. Nack This is applicable across MPLS and GMPLS. Error TLVs are not present in MPLS RSVP-TE at this time. They may be added later. > 29) gmplsTunnelErrorTLVs OBJECT-TYPE > > Need to add a variable size to this string. When the string > size is 0 that would indicate that no TLVs are present, so > the DESCRIPTION should be modified to reflect this. Ack As per discussion with David. > 30) gmplsTunnelErrorHelpString OBJECT-TYPE > SYNTAX DisplayString > > DisplayString is not used in newer MIBs because it does not > meet internationalization standards, better to use > SnmpAdminString or something which meets internationalization > standards. Ack > 31) Compliance > > Please move some of the following comment in the > DESCRIPTION of gmplsTeModuleFullCompliance > > -- The mandatory group has to be implemented by all LSRs that > -- originate, terminate or act as transit for TE-LSPs/tunnels. > -- In addition, depending on the type of tunnels supported, other > -- groups become mandatory as explained below. Ack > 32) gmplsTunnelUnnumIf does not appear in the ReadOnly compliance > and it probably should. Ack > Section 11.2.1. IANA-GMPLS-MIB Definition > ----------------------------------------- > 33) Please change the name of this MIB to > IANA-GMPLS-TC-MIB > > and instead of: ianaGmpls MODULE-IDENTITY > please use: ianaGmplsTcMIB MODULE-IDENTITY Ack > 34) Please add the following to the DESCRIPTION: > "Copyright (C) The Internet Society (2005). The initial version > of this MIB module was published in RFC XXXX. For full legal > notices see the RFC itself. Supplementary information > may be available on: > http://www.ietf.org/copyrights/ianamib.html Ack > 35) Please change GMPLS-TE-MIB's to GMPLS-TE-STD-MIB's [RFCXXX] (RFC-Editor > please fill in the XXX based on the RFC number for > draft-ietf-ccamp-gmpls-te-mib > and remove this note) in the > DESCRIPTION clauses of ALL TCs. Ack > 36) Please change the name IANAGmplsLSPEncoding to > IANAGmplsLSPEncodingType. (more closely matches what's on > IANA's website now) Ack > 37) Please change the name IANAGmplsGPid to > IANAGmplsGeneralizedPid Ack > 38) I believe that the TC > > IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION > > should be put in the GMPLS-TC-STD-MIB or should just > remain in the GMPLS-TE-STD-MIB. The reason is that this > is not an assigned numbers list maintained by IANA, so > should not be in the IANA GMPLS MIB. If I am incorrect > about this please let me know, but I didn't see an IANA > maintained Administrative Status Information enum. Nack There are no fewer than three requests in CCAMP I-Ds that have passed WG last call for this space to be managed by IANA. > Additionally, this should be renamed to > GmplsAdminStatusInformation which more closely matches rfc3471. Ack > 39) Several comments on the SYNTAX clause: > > 40a) smicngPRO gives the error > > E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS > must be in contiguous positions > > SYNTAX BITS { > delInProgress (0), > adminDown (1), > testing (2), > reflect (31) > } > > > RFC2578 specifies that BITS should be contiguous > (although there are exceptions to this, but this > object does not seem to be an exception). Nack To quote the DESCRIPTION... The relationship between the assignment of gmplsTunnelAdminStatusFlags values and of the bit flags in the Admin Status object or TLV within the GMPLS signaling protocols is solely the purview of IANA and is subject to change without notice." However, it seems to us that making the bits match the flags in the Admin Status object is a Good Idea (TM). > Could delInProgress, be renamed to deleteInProgress ? > Could adminDown be renamed to administrativelyDown? > These names more closely match 3471. Ack > 40b) Please put in the specific section number on this > reference (section 8?). Ack Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 22 Sep 2005 05:17:01 +0000 Message-ID: <04f201c5bc52$93d57ff0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Working group last call on draft-ietf-ccamp-gmpls-ason-routing-eval Date: Sun, 18 Sep 2005 14:10:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, As requested by the AD, I asked the mailing list to let me know if there were any objections to last calling this I-D. I received none. Therefore this email starts a two eek last call on draft-ietf-ccamp-gmpls-ason-routing-eval. The last call will end on 2nd October at 12 noon GMT. The draft is targeted as Informational. Please send your comments to the mailing list. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Sep 2005 02:39:06 +0000 Message-ID: <0bdb01c5bc9c$4010f3a0$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Informal pre-IANA registries for MPLS and GMPLS Date: Sun, 18 Sep 2005 22:25:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Just to remind folks that I maintain two informal pre-IANA registries that folk may want to make use of. You can find them on the alternative CCAMP pages at http://www.olddog.co.uk/ccamp.htm LSP-ATTRIBUTES bits are for use in the LSP-ATTRIBUTES and LSP-REQUIRED-ATTRIBUTES objects as defined in draft-ietf-mpls-rsvpte-attributes-05.txt. Hopefully this will reach IANA through the RFC Editor process quite soon. The ADMIN-STATUS object is defined in RFC3473 with bits defined in RFC3471. Other bits are being defined here and there but there is currently no IANA registry. Several drafts in the RFC Editor queue and in AD review make a request to create the registry, so we will have one one day. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Sep 2005 02:38:20 +0000 Message-ID: <0c0c01c5bca3$82c18960$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Jim Jones" Cc: , "'Kireeti Kompella'" , , "Bill Fenner" Subject: Response to your questions about GMPLS parameters Date: Sun, 18 Sep 2005 23:51:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: Jim Jones, OIF Technical Committee Chair From: Adrian Farrel and Kireeti Kompella, WG Co-Chairs for IETF CCAMP Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors Subject: Response to your questions about GMPLS parameters. Dear Jim, Thanks for your correspondence about the questions with respect to GMPLS parameters that arose before and during your interoperability testing. CCAMP is pleased to receive such questions and is glad to have the opportunity to explain the intended operation of the GMPLS protocols. Much of the material supplied below can be simply extracted from the relevant RFCs. > 1. Use of the NCC and RCC fields for STS-3c/VC-4 connections > > During OIF testing it was noted that some ambiguity exists in the > specification of encoding of NCC, RCC and NVC for certain types of > connections: NCC and RCC for an STS-3c/VC-4 connection can be set to 0 > or to 1 depending on which example of RFC 3946 is followed. > > Clarification is requested from IETF CCAMP as to which setting is > considered correct, or if both settings should be accepted (this > procedure was used during testing at Supercomm). This question about RFC 3946 was raised informally on the CCAMP mailing list at the start of March this year. The intention of the editors of RFC 3946 was that a VC-4 elementary signal would be represented using RCC=0 and NCC=0, while an STS-3c SPE elementary signal would have RCC=1 and NCC=1. This follows the examples in the annex. Your question probably arises from the two notes and subsequent paragraph in section 2.1 or RFC 3946. The text here is compatible with the annex, but culminates with... "A RCC value different from 0 must imply a number of contiguous components greater than 1." The editors intended this to mean "greater than or equal to 1." As a result of your question there has been some heated debate within CCAMP driven by the fact that some people have implemented according to the word of the RFC while others have implemented according to the intention of the editors (using the examples in the annex to drive their work). We plan to issue a revision to RFC 3946 which will include the following compromise position. a. "greater than" will be changed to "greater than or equal to" b. A third note will be added to section 2.1 to clarify the expected behavior as follows... Note 3: Following these rules, when requesting a VC-4 signal, the RCC and the NCC values are set to 0, whereas for an STS-3c SPE signal, the RCC and the NCC values are set to 1. However, since the signals are indistinguishable in the data plane, the requesting upstream node MAY set the RCC and NCC values to either both 0 or both 1 without impacting the function. The downstream node MUST accept both possible settings of RCC and NCC and handle them interchangeably. The upstream node SHOULD be consistent in its choice of RCC and NCC value settings for all LSPs requested on any one interface. This solution is still subject to agreement from the CCAMP community, but appears to reflect a position which facilitates maximum interworking. > 2. Setting of NVC for VCAT connections > > It was also noted that the setting of NVC may be somewhat ambiguous for > the case where diverse connections are used within a single VCAT group. > Each individual RSVP session controls a single connection, but the > connection is part of a larger VCAT group and carries VCAT encoding of > the H4 byte. Clarification is requested from IETF CCAMP and ITU-T Q.14/15 > as to the correct setting of NVC for this case (0 or 1?). It should be > noted that this case may occur with a VCAT group with only a single initial > member, and that the NVC may provide an indication that VCAT encoding of > the H4 byte is in use for the connection. A VCn-Xv group split into X components requires each of its component to be signaled with the NVC value set to 1. This setting is regardless of how the components are established. > 3. Length of the Interface Switching Capability TLV > > Although the Interface Switching Capability TLV defined by CCAMP for > SONET/SDH connections was not used for the testing, it was noted that > the text describing the length of the Interface Switching Capability TLV > defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly > ambiguous due to the use of padding bytes. > > RFC 3630 states that "The TLV is padded to four-octet alignment; padding > is not included in the length field (so a three octet value would have a > length of three, but the total size of the TLV would be eight octets)." Yes. Section 2.3.2 of RFC3630 gives a definitive statement of the meaning of the length field and the use of padding, and provides an example. > Reading of the encoding in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt > specifies that the length of the TLV for TDM is 41 bytes plus 3 bytes of > padding, and should be given in the length field as 41 bytes rather than > 44. OIF requests verification of this interpretation from the experts in > IETF CCAMP group. Note that the Interface Switching Capability Descriptor defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link TLV. Sub-TLVs and TLVs follow the same encoding rules. The ISCD TLV for TDM contains the following fields... type 2 bytes length 2 bytes --- switch cap 1 byte encoding 1 byte reserve 2 bytes LSP b/w 0 4 bytes LSP b/w 1 4 bytes LSP b/w 2 4 bytes LSP b/w 3 4 bytes LSP b/w 4 4 bytes LSP b/w 5 4 bytes LSP b/w 6 4 bytes LSP b/w 7 4 bytes min b/w 4 bytes indication 1 byte == 41 bytes We presume that your question relates to whether the 3-byte field shown as "padding" in the TDM-specific figure on page 6 of draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an explicit field. It is an implicit field, and should not be included in the length of the TLV. Nevertheless, we take this opportunity to remind the OIF that implementations of GMPLS protocols should be conservative in what they send and liberal in what they receive. Thus, an implementation that receives a TDM ISCD TLV with length 44 should not reject the TLV for this reason. It should parse the TLV according to the defined fields and skip the final three bytes. Thus, it should not affect a receiving implementation if the sending implementation has treated the "padding" field as implicit or explicit. In the event that a receiving implementation rejected such a TLV on grounds of the value contained in the length field being too large, the fault would lie with the receiving implementation not the sending implementation. > 4. Use of ADMIN_STATUS in an initial PATH message > > Some implementations sent an ADMIN_STATUS object with no flags set in > the initial PATH message, i.e., when no status change was being requested. > Although this did not serve any particular function, it was believed > that this could be accepted as RFC3473, sect. 7.2 (page 18) states: > > "The absence of the object is equivalent to receiving an object > containing values all set to zero (0)." > > It was our interpretation based on this text that a node should accept > an ADMIN_STATUS object with no flags set in the same way as if > the object was missing. Comment on this interpretation is welcome. The effect of the meaning is as you state, but the intention of the meaning is reversed. That is, an implementation should accept the absence of the ADMIN_STATUS object in the same way as if the object was present with no flags set. That is, the default behavior is to consider the ADMIN_STATUS object as a standard part of the processing. We note from your first paragraph that you assume that the ADMIN_STATUS object is used to change the status of the LSP. This is a misinterpretation - it is used to control the status of the LSP. Thus, if there is no change to the status of an LSP, refresh messages must continue to carry the ADMIN_STATUS object with the same bit setting. In this way, it is not possible to "drop" the ADMIN_STATUS object without having the same meaning as transmitting the object with all bits cleared. > 5. Handling of multiple received ResvConf Request objects > > When a connection desires a confirmation that the service (i.e. > connection) requested is in place, a RESV_CONF_REQ object is included in > the RESV message. As this object is received by the remote end of the > reservation, it will send a RESV_CONF message back to the requester. > > However, it is unclear whether it is necessary to send a RESV_CONF > message when the RSVP connection state is refreshed by subsequent > RESV. This becomes potentially burdensome, especially when the > reservation is being rapidly refreshed. Therefore we ask: should the > remote end send a RESV_CONF message for subsequent RESV > messages that still include the RESV_CONF_REQ object? Or is it > required that the requestor of the reservation remove the > RESV_CONF_REQ object to prevent the generation of further > RESV_CONF messages? Comment on this issue from IETF CCAMP > is requested. It is fundamental to the implementation of RSVP-TE that there is a good understanding of the distinction between a trigger message and a refresh message. This can be achieved by reading section 1.1 of RFC2961. Following this understanding, you will note that a refresh message does not cause any processing to be performed at the LSR that receives it (in this case the ingress). You will also note that refresh processing is not end-to-end as implied in your text, but is hop-by-hop. Thus, a downstream LSR that wishes to trigger a new ResvConf message must make a specific change to the content of the Resv message that it sends in order to cause a trigger message to be propagated through the network to the ingress LSR. Such processing is implementation specific but might include the toggling of the presence of the RESV_CONFIRM object on the Resv message. Note that a ResvConf message is not necessarily reliably delivered end-to-end. Relying on the receipt of a ResvConf message before doing something (e.g. turning on the laser) might be a poor idea. GMPLS uses the Administrative Status object and in particular the R-bit in order to reliably achieve this function. > 6. Symmetry of Refresh Reduction usage > > During interop testing, we ran into a conflict caused by varying > interpretations of RFC2961, regarding the use of SRefresh messages and > the Refresh Reduction capabilities of the two ends of a given link. One > interpretation of RFC2961 indicates that setting the Refresh Reduction > Capability flag in the RSVP header indicates that that interface shall > be capable of receiving messages related to Refresh Reduction - > including the SRefresh message. This would be true even if the other > end of the link for that interface were NOT indicating Refresh Reduction > Capability, since the RFC makes no statement about symmetry in this > matter. > > Another interpretation is that both ends of an interface must indicate > Refresh Reduction Capability before either end can use such messages, > i.e, use of Refresh Reduction on a link is symmetric. > > Comment from CCAMP WG on the correct interpretation is requested. We are confused by your question. You correctly state that the use of the refresh-reduction-capable bit indicates the ability of an LSR to support the receipt of refresh reduction options and messages. To quote from section 2 of RFC2961... When set, indicates that this node is willing and capable of receiving all the messages and objects described in this document. This includes the Bundle message described in Section 3, the MESSAGE_ID objects and Ack messages described in Section 4, and the MESSAGE_ID LIST objects and Srefresh message described in Section 5. This bit is meaningful only between RSVP neighbors. This makes no statement about whether the LSR intends to use these options when communicating with another LSR. However, you will note that some refresh reduction procedures require that a message is sent and response returned. In order to make use of the response, the receiver must be capable of receiving and processing the response. Thus, it would be usual for an LSR that is capable of sending refresh reduction options and messages to also set the refresh-reduction-capable bit. In summary: - An LSR must not send refresh reduction options or messages to an LSR that is not setting the refresh-reduction-capable bit. - An LSR may send refresh reduction options or messages to an LSR that is setting the refresh-reduction-capable bit. - An LSR that wishes to successfully use responded refresh reduction options or messages should set the refresh- reduction-capable bit. Note, finally, that section 2 of RFC 2961 states that "When it is not known if a next hop supports the extension, standard Path and Resv message based refreshes MUST be used." > 7. Sending of ACKs bundled with the RSVP HELLO > > During interop testing, it was observed that Message Acks were > piggybacked onto RSVP Hello messages, when the receiving end > was not using the Hello protocol. In this situation, the incoming > Hello's were discarded and the Acks were lost. > > We believe that Message Acks should only be piggybacked onto mandatory > messages, and not on Hello messages because of this problem. Comment on > this interpretation is requested. You use of the terms "bundled" and "piggybacked" are contradictory. "Bundled" implies the use of the Bundle message. RFC 2961 states... A sub-message MAY be any message type except for another Bundle message. Thus, Ack messages may be bundled with other messages. (Although one might consider this perverse since the Ack message is only introduced to handle the case when the Ac/Nack objects have no other message on which they can be carried.) Further, RFC 3209 states... A Hello message may be included as a sub-message within a bundle message. Therefore, it acceptable for a Ack and Hello messages to be bundled together. The processing rules (RFC 29610 for Bundled messages are such that each sub-message is processed in its own right, and the non-support/non-use of Hello messages should not impact the processing of other messages. On the other hand, "piggybacked" implies the use of the Ack/Nack objects within a Hello message. Section 4.1 of RFC2961 states that Ack/Nack objects may be included in the "standard" RSVP messages, and shows where they are placed. However, RFC 3209 defines the Hello message as not including the Ack/Nack objects... ::= [ ] Since RFC 3209 post-dates RFC 2961, this definition is definitive and the Ack/Nack objects should not be present on the Hello message. Give that section 5.3 of RFC 3209 states... The Hello Message is completely OPTIONAL. All messages may be ignored by nodes which do not wish to participate in Hello message processing. ...it is not particularly important what the message format rules are. An implementation that chooses to place an Ack/Nack object in a Hello message knows that the object might be discarded unprocessed. > 8. TSPEC format to be used for Ethernet connections The CCAMP working group has discussed the use of GMPLS for control of Ethernet devices, and this has led to the publication of a new Internet-Draft entitled "Use of the Generalized Multi-Protocol Label Switching control plane for point-to-point Ethernet Label Switching" which you can find at http://www.ietf.org/internet-drafts/draft-andersson-gels-bof-prep-00.txt. The Abstract of this draft reads as follows: This document proposes starting a work within the IETF to apply the Generalized Multi-Protocol Label Switching (GMPLS) control plane to Ethernet Label Switching and to make extensions to the GMPLS control plane protocols as necessary for this application. This will be done based on the protocols developed by the MPLS and CCAMP working groups in the IETF. Ethernet Label Switching will use the data plane encodings as specified by the IEEE 802 standards. This document intends to gather the information necessary to have a "GMPLS Ethernet Label Switching" BoF in Vancouver. We are certain that the IETF will want to ensure that the OIF's requirements for Ethernet are adequately covered by GMPLS and would urge the OIF to document its requirements and to send them to the IETF for inclusion. In this instance you may send such requirements to us and we will ensure that they are passed on to the correct group that undertakes this work. Best regards, Adrian Farrel Kireeti Kompella Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 21 Sep 2005 02:37:29 +0000 Message-ID: <0be701c5bc9c$e0651c50$28849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Arthi Ayyangar" Cc: "'Jean Philippe Vasseur'" , Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt Date: Sun, 18 Sep 2005 23:02:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Arthi, I'm sorry that there is a conflict for these bits. Way back in the distant past a predecessor of your I-D had the Contiguous bit at 0x02 and the Stitching bit at 0x03 while it also had a Crankback bit at 0x01. There was an obvious conflict even then with the Crankback I-D and I started the registry to try to resolve this and sent mail to the MPLS and CCAMP lists. Obviously I didn't draw it to your attention well enough. I don't think that you can claim to predate the crankback work which was already at revision 6 in June 2003. But that probably isn't important. We have a conflict we need to resolve. Since the Crankback I-D completed WG last call in April this year and was passed to the ADs in May, I think it "wins". Cheers, Adrian ----- Original Message ----- From: "Arthi Ayyangar" To: "Adrian Farrel" Cc: "'Jean Philippe Vasseur'" ; Sent: Thursday, September 15, 2005 1:56 AM Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt > Hi Adrian, > > Sorry for the delay (as usual) and thanks for your comments (as usual). > I have incorporated your comments and suggestions for the next rev. Just > one major point of contention. See below. > > > Section 4.1 (also section 9.1) > > 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end > > node that originates the inter-domain TE LSP if it desires a > > contiguous end-to-end TE LSP (in the control & data plane). When set, > > this indicates that a boundary node MUST not perform any stitching or > > nesting on the TE LSP and the TE LSP MUST be routed as any other TE > > LSP (it must be contiguous end to end). When this bit is cleared, a > > boundary node may decide to perform stitching or nesting. A mid-point > > node not supporting contiguous TE LSP MUST send a Path Error message > > > > a. s/MUST not/MUST NOT/ > > b. I have allocated bit number 4 (0x08) in the temporary registry of > > LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp-attrib.txt as > > a place holder until the IANA takes over this work. (I think we've > > discussed this before - the point of the temporary registry is to save > ---------> This has been 0x01 for Contiguous LSP desired and 0x02 for > Stitching desired since the beginning of any of these drafts, through the > merger and split. And I remember that the LSP Attributes registry used to > carry the matching numbers before. But looks like other drafts have > appeared and now the numbers for the inter-domain IDs in the registry no > longer match the ones in the IDs. > > Just one point that these inter-domain IDs predate most of the other IDs > actually (in fact we went the LSP ATTRIBUTES path because we ran out of > bits for the inter-domain IDs), so I am not sure what you propose we do > at this point. > > thanks, > -arthi Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 20 Sep 2005 08:41:48 +0000 Message-ID: <432FCA7B.5090704@pi.se> Date: Tue, 20 Sep 2005 10:38:19 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) MIME-Version: 1.0 To: gels@rtg.ietf.org, mpls@ietf.org, ccamp@ops.ietf.org, pwe3 , l1vpn@ietf.org, L2VPN , "Developing a hybrid router/bridge." , rtgwg@ietf.org, rtg-dir@ietf.org Subject: GMPLS Ethernet in Vancouver Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, following the discussion in the CCAMP working group on the L2SC design team report, the discussion continued off-line and the idea to hold a GMPLS Ethernet BoF in Vancouver was born. We have collected bits and pieces of the discussion so far and tried to come up with a way to proceed. We have put together a more focused proposal for GMPLS controled Ethernet Label Switching and have requested that a BoF will be held in Vancouver. This request has been approved by the Routing Area directors. A draft draft-andersson-gels-bof-prep-00.txt has been published to serve as a starting point for the discussion at the BoF. The intention has been to reflect the GMPLS Ethernet discussion so far, without any claim to be complete or "objective", but to specify limited and focused work that can serve starting as a point for GMPLS controlled Ethernet Label Switching. A mailing list has been set up to host the discussion before the BoF to subscribe to the mailing list send mail to gels-request@rtg.ietf.org (subsribe) in body or subject or visit https://rtg.ietf.org/mailman/listinfo/gels Looking forward to comments and discussion. /Loa and Dimitri -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Sep 2005 18:45:46 +0000 Message-Id: <200509191845.j8JIjKqK021092@auds953.usa.alcatel.com> From: "Jim Jones" To: "'Adrian Farrel'" Cc: , "'Kireeti Kompella'" , , "'Bill Fenner'" Subject: RE: Response to your questions about GMPLS parameters Date: Mon, 19 Sep 2005 13:45:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-index: AcW8oyQGzTZVDYHRQmSm2ZTpUPRFfQApgrzA Dear Adrian, Thanks for the detailed reply. I am posting this on the OIF contribution site for discussion during our 4Q Technical Committee meetings next month. I expect we will cover the topic of Ethernet requirements as well as the details regarding GMPLS parameters. Again, we appreciate the efforts of the IETF CCAMP in preparing this reply and look forward to continued cooperation. Best Regards, Jim -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: Sunday, September 18, 2005 5:51 PM To: Jim Jones Cc: ccamp@ops.ietf.org; 'Kireeti Kompella'; zinin@psg.com; Bill Fenner Subject: Response to your questions about GMPLS parameters To: Jim Jones, OIF Technical Committee Chair From: Adrian Farrel and Kireeti Kompella, WG Co-Chairs for IETF CCAMP Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors Subject: Response to your questions about GMPLS parameters. Dear Jim, Thanks for your correspondence about the questions with respect to GMPLS parameters that arose before and during your interoperability testing. CCAMP is pleased to receive such questions and is glad to have the opportunity to explain the intended operation of the GMPLS protocols. Much of the material supplied below can be simply extracted from the relevant RFCs. > 1. Use of the NCC and RCC fields for STS-3c/VC-4 connections > > During OIF testing it was noted that some ambiguity exists in the > specification of encoding of NCC, RCC and NVC for certain types of > connections: NCC and RCC for an STS-3c/VC-4 connection can be set to 0 > or to 1 depending on which example of RFC 3946 is followed. > > Clarification is requested from IETF CCAMP as to which setting is > considered correct, or if both settings should be accepted (this > procedure was used during testing at Supercomm). This question about RFC 3946 was raised informally on the CCAMP mailing list at the start of March this year. The intention of the editors of RFC 3946 was that a VC-4 elementary signal would be represented using RCC=0 and NCC=0, while an STS-3c SPE elementary signal would have RCC=1 and NCC=1. This follows the examples in the annex. Your question probably arises from the two notes and subsequent paragraph in section 2.1 or RFC 3946. The text here is compatible with the annex, but culminates with... "A RCC value different from 0 must imply a number of contiguous components greater than 1." The editors intended this to mean "greater than or equal to 1." As a result of your question there has been some heated debate within CCAMP driven by the fact that some people have implemented according to the word of the RFC while others have implemented according to the intention of the editors (using the examples in the annex to drive their work). We plan to issue a revision to RFC 3946 which will include the following compromise position. a. "greater than" will be changed to "greater than or equal to" b. A third note will be added to section 2.1 to clarify the expected behavior as follows... Note 3: Following these rules, when requesting a VC-4 signal, the RCC and the NCC values are set to 0, whereas for an STS-3c SPE signal, the RCC and the NCC values are set to 1. However, since the signals are indistinguishable in the data plane, the requesting upstream node MAY set the RCC and NCC values to either both 0 or both 1 without impacting the function. The downstream node MUST accept both possible settings of RCC and NCC and handle them interchangeably. The upstream node SHOULD be consistent in its choice of RCC and NCC value settings for all LSPs requested on any one interface. This solution is still subject to agreement from the CCAMP community, but appears to reflect a position which facilitates maximum interworking. > 2. Setting of NVC for VCAT connections > > It was also noted that the setting of NVC may be somewhat ambiguous > for the case where diverse connections are used within a single VCAT group. > Each individual RSVP session controls a single connection, but the > connection is part of a larger VCAT group and carries VCAT encoding of > the H4 byte. Clarification is requested from IETF CCAMP and ITU-T Q.14/15 > as to the correct setting of NVC for this case (0 or 1?). It should be > noted that this case may occur with a VCAT group with only a single initial > member, and that the NVC may provide an indication that VCAT encoding > of the H4 byte is in use for the connection. A VCn-Xv group split into X components requires each of its component to be signaled with the NVC value set to 1. This setting is regardless of how the components are established. > 3. Length of the Interface Switching Capability TLV > > Although the Interface Switching Capability TLV defined by CCAMP for > SONET/SDH connections was not used for the testing, it was noted that > the text describing the length of the Interface Switching Capability > TLV defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be > slightly ambiguous due to the use of padding bytes. > > RFC 3630 states that "The TLV is padded to four-octet alignment; > padding is not included in the length field (so a three octet value > would have a length of three, but the total size of the TLV would be eight octets)." Yes. Section 2.3.2 of RFC3630 gives a definitive statement of the meaning of the length field and the use of padding, and provides an example. > Reading of the encoding in > draft-ietf-ccamp-ospf-gmpls-extensions-12.txt > specifies that the length of the TLV for TDM is 41 bytes plus 3 bytes > of padding, and should be given in the length field as 41 bytes rather > than 44. OIF requests verification of this interpretation from the > experts in IETF CCAMP group. Note that the Interface Switching Capability Descriptor defined in draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link TLV. Sub-TLVs and TLVs follow the same encoding rules. The ISCD TLV for TDM contains the following fields... type 2 bytes length 2 bytes --- switch cap 1 byte encoding 1 byte reserve 2 bytes LSP b/w 0 4 bytes LSP b/w 1 4 bytes LSP b/w 2 4 bytes LSP b/w 3 4 bytes LSP b/w 4 4 bytes LSP b/w 5 4 bytes LSP b/w 6 4 bytes LSP b/w 7 4 bytes min b/w 4 bytes indication 1 byte == 41 bytes We presume that your question relates to whether the 3-byte field shown as "padding" in the TDM-specific figure on page 6 of draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an explicit field. It is an implicit field, and should not be included in the length of the TLV. Nevertheless, we take this opportunity to remind the OIF that implementations of GMPLS protocols should be conservative in what they send and liberal in what they receive. Thus, an implementation that receives a TDM ISCD TLV with length 44 should not reject the TLV for this reason. It should parse the TLV according to the defined fields and skip the final three bytes. Thus, it should not affect a receiving implementation if the sending implementation has treated the "padding" field as implicit or explicit. In the event that a receiving implementation rejected such a TLV on grounds of the value contained in the length field being too large, the fault would lie with the receiving implementation not the sending implementation. > 4. Use of ADMIN_STATUS in an initial PATH message > > Some implementations sent an ADMIN_STATUS object with no flags set in > the initial PATH message, i.e., when no status change was being requested. > Although this did not serve any particular function, it was believed > that this could be accepted as RFC3473, sect. 7.2 (page 18) states: > > "The absence of the object is equivalent to receiving an object > containing values all set to zero (0)." > > It was our interpretation based on this text that a node should accept > an ADMIN_STATUS object with no flags set in the same way as if the > object was missing. Comment on this interpretation is welcome. The effect of the meaning is as you state, but the intention of the meaning is reversed. That is, an implementation should accept the absence of the ADMIN_STATUS object in the same way as if the object was present with no flags set. That is, the default behavior is to consider the ADMIN_STATUS object as a standard part of the processing. We note from your first paragraph that you assume that the ADMIN_STATUS object is used to change the status of the LSP. This is a misinterpretation - it is used to control the status of the LSP. Thus, if there is no change to the status of an LSP, refresh messages must continue to carry the ADMIN_STATUS object with the same bit setting. In this way, it is not possible to "drop" the ADMIN_STATUS object without having the same meaning as transmitting the object with all bits cleared. > 5. Handling of multiple received ResvConf Request objects > > When a connection desires a confirmation that the service (i.e. > connection) requested is in place, a RESV_CONF_REQ object is included > in the RESV message. As this object is received by the remote end of > the reservation, it will send a RESV_CONF message back to the requester. > > However, it is unclear whether it is necessary to send a RESV_CONF > message when the RSVP connection state is refreshed by subsequent > RESV. This becomes potentially burdensome, especially when the > reservation is being rapidly refreshed. Therefore we ask: should the > remote end send a RESV_CONF message for subsequent RESV messages that > still include the RESV_CONF_REQ object? Or is it required that the > requestor of the reservation remove the RESV_CONF_REQ object to > prevent the generation of further RESV_CONF messages? Comment on this > issue from IETF CCAMP is requested. It is fundamental to the implementation of RSVP-TE that there is a good understanding of the distinction between a trigger message and a refresh message. This can be achieved by reading section 1.1 of RFC2961. Following this understanding, you will note that a refresh message does not cause any processing to be performed at the LSR that receives it (in this case the ingress). You will also note that refresh processing is not end-to-end as implied in your text, but is hop-by-hop. Thus, a downstream LSR that wishes to trigger a new ResvConf message must make a specific change to the content of the Resv message that it sends in order to cause a trigger message to be propagated through the network to the ingress LSR. Such processing is implementation specific but might include the toggling of the presence of the RESV_CONFIRM object on the Resv message. Note that a ResvConf message is not necessarily reliably delivered end-to-end. Relying on the receipt of a ResvConf message before doing something (e.g. turning on the laser) might be a poor idea. GMPLS uses the Administrative Status object and in particular the R-bit in order to reliably achieve this function. > 6. Symmetry of Refresh Reduction usage > > During interop testing, we ran into a conflict caused by varying > interpretations of RFC2961, regarding the use of SRefresh messages and > the Refresh Reduction capabilities of the two ends of a given link. > One interpretation of RFC2961 indicates that setting the Refresh > Reduction Capability flag in the RSVP header indicates that that > interface shall be capable of receiving messages related to Refresh > Reduction - including the SRefresh message. This would be true even if > the other end of the link for that interface were NOT indicating > Refresh Reduction Capability, since the RFC makes no statement about > symmetry in this matter. > > Another interpretation is that both ends of an interface must indicate > Refresh Reduction Capability before either end can use such messages, > i.e, use of Refresh Reduction on a link is symmetric. > > Comment from CCAMP WG on the correct interpretation is requested. We are confused by your question. You correctly state that the use of the refresh-reduction-capable bit indicates the ability of an LSR to support the receipt of refresh reduction options and messages. To quote from section 2 of RFC2961... When set, indicates that this node is willing and capable of receiving all the messages and objects described in this document. This includes the Bundle message described in Section 3, the MESSAGE_ID objects and Ack messages described in Section 4, and the MESSAGE_ID LIST objects and Srefresh message described in Section 5. This bit is meaningful only between RSVP neighbors. This makes no statement about whether the LSR intends to use these options when communicating with another LSR. However, you will note that some refresh reduction procedures require that a message is sent and response returned. In order to make use of the response, the receiver must be capable of receiving and processing the response. Thus, it would be usual for an LSR that is capable of sending refresh reduction options and messages to also set the refresh-reduction-capable bit. In summary: - An LSR must not send refresh reduction options or messages to an LSR that is not setting the refresh-reduction-capable bit. - An LSR may send refresh reduction options or messages to an LSR that is setting the refresh-reduction-capable bit. - An LSR that wishes to successfully use responded refresh reduction options or messages should set the refresh- reduction-capable bit. Note, finally, that section 2 of RFC 2961 states that "When it is not known if a next hop supports the extension, standard Path and Resv message based refreshes MUST be used." > 7. Sending of ACKs bundled with the RSVP HELLO > > During interop testing, it was observed that Message Acks were > piggybacked onto RSVP Hello messages, when the receiving end was not > using the Hello protocol. In this situation, the incoming Hello's were > discarded and the Acks were lost. > > We believe that Message Acks should only be piggybacked onto mandatory > messages, and not on Hello messages because of this problem. Comment > on this interpretation is requested. You use of the terms "bundled" and "piggybacked" are contradictory. "Bundled" implies the use of the Bundle message. RFC 2961 states... A sub-message MAY be any message type except for another Bundle message. Thus, Ack messages may be bundled with other messages. (Although one might consider this perverse since the Ack message is only introduced to handle the case when the Ac/Nack objects have no other message on which they can be carried.) Further, RFC 3209 states... A Hello message may be included as a sub-message within a bundle message. Therefore, it acceptable for a Ack and Hello messages to be bundled together. The processing rules (RFC 29610 for Bundled messages are such that each sub-message is processed in its own right, and the non-support/non-use of Hello messages should not impact the processing of other messages. On the other hand, "piggybacked" implies the use of the Ack/Nack objects within a Hello message. Section 4.1 of RFC2961 states that Ack/Nack objects may be included in the "standard" RSVP messages, and shows where they are placed. However, RFC 3209 defines the Hello message as not including the Ack/Nack objects... ::= [ ] Since RFC 3209 post-dates RFC 2961, this definition is definitive and the Ack/Nack objects should not be present on the Hello message. Give that section 5.3 of RFC 3209 states... The Hello Message is completely OPTIONAL. All messages may be ignored by nodes which do not wish to participate in Hello message processing. ...it is not particularly important what the message format rules are. An implementation that chooses to place an Ack/Nack object in a Hello message knows that the object might be discarded unprocessed. > 8. TSPEC format to be used for Ethernet connections The CCAMP working group has discussed the use of GMPLS for control of Ethernet devices, and this has led to the publication of a new Internet-Draft entitled "Use of the Generalized Multi-Protocol Label Switching control plane for point-to-point Ethernet Label Switching" which you can find at http://www.ietf.org/internet-drafts/draft-andersson-gels-bof-prep-00.txt. The Abstract of this draft reads as follows: This document proposes starting a work within the IETF to apply the Generalized Multi-Protocol Label Switching (GMPLS) control plane to Ethernet Label Switching and to make extensions to the GMPLS control plane protocols as necessary for this application. This will be done based on the protocols developed by the MPLS and CCAMP working groups in the IETF. Ethernet Label Switching will use the data plane encodings as specified by the IEEE 802 standards. This document intends to gather the information necessary to have a "GMPLS Ethernet Label Switching" BoF in Vancouver. We are certain that the IETF will want to ensure that the OIF's requirements for Ethernet are adequately covered by GMPLS and would urge the OIF to document its requirements and to send them to the IETF for inclusion. In this instance you may send such requirements to us and we will ensure that they are passed on to the correct group that undertakes this work. Best regards, Adrian Farrel Kireeti Kompella Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Sep 2005 18:35:44 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6D765E63-D385-4308-8D8C-B0B975F372CA@cisco.com> Cc: Adrian Farrel , ccamp@ops.ietf.org Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt Date: Mon, 19 Sep 2005 14:33:38 -0400 To: Arthi Ayyangar Hi Arthi, On Sep 18, 2005, at 10:20 PM, Arthi Ayyangar wrote: > Hi Adrian, > > It is unfortunate that this conflict occured and it took so long to > find this out. Thanks for noticing it, when you did. On the bright > side, atleast we can still fix this. I am okay with changing the > bits in the inter-domain and stitching IDs. JP, is this fine with > you ? > Yes, > I will send out a mail pointing out this change once the next > version has been posted, so that if someone thinks this change is > significant and it affects them, then hopefully they will bring it up. > Thanks. JP. > thanks, > -arthi > > >> I'm sorry that there is a conflict for these bits. Way back in the >> distant >> past a predecessor of your I-D had the Contiguous bit at 0x02 and the >> Stitching bit at 0x03 while it also had a Crankback bit at 0x01. >> There was >> an obvious conflict even then with the Crankback I-D and I started >> the >> registry to try to resolve this and sent mail to the MPLS and >> CCAMP lists. >> >> Obviously I didn't draw it to your attention well enough. >> >> I don't think that you can claim to predate the crankback work >> which was >> already at revision 6 in June 2003. But that probably isn't >> important. >> >> We have a conflict we need to resolve. >> >> Since the Crankback I-D completed WG last call in April this year >> and was >> passed to the ADs in May, I think it "wins". >> >> Cheers, >> Adrian >> >> ----- Original Message ----- >> From: "Arthi Ayyangar" >> To: "Adrian Farrel" >> Cc: "'Jean Philippe Vasseur'" ; >> >> Sent: Thursday, September 15, 2005 1:56 AM >> Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt >> >> >> >>> Hi Adrian, >>> >>> Sorry for the delay (as usual) and thanks for your comments (as >>> usual). >>> I have incorporated your comments and suggestions for the next >>> rev. Just >>> one major point of contention. See below. >>> >>> >>>> Section 4.1 (also section 9.1) >>>> 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end >>>> node that originates the inter-domain TE LSP if it desires a >>>> contiguous end-to-end TE LSP (in the control & data plane). When >>>> >> set, >> >>>> this indicates that a boundary node MUST not perform any >>>> stitching >>>> >> or >> >>>> nesting on the TE LSP and the TE LSP MUST be routed as any >>>> other TE >>>> LSP (it must be contiguous end to end). When this bit is >>>> cleared, a >>>> boundary node may decide to perform stitching or nesting. A >>>> >> mid-point >> >>>> node not supporting contiguous TE LSP MUST send a Path Error >>>> message >>>> >>>> a. s/MUST not/MUST NOT/ >>>> b. I have allocated bit number 4 (0x08) in the temporary >>>> registry of >>>> LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp- >>>> attrib.txt >>>> >> as >> >>>> a place holder until the IANA takes over this work. (I think we've >>>> discussed this before - the point of the temporary registry is to >>>> >> save >> >>> ---------> This has been 0x01 for Contiguous LSP desired and 0x02 >>> for >>> Stitching desired since the beginning of any of these drafts, >>> through >>> >> the >> >>> merger and split. And I remember that the LSP Attributes registry >>> used >>> >> to >> >>> carry the matching numbers before. But looks like other drafts have >>> appeared and now the numbers for the inter-domain IDs in the >>> registry no >>> longer match the ones in the IDs. >>> >>> Just one point that these inter-domain IDs predate most of the >>> other IDs >>> actually (in fact we went the LSP ATTRIBUTES path because we ran >>> out of >>> bits for the inter-domain IDs), so I am not sure what you propose >>> we do >>> at this point. >>> >>> thanks, >>> -arthi >>> >> > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 19 Sep 2005 02:25:09 +0000 Date: Sun, 18 Sep 2005 19:20:57 -0700 (PDT) From: Arthi Ayyangar To: Adrian Farrel cc: "'Jean Philippe Vasseur'" , ccamp@ops.ietf.org Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt Message-ID: <20050918191059.C48484@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi Adrian, It is unfortunate that this conflict occured and it took so long to find this out. Thanks for noticing it, when you did. On the bright side, atleast we can still fix this. I am okay with changing the bits in the inter-domain and stitching IDs. JP, is this fine with you ? I will send out a mail pointing out this change once the next version has been posted, so that if someone thinks this change is significant and it affects them, then hopefully they will bring it up. thanks, -arthi > I'm sorry that there is a conflict for these bits. Way back in the distant > past a predecessor of your I-D had the Contiguous bit at 0x02 and the > Stitching bit at 0x03 while it also had a Crankback bit at 0x01. There was > an obvious conflict even then with the Crankback I-D and I started the > registry to try to resolve this and sent mail to the MPLS and CCAMP lists. > > Obviously I didn't draw it to your attention well enough. > > I don't think that you can claim to predate the crankback work which was > already at revision 6 in June 2003. But that probably isn't important. > > We have a conflict we need to resolve. > > Since the Crankback I-D completed WG last call in April this year and was > passed to the ADs in May, I think it "wins". > > Cheers, > Adrian > > ----- Original Message ----- > From: "Arthi Ayyangar" > To: "Adrian Farrel" > Cc: "'Jean Philippe Vasseur'" ; > Sent: Thursday, September 15, 2005 1:56 AM > Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt > > >> Hi Adrian, >> >> Sorry for the delay (as usual) and thanks for your comments (as usual). >> I have incorporated your comments and suggestions for the next rev. Just >> one major point of contention. See below. >> >>> Section 4.1 (also section 9.1) >>> 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end >>> node that originates the inter-domain TE LSP if it desires a >>> contiguous end-to-end TE LSP (in the control & data plane). When > set, >>> this indicates that a boundary node MUST not perform any stitching > or >>> nesting on the TE LSP and the TE LSP MUST be routed as any other TE >>> LSP (it must be contiguous end to end). When this bit is cleared, a >>> boundary node may decide to perform stitching or nesting. A > mid-point >>> node not supporting contiguous TE LSP MUST send a Path Error message >>> >>> a. s/MUST not/MUST NOT/ >>> b. I have allocated bit number 4 (0x08) in the temporary registry of >>> LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp-attrib.txt > as >>> a place holder until the IANA takes over this work. (I think we've >>> discussed this before - the point of the temporary registry is to > save >> ---------> This has been 0x01 for Contiguous LSP desired and 0x02 for >> Stitching desired since the beginning of any of these drafts, through > the >> merger and split. And I remember that the LSP Attributes registry used > to >> carry the matching numbers before. But looks like other drafts have >> appeared and now the numbers for the inter-domain IDs in the registry no >> longer match the ones in the IDs. >> >> Just one point that these inter-domain IDs predate most of the other IDs >> actually (in fact we went the LSP ATTRIBUTES path because we ran out of >> bits for the inter-domain IDs), so I am not sure what you propose we do >> at this point. >> >> thanks, >> -arthi > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 15 Sep 2005 00:57:58 +0000 Date: Wed, 14 Sep 2005 17:56:05 -0700 (PDT) From: Arthi Ayyangar To: Adrian Farrel cc: "'Jean Philippe Vasseur'" , ccamp@ops.ietf.org Subject: Re: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt Message-ID: <20050914174809.A77537@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi Adrian, Sorry for the delay (as usual) and thanks for your comments (as usual). I have incorporated your comments and suggestions for the next rev. Just one major point of contention. See below. > Section 4.1 (also section 9.1) > 0x01 (TBD): Contiguous LSP bit - this flag is set by the head-end > node that originates the inter-domain TE LSP if it desires a > contiguous end-to-end TE LSP (in the control & data plane). When set, > this indicates that a boundary node MUST not perform any stitching or > nesting on the TE LSP and the TE LSP MUST be routed as any other TE > LSP (it must be contiguous end to end). When this bit is cleared, a > boundary node may decide to perform stitching or nesting. A mid-point > node not supporting contiguous TE LSP MUST send a Path Error message > > a. s/MUST not/MUST NOT/ > b. I have allocated bit number 4 (0x08) in the temporary registry of > LSP_ATTRIBUTE bits available at http://www.olddog.co.uk/lsp-attrib.txt as > a place holder until the IANA takes over this work. (I think we've > discussed this before - the point of the temporary registry is to save ---------> This has been 0x01 for Contiguous LSP desired and 0x02 for Stitching desired since the beginning of any of these drafts, through the merger and split. And I remember that the LSP Attributes registry used to carry the matching numbers before. But looks like other drafts have appeared and now the numbers for the inter-domain IDs in the registry no longer match the ones in the IDs. Just one point that these inter-domain IDs predate most of the other IDs actually (in fact we went the LSP ATTRIBUTES path because we ran out of bits for the inter-domain IDs), so I am not sure what you propose we do at this point. thanks, -arthi Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 13 Sep 2005 15:41:35 +0000 From: "MPLS 2005" To: Subject: MPLS 2005: Early Registration Deadline in 4 Days Date: Tue, 13 Sep 2005 11:37:41 -0400 Message-ID: <000c01c5b879$172dfa90$1ac1d541@workgroup> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C5B857.901C5A90" This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5B857.901C5A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MPLS 2005 International Conference October 16-19, 2005 Omni Shoreham Hotel Washington, DC _____ MPLS 2005 International Conference will be held from Sunday October 16 through Wednesday October 19, 2005 at the Omni Shoreham Hotel in Washington DC. Registration for the MPLS 2005 International Conference is now open, with only FOUR days left to take advantage of the discounted registration rates [early registration discount cut off date is September 17]. Go to www.mpls2005.com/registration.htm to register. Take advantage of this opportunity and register NOW! Conference Program: Sunday, October 16 10:30 - 12:00 am Tutorial 1: Scaling Considerations for MPLS Protocols and Applications - Ina Minei, Juniper Networks 1:00 - 2:30 pm Tutorial 2: Inter-Provider MPLS -Azhar Sayeed and Santiago Alvarez, Cisco Systems 2:45 - 4:15 pm Tutorial 3: Metro Ethernet 4:30 - 6:00 pm Tutorial 4: MPLS Network Operations and Management - Peter Busschbach, Lucent Technologies Monday, October 17 8:30 - 10:15 am * Introduction * Opening Speech * Keynote Speech * MPLS, GMPLS and Pseudowires: The Need for Cooperation Between Standards Bodies - Adrian Farrel, IETF Break & Exhibits 10:45 am - 12:30 pm Pseudowires: Extending the reach * Interprovider Pseudowires - Luca Martini, Cisco Systems * Multi-Hop PWs: "A small step for PWs , a giant step for Metro Convergence?" - David McDysan , MCI & Florin Balus , Nortel Networks * Multi segment Pseudo-Wires using RSVP-TE - Ron Bonica , Juniper Networks * OAM for Multihop Pseudowires - Thomas Nadeau, Cisco Systems Lunch & Exhibits 2:00 - 3:30 pm What do we want from multicast MPLS and Point-to-Multipoint Traffic Engineering? * MPLS P2MP: from the needs definition to the solutions description - Renaud Moignard, France Telecom * Design Considerations for Multicast MPLS/BGP VPNs - Maria Napierala, ATT Labs * Carrier-Grade Multicast Deployment in MPLS Backbones - Nicolai Leymann, T-Systems * Multicast VPN Deployment Scenarios and Service Requirements - Seisho Yasukawa, NTT Break & Exhibits 4:00 - 5:00 pm Ethernet in the Metro Network - What is the role for MPLS? * Metro Ethernet and MPLS - Kireeti Kompella, Juniper Networks * MPLS, Ethernet and the Metro - David Allan, Nortel Networks * GMPLS Controlled Ethernet Networks - Loa Andersson, Acreo 5:00 - 6:00 pm Panel: Advanced Services Using MPLS Panelists from selected ISP/Carriers 6:00 - 7:30 pm: Reception & Exhibits Reception Hosted by Avici Systems Tuesday, October 18 8:30 - 10:15 am Broadband Services - Enabling the future * Broadband, the Next Revolution - What it Means to an MPLS Network - Sangeeta Anand, Cisco Systems * Realizing services across regions utilizing dissimilar convergence layers - Andy Malis and Jonathan Sadler, Tellabs * Broadband Services using MPLS - Kurt Melden, Juniper * Enhanced architecture model that deploys MPLS-enabled Ethernet-based Aggregation in DSL networks for Triple Play services - Sunil Khandekar, Alcatel * Subscriber Aware MPLS for Broadband Services - Arpit Joshipura, Redback Networks Break & Exhibits 10:45 - 12:30 am Building blocks for Advanced Services in MPLS Networks * Combining RSVP and MPLS for Scalable Admission Control - Bruce Davie, Cisco Systems * Assuring QoS: Delivering Real Time Services with MPLS Networks - Sridhar Ramachandran, Nextone * LSP Hierarchy in MPLS networks - Arthi Ayyangar, Juniper Networks * VPN Route Reflector Architectures and Operational Impacts - Eric Brendel, Chiaro Networks * Secure MPLS Backbone Design to Support IMS - Scott Poretsky , Reef Point Systems Lunch & Exhibits 12:30 - 2:00 pm 2:00 - 3:30 pm Interworking MPLS and GMPLS * Applicability of GMPLS to Packet LSPs and MPLS to GMPLS Migration Methods - Dimitri Papadimitriou, Alcatel * Investigation of deployment scenarios for a GMPLS network migrating into an existing IP/MPLS network - Tomohiro Otani, Kenichi Ogaki, Hideaki Tanaka (KDDI), Mallik Tatipamula & Zafar Ali (Cisco) * MPLS and GMPLS interworking - Kohei Shiomoto, NTT * Operational, Deployment and Interworking Considerations for GMPLS Technology - Zafar Ali, Cisco Systems Break & Exhibits 4:00 - 5:00 pm MPLS in Enterprise Networks - Experiences from Deployment * Deploying, interworking and operating L2 and L3 MPLS VPNs - MPLS deployment experience: scaling, performance and security - Peter Himmelberger, CSC * Enterprise Customer Deployment - Tom McKinney, Cisco Systems * An All Encompassing MPLS-Enabled VPN - Lee Jalali, Sprint 5:00 - 6:00 pm Vendor's Panel Session: LDP vs. RSVP-TE Panelists from selected vendors Exhibits 6:00 - 7:30 pm Wednesday, October 19 8:30 - 10:00 am Generalized MPLS in the Optical Network * Overview of GMPLS interworking test in Japan and NICT Keihana GMPLS E-NNI trials - Naoaki Yamanaka * Next Generation IP/Optical Integrated Network in KDDI - Masatoshi Suzuki and Tomohiro Otani, KDDI * Extending GMPLS for Pure Photonic Networks - Don Fedyk & Vik Saxena Nortel Networks & Comcast * Dynamic optical link preemption based on GMPLS traffic engineering - Shinya Tanaka , Japan Telecom * The Unified Optical Control Plane: The Time is Now - Vijay Pandian, Sycamore Networks Break & Exhibits 10:45 - 12:30 am Experiences from the Front Line - Building MPLS Networks for Advanced and Triple-play Services * IPv6 and MPLS - Daniel Awduche, MCI * Case Study: Building A Successful Full Packet Voice Network and IP Network - Hamid Laamouri & Cristina Gentili , WANDL & Telecom Italia * IP/MPLS for Live Broadcast Video Applications, Ryan Korte, WilTel Communications * Telenor's pan- nordic NG multiservice network - Lei Wang, Telenor * Some Considerations in the SLA Delivery for MPLS Enabled Networks - Roman Krzanowski , Verizon Lunch & Exhibits 12:30 - 2:00 pm 2:00 - 3:00 pm Supporting multicast traffic in MPLS networks * Multicast LDP - IJsbrand Wijnands, Cisco Systems * Next-Generation Solutions for Multicast in 2547 VPNs and VPLS - Rahul Aggarwal, Juniper Networks * VPLS Multicast challenges and options, Marc Lasserre, Riverstone Break 3:15 - 4:45 pm Multi-domain MPLS - Now we can all talk together * PCE (Path Computation Element) models: architecture and applications - JP Vasseur, Cisco Systems * Advanced MPLS L3 VPN deployment and challenges - Inter-provider VPNs, VoIP support, and MVPNs - Luyuan Fang, AT&T Labs * Inter-AS Security Factors and Best Practice Guidelines, Monique Morrow, Cisco Systems * Multi-layer traffic engineering with PCE in MPLS/GMPLS networks - Eiji Oki, NTT ------=_NextPart_000_000D_01C5B857.901C5A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

MPLS 2005 International Conference
October 16-19, 2005
Omni = Shoreham Hotel
Washington, = DC=

MPLS 2005 International Conference will be held from Sunday October 16 through = Wednesday October 19, = 2005 at the Omni Shoreham Hotel in Washington = DC.

Registration for the MPLS 2005 International Conference is now open, with only FOUR = days left to take advantage of the discounted registration rates [early = registration discount cut off date is September 17]. Go to = www.mpls2005.com/registration.htm= to register.

Take advantage of this = opportunity and register NOW!

Conference Program:

Sunday, October 16

10:30 - 12:00 = am

Tutorial 1: Scaling Considerations for MPLS = Protocols and Applications - Ina Minei, Juniper = Networks

1:00 - 2:30 = pm

Tutorial 2: Inter-Provider MPLS = -Azhar Sayeed and Santiago = Alvarez, Cisco Systems

2:45 - 4:15 = pm

Tutorial 3: Metro = Ethernet

4:30 - 6:00 = pm

Tutorial 4: MPLS Network Operations and Management = - Peter Busschbach, Lucent Technologies

 

Monday, October 17

8:30 - 10:15 = am

·     Introduction
·     Opening Speech
·     Keynote Speech
·     MPLS, GMPLS and Pseudowires: The Need for Cooperation Between Standards = Bodies - Adrian Farrel, IETF

Break & Exhibits

10:45 am - 12:30 = pm
Pseudowires: Extending the = reach

·     Interprovider Pseudowires - Luca Martini, Cisco Systems
·     Multi-Hop PWs: "A small step = for PWs , a giant step for Metro Convergence?" - David McDysan , MCI = & Florin Balus , Nortel Networks
·     Multi segment Pseudo-Wires using = RSVP-TE - Ron Bonica , Juniper Networks
·     OAM for Multihop Pseudowires - = Thomas Nadeau, Cisco Systems

Lunch & = Exhibits

2:00 - 3:30 = pm
What do we want from multicast = MPLS and Point-to-Multipoint Traffic Engineering?

·     MPLS P2MP: from the needs = definition to the solutions description - Renaud = Moignard, = France Telecom
·     Design Considerations for = Multicast MPLS/BGP VPNs - Maria Napierala, ATT Labs
·     Carrier-Grade Multicast = Deployment in MPLS Backbones - Nicolai Leymann, T-Systems
·     Multicast VPN Deployment = Scenarios and Service Requirements - Seisho Yasukawa, NTT

Break & = Exhibits

4:00 - 5:00 = pm
Ethernet in the Metro Network - = What is the role for MPLS?

·     Metro Ethernet and MPLS - Kireeti Kompella, Juniper Networks
·     MPLS, Ethernet and the Metro - = David Allan, Nortel Networks
·     GMPLS Controlled Ethernet = Networks - Loa Andersson, Acreo

5:00 - 6:00 = pm
Panel: Advanced Services Using = MPLS

Panelists from selected ISP/Carriers

6:00 - 7:30 = pm: = Reception & Exhibits
Reception Hosted by Avici Systems

 

Tuesday, October 18

8:30 - 10:15 = am
Broadband Services – = Enabling the future

·     Broadband, the Next Revolution - What it Means to an = MPLS Network - Sangeeta Anand, Cisco Systems
·     Realizing services across regions utilizing dissimilar convergence layers - Andy Malis and Jonathan Sadler, Tellabs
·     Broadband Services using MPLS - Kurt Melden, Juniper
·     Enhanced architecture model that deploys MPLS-enabled Ethernet-based Aggregation in DSL networks for Triple Play services - = Sunil Khandekar, Alcatel
·     Subscriber Aware MPLS for Broadband Services - Arpit = Joshipura, Redback Networks

Break & = Exhibits

10:45 - 12:30 = am
Building blocks for Advanced = Services in MPLS Networks

·     Combining RSVP and MPLS for Scalable Admission Control - = Bruce Davie, Cisco Systems
·     Assuring QoS: Delivering Real Time Services with MPLS = Networks - Sridhar Ramachandran, Nextone
·     LSP Hierarchy in MPLS networks - Arthi Ayyangar, Juniper Networks
·     VPN = Route Reflector Architectures and Operational Impacts - Eric Brendel, Chiaro = Networks
·     Secure MPLS Backbone Design to Support IMS - Scott = Poretsky , Reef Point Systems

Lunch & Exhibits 12:30 – 2:00 pm

2:00 - 3:30 pm =
Interworking MPLS and GMPLS =

·     Applicability of GMPLS to Packet LSPs and MPLS to GMPLS Migration Methods - Dimitri Papadimitriou, Alcatel
·     Investigation of deployment scenarios for a GMPLS = network migrating into an existing IP/MPLS network - Tomohiro Otani, Kenichi = Ogaki, Hideaki Tanaka (KDDI), Mallik Tatipamula & Zafar Ali (Cisco)
·     MPLS and GMPLS interworking - Kohei Shiomoto, NTT
·     Operational, Deployment and Interworking Considerations = for GMPLS Technology - Zafar Ali, Cisco Systems

Break & = Exhibits

4:00 - 5:00 pm =
MPLS in = Enterprise Networks - Experiences from Deployment =

·     Deploying, interworking and operating L2 and L3 MPLS = VPNs - MPLS deployment experience: scaling, performance and security - Peter Himmelberger, CSC
·     Enterprise = Customer Deployment - Tom McKinney, Cisco Systems
·     An All Encompassing MPLS-Enabled VPN - Lee Jalali, = Sprint

5:00 - 6:00 = pm
Vendor’s Panel Session: LDP = vs. RSVP-TE

Panelists from selected vendors

Exhibits 6:00 - 7:30 pm

 

Wednesday, October 19

8:30 - 10:00 = am
Generalized MPLS in the Optical Network

·     Overview of GMPLS interworking test in Japan and NICT = Keihana GMPLS E-NNI trials - Naoaki Yamanaka
·     Next Generation IP/Optical Integrated Network in KDDI - Masatoshi Suzuki and Tomohiro Otani, KDDI
·     Extending GMPLS for Pure Photonic Networks - Don Fedyk = & Vik Saxena Nortel Networks & Comcast
·     Dynamic optical link preemption based on GMPLS traffic engineering - Shinya Tanaka , = Japan Telecom
·     The Unified Optical Control Plane: The Time is Now - = Vijay Pandian, Sycamore Networks

Break & = Exhibits

10:45 - 12:30 = am
Experiences from the Front Line - = Building MPLS Networks for Advanced and Triple-play Services =

·     IPv6 and MPLS - Daniel Awduche, MCI
·     Case Study: Building A Successful Full Packet Voice = Network and IP Network - Hamid Laamouri & = Cristina Gentili , WANDL & Telecom Italia
·     IP/MPLS for Live Broadcast Video Applications, Ryan = Korte, WilTel Communications
·     Telenor's pan- nordic NG multiservice network - Lei = Wang, Telenor
·     Some Considerations in the SLA = Delivery for MPLS Enabled Networks - Roman Krzanowski , Verizon

Lunch & Exhibits 12:30 – 2:00 pm

2:00 - 3:00 = pm
Supporting multicast traffic in = MPLS networks

·     Multicast LDP - IJsbrand Wijnands, Cisco Systems
·     Next-Generation Solutions for Multicast in 2547 VPNs and = VPLS - Rahul Aggarwal, Juniper Networks
·     VPLS Multicast challenges and options, Marc Lasserre, Riverstone

Break

3:15 - 4:45 = pm
Multi-domain MPLS - Now we can all = talk together

·     PCE (Path Computation Element) models: architecture and applications - JP Vasseur, Cisco Systems
·     Advanced MPLS L3 VPN deployment and challenges - = Inter-provider VPNs, VoIP support, and MVPNs - Luyuan Fang, AT&T Labs
·     Inter-AS Security Factors and Best Practice Guidelines, = Monique Morrow, Cisco Systems
·     Multi-layer traffic engineering with PCE in MPLS/GMPLS = networks - Eiji Oki, NTT

 

------=_NextPart_000_000D_01C5B857.901C5A90-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 12 Sep 2005 19:52:09 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-alarm-spec-03.txt Message-Id: Date: Mon, 12 Sep 2005 15:50:02 -0400 --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 : GMPLS - Communication of Alarm Information Author(s) : L. Berger Filename : draft-ietf-ccamp-gmpls-alarm-spec-03.txt Pages : 18 Date : 2005-9-12 This document describes an extension to Generalized MPLS (Multi- Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object. This document updates RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with the procedures specified in RFC 3473. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-alarm-spec-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-ietf-ccamp-gmpls-alarm-spec-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: <2005-9-12110024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-alarm-spec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-alarm-spec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-12110024.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Sep 2005 14:46:10 +0000 Message-ID: <064901c5b54d$5cce2450$93849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Wijnen, Bert \(Bert\)" , , "Thomas D. Nadeau" , Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Fri, 9 Sep 2005 15:43:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Many thanks to David and Bert, and especially Joan. Tom and I are wading through the comments at the moment and will send a reply as soon as we can. It seems that a good proportion of the requested changes are editorial, some are important boilerplate, and a few are related to ASN.1/SNMP. We should be able to clear them up very quickly. Bert is right that we will need new versions of the documents. Not sure if there is anything for WG discussion, but we will probably want to hold another last call just because of the number of changes. Cheers, Adrian ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: ; ; ; Sent: Friday, September 09, 2005 11:32 AM Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > [bcc to David HArrington, he also did submit comments] > [David, I am not sure if you are on WG mailing list] > > Joan, thank you very much for your reviews. > > It seems to me that some WG discussion may be needed and > I would also expect new revisions of the 3 documents. > > Alex and WG chairs, > I have put the comments in the I-D tracker as well. > > Bert > > > -----Original Message----- > > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > > Sent: Friday, September 09, 2005 03:37 > > To: tnadeau@cisco.com; adrian@olddog.co.uk; ccamp@ops.ietf.org > > Cc: bwijnen@lucent.com; jcucchiara@mindspring.com > > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > > > > > > > > HI Tom and Adrian, > > > > This email has 2 parts: First are comments which > > pertain to the 3 GMPLS MIB docs under review. > > I thought this was easier than repeating these > > comments 3 times. > > > > Following are additional comments on > > draft-ietf-ccamp-gmpls-tc-mib-07.txt. > > > > thanks, Joan > > > > > > > > General comments for all 3 drafts: > > ================================================ > > 1*) Suggestion only: > > When submitting these 3 GMPLS MIBs > > you may want to ask RFC-editor > > to give the GMPLS-TC-STD-MIB document the first > > RFC number, and that all 3 GMPLS MIB docs appear > > contiguously numbered. > > > > If you would like to incorporate this suggestion > > then you'd need to add a paragraph to the > > IANA Considerations section and put the usual > > RFC-editor disclaimers around your request, such > > as: > > > > > > (Note to RFC-Editor:) > > We request that you assign the first RFC number > > to the draft-ietf-ccamp-gmpls-tc-mib, and also > > assign contiguous numbers to all three GMPLS MIB > > docs, i.e. draft-ietf-ccamp-gmpls-tc-mib, > > draft-ietf-ccamp-gmpls-lsr-mib, and > > draft-ietf-ccamp-gmpls-te-mib. > > (Please remove this note prior to publication.) > > > > > > > > 2*) Table of Contents is incorrect, please > > regenerate it, (e.g. The SNMP Management Framework > > should be The Internet-Standard Management Framework). > > > > > > 3*) Question if these documents should have a > > contributors section. It violates the guidelines > > of "RFC Editorial Guidelines and Procedures" > > http://www.rfc-editor.org/policy.html#policy.auth2 > > > > There are many people listed under > > Authors but not listed on the front page, > > so how about adding a Contributors Section? > > > > 4*) Tom's Contact info needs to be updated to > > Boxborough. > > > > > > 5*) would be clearer to be consistent about > > referring to MIB modules and always use the entire MIB name > > and site the reference: > > e.g. MPLS LSR MIB module or LSR MIB module, > > should be MPLS-LSR-STD-MIB module [RFC3813] > > > > e.g. GMPLS LSR MIB module, should be > > GMPLS-LSR-STD-MIB module [RFCXXX] (NOTE to RFC-Editor: > > please fill in XXX with the RFC name for > > draft-ietf-ccamp-gmpls-lsr-mib and remove this note.) > > > > > > 6*) The term "extends" is used and since this term is applied > > to GMPLS interfaces, the more appropriate phrase is > > 'sparse augments'. Please change this in the text. > > > > > > > > 7*) ORGANIZATION, please add IETF > > as in "IETF Common Control and ...." > > > > > > 8*) DESCRIPTION > > Please change the first paragraph to: > > > > Copyright (C) The Internet Society (2005). This > > version of > > this MIB module is part of RFC XXX; see the RFC > > itself for > > full legal notices. > > > > The exception to this is the IANA-GMPLS-MIB module, which should > > include: > > > > "Copyright (C) The Internet Society (2005). The initial version > > of this MIB module was published in RFC XXXX. For full legal > > notices see the RFC itself. Supplementary information > > may be available on: > > http://www.ietf.org/copyrights/ianamib.html > > > > > > > > > > 9*) Please make sure to ask RFC-Editor to remove comments > > prior to publication, e.g. > > > > -- RFC Editor's Note (to be removed prior to publication): > > > > "Initial version published as part of RFC XXXX." > > -- replace XXX with actual RFC number & remove this note. > > > > > > 10*) Acknowledgements Section > > Please start off this section with: > > > > This document is a product of the CCAMP Working Group. > > > > and remove: > > > > This draft is the work of the five authors listed in the next > > section. > > > > > > 11*) Please change "Informational References" > > to "Informative References" > > > > 12*) There are a number of references (as discovered by > > Bert) that aren't in the RFC expected format. > > Please review all the references in this document and > > the other GMPLS MIB docs. > > Please see comments in the review of the > > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > > examples of references in the RFC format. > > > > > > > > draft-ietf-ccamp-gmpls-tc-mib-07.txt > > ====================================== > > > > Section 3. GMPLS Textual Conventions MIB Definitions > > --------------------------------------------------- > > > > 1) GmplsFreeformLabel TC > > > > 1a) Could the REFERENCE include section(s)? > > I suspect that this is referring to the Generalized Label > > described in section 3.2.1, is this correct? > > > > 1b) Please explain why this is 0..64 ? > > RFC3471 states that the Generalized label can be > > variable length, so wondering if this should be made > > larger? > > > > 1c) The DESCRIPTION needs a little work: > > DESCRIPTION > > "This value represents a freeform generalized MPLS Label. This > > can be used to represent label types which are not standard in > > the drafts. It may also be used by systems that do not wish to > > represent the labels using the specific label types." > > > > Please reword to something like: > > > > "This value represents a freeform GMPLS label. A freeform GMPLS > > label is specified by the system which uses it. In > > other words, > > the freeform GMPLS label is not a standard GMPLS label type, > > but is created by the system which uses it." > > > > > > 2) GmplsGeneralizedLabelTypes TC > > > > > > 2a) Could you change the name of the TC > > GmplsGeneralizedLabelTypes to > > > > GmplsLabelType > > > > It is more appropriate to have it singular when > > Imported and used in other MIBs, and dropping the > > word Generalized, because you already have the > > prefix Gmpls. > > > > 2b) Could the SYNTAX order be changed? > > > > Currently: > > > > SYNTAX INTEGER { > > gmplsMplsLabel(1), > > gmplsPortWavelengthLabel(2), > > gmplsFreeformGeneralizedLabel(3), > > gmplsSonetLabel(4), > > gmplsSdhLabel(5), > > gmplsWavebandLabel(6) > > } > > > > Proposed (NOTE also some of the names have been changed): > > > > > > SYNTAX INTEGER { > > gmplsFreeformLabelOrOther(1), > > gmplsMplsLabel(2), > > gmplsPortAndWavelengthLabel(3), > > gmplsSonetLabel(4), > > gmplsSdhLabel(5), > > gmplsWavebandLabel(6) > > } > > > > > > > > Section 4. Security Considerations > > ------------------------------------- > > > > 3) Change MPLS to GMPLS in the following statement: > > > > "This module does not define any management objects. Instead, it > > defines a set of textual conventions which may be used by > > other MPLS > > MIB modules to define management objects." > > > > > > Section 5. IANA Considerations > > ------------------------------------- > > > > 4) Section 5. IANA Considerations > > RFC Editor's Note (to be removed prior to publication): > > the IANA is requested to assign a value for "XXX" under > > the mib-2/mplsStdMIB subtree and to record the assignment > > in the SMI Numbers registry. > > When the assignment has been made, the RFC Editor is > > asked to replace the "XXX" (here and in the MIB module) with > > the assigned value and to remove this note. > > > > > > > > 5) Section 5. IANA Considerations > > > > Please remove the last sentence of this section: > > > > "The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB." > > > > > > Section 6.2 Informational References. > > --------------------------------------- > > > > 6) Section 6.2 Informational References. > > Please change to "Informative". > > > > 7) I believe the following references should be moved > > to the Normative section: > > > > [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), > > "Generalized MPLS Signaling - CR-LDP Extensions", > > RFC 3472, January 2003. > > > > [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - > > RSVP-TE Extensions", RFC 3473 January 2003. > > > > [RFC3811] Nadeau, T. and J. Cucchiara, "Definition > > of Textual > > Conventions and for Multiprotocol Label Switching > > (MPLS) Management", RFC 3811, June 2004. > > > > [RFC3945] Mannie, E. (Editor), "Generalized Multiprotocol > > Label Switching (GMPLS) Architecture", RFC 3945, > > October 2004. > > > > [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), > > "Generalized Multi-Protocol Label Switching > > Extensions for SONET and SDH Control", > > draft-ietf-ccamp-gmpls-sonet-sdh, work in > > progress. > > > > (the above is now RFC 3946) > > [GMPLS-SONET] Mannie, E. and D. Papadimitriou, > > "Generalized Multi- > > Protocol Label Switching (GMPLS) Extensions for > > Synchronous Optical Network (SONET) and Synchronous > > Digital Hierarchy (SDH) Control", RFC 3946, October > > 2004. > > > > > > Also, as previously mentioned, need to check > > on the format of these References. > > Please see comments in the review of the > > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > > examples of references in the RFC format. > > > > > > --- the end --- > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Sep 2005 10:33:41 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507FC55C7@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: jcucchiara@mindspring.com, tnadeau@cisco.com, adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: RE: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Date: Fri, 9 Sep 2005 12:32:12 +0200 MIME-Version: 1.0 Content-Type: text/plain [bcc to David HArrington, he also did submit comments] [David, I am not sure if you are on WG mailing list] Joan, thank you very much for your reviews. It seems to me that some WG discussion may be needed and I would also expect new revisions of the 3 documents. Alex and WG chairs, I have put the comments in the I-D tracker as well. Bert > -----Original Message----- > From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com] > Sent: Friday, September 09, 2005 03:37 > To: tnadeau@cisco.com; adrian@olddog.co.uk; ccamp@ops.ietf.org > Cc: bwijnen@lucent.com; jcucchiara@mindspring.com > Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt > > > > HI Tom and Adrian, > > This email has 2 parts: First are comments which > pertain to the 3 GMPLS MIB docs under review. > I thought this was easier than repeating these > comments 3 times. > > Following are additional comments on > draft-ietf-ccamp-gmpls-tc-mib-07.txt. > > thanks, Joan > > > > General comments for all 3 drafts: > ================================================ > 1*) Suggestion only: > When submitting these 3 GMPLS MIBs > you may want to ask RFC-editor > to give the GMPLS-TC-STD-MIB document the first > RFC number, and that all 3 GMPLS MIB docs appear > contiguously numbered. > > If you would like to incorporate this suggestion > then you'd need to add a paragraph to the > IANA Considerations section and put the usual > RFC-editor disclaimers around your request, such > as: > > > (Note to RFC-Editor:) > We request that you assign the first RFC number > to the draft-ietf-ccamp-gmpls-tc-mib, and also > assign contiguous numbers to all three GMPLS MIB > docs, i.e. draft-ietf-ccamp-gmpls-tc-mib, > draft-ietf-ccamp-gmpls-lsr-mib, and > draft-ietf-ccamp-gmpls-te-mib. > (Please remove this note prior to publication.) > > > > 2*) Table of Contents is incorrect, please > regenerate it, (e.g. The SNMP Management Framework > should be The Internet-Standard Management Framework). > > > 3*) Question if these documents should have a > contributors section. It violates the guidelines > of "RFC Editorial Guidelines and Procedures" > http://www.rfc-editor.org/policy.html#policy.auth2 > > There are many people listed under > Authors but not listed on the front page, > so how about adding a Contributors Section? > > 4*) Tom's Contact info needs to be updated to > Boxborough. > > > 5*) would be clearer to be consistent about > referring to MIB modules and always use the entire MIB name > and site the reference: > e.g. MPLS LSR MIB module or LSR MIB module, > should be MPLS-LSR-STD-MIB module [RFC3813] > > e.g. GMPLS LSR MIB module, should be > GMPLS-LSR-STD-MIB module [RFCXXX] (NOTE to RFC-Editor: > please fill in XXX with the RFC name for > draft-ietf-ccamp-gmpls-lsr-mib and remove this note.) > > > 6*) The term "extends" is used and since this term is applied > to GMPLS interfaces, the more appropriate phrase is > 'sparse augments'. Please change this in the text. > > > > 7*) ORGANIZATION, please add IETF > as in "IETF Common Control and ...." > > > 8*) DESCRIPTION > Please change the first paragraph to: > > Copyright (C) The Internet Society (2005). This > version of > this MIB module is part of RFC XXX; see the RFC > itself for > full legal notices. > > The exception to this is the IANA-GMPLS-MIB module, which should > include: > > "Copyright (C) The Internet Society (2005). The initial version > of this MIB module was published in RFC XXXX. For full legal > notices see the RFC itself. Supplementary information > may be available on: > http://www.ietf.org/copyrights/ianamib.html > > > > > 9*) Please make sure to ask RFC-Editor to remove comments > prior to publication, e.g. > > -- RFC Editor's Note (to be removed prior to publication): > > "Initial version published as part of RFC XXXX." > -- replace XXX with actual RFC number & remove this note. > > > 10*) Acknowledgements Section > Please start off this section with: > > This document is a product of the CCAMP Working Group. > > and remove: > > This draft is the work of the five authors listed in the next > section. > > > 11*) Please change "Informational References" > to "Informative References" > > 12*) There are a number of references (as discovered by > Bert) that aren't in the RFC expected format. > Please review all the references in this document and > the other GMPLS MIB docs. > Please see comments in the review of the > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > examples of references in the RFC format. > > > > draft-ietf-ccamp-gmpls-tc-mib-07.txt > ====================================== > > Section 3. GMPLS Textual Conventions MIB Definitions > --------------------------------------------------- > > 1) GmplsFreeformLabel TC > > 1a) Could the REFERENCE include section(s)? > I suspect that this is referring to the Generalized Label > described in section 3.2.1, is this correct? > > 1b) Please explain why this is 0..64 ? > RFC3471 states that the Generalized label can be > variable length, so wondering if this should be made > larger? > > 1c) The DESCRIPTION needs a little work: > DESCRIPTION > "This value represents a freeform generalized MPLS Label. This > can be used to represent label types which are not standard in > the drafts. It may also be used by systems that do not wish to > represent the labels using the specific label types." > > Please reword to something like: > > "This value represents a freeform GMPLS label. A freeform GMPLS > label is specified by the system which uses it. In > other words, > the freeform GMPLS label is not a standard GMPLS label type, > but is created by the system which uses it." > > > 2) GmplsGeneralizedLabelTypes TC > > > 2a) Could you change the name of the TC > GmplsGeneralizedLabelTypes to > > GmplsLabelType > > It is more appropriate to have it singular when > Imported and used in other MIBs, and dropping the > word Generalized, because you already have the > prefix Gmpls. > > 2b) Could the SYNTAX order be changed? > > Currently: > > SYNTAX INTEGER { > gmplsMplsLabel(1), > gmplsPortWavelengthLabel(2), > gmplsFreeformGeneralizedLabel(3), > gmplsSonetLabel(4), > gmplsSdhLabel(5), > gmplsWavebandLabel(6) > } > > Proposed (NOTE also some of the names have been changed): > > > SYNTAX INTEGER { > gmplsFreeformLabelOrOther(1), > gmplsMplsLabel(2), > gmplsPortAndWavelengthLabel(3), > gmplsSonetLabel(4), > gmplsSdhLabel(5), > gmplsWavebandLabel(6) > } > > > > Section 4. Security Considerations > ------------------------------------- > > 3) Change MPLS to GMPLS in the following statement: > > "This module does not define any management objects. Instead, it > defines a set of textual conventions which may be used by > other MPLS > MIB modules to define management objects." > > > Section 5. IANA Considerations > ------------------------------------- > > 4) Section 5. IANA Considerations > RFC Editor's Note (to be removed prior to publication): > the IANA is requested to assign a value for "XXX" under > the mib-2/mplsStdMIB subtree and to record the assignment > in the SMI Numbers registry. > When the assignment has been made, the RFC Editor is > asked to replace the "XXX" (here and in the MIB module) with > the assigned value and to remove this note. > > > > 5) Section 5. IANA Considerations > > Please remove the last sentence of this section: > > "The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB." > > > Section 6.2 Informational References. > --------------------------------------- > > 6) Section 6.2 Informational References. > Please change to "Informative". > > 7) I believe the following references should be moved > to the Normative section: > > [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), > "Generalized MPLS Signaling - CR-LDP Extensions", > RFC 3472, January 2003. > > [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - > RSVP-TE Extensions", RFC 3473 January 2003. > > [RFC3811] Nadeau, T. and J. Cucchiara, "Definition > of Textual > Conventions and for Multiprotocol Label Switching > (MPLS) Management", RFC 3811, June 2004. > > [RFC3945] Mannie, E. (Editor), "Generalized Multiprotocol > Label Switching (GMPLS) Architecture", RFC 3945, > October 2004. > > [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), > "Generalized Multi-Protocol Label Switching > Extensions for SONET and SDH Control", > draft-ietf-ccamp-gmpls-sonet-sdh, work in > progress. > > (the above is now RFC 3946) > [GMPLS-SONET] Mannie, E. and D. Papadimitriou, > "Generalized Multi- > Protocol Label Switching (GMPLS) Extensions for > Synchronous Optical Network (SONET) and Synchronous > Digital Hierarchy (SDH) Control", RFC 3946, October > 2004. > > > Also, as previously mentioned, need to check > on the format of these References. > Please see comments in the review of the > draft-ietf-ccamp-gmpls-lsr-mib-08.txt for > examples of references in the RFC format. > > > --- the end --- > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Sep 2005 01:57:14 +0000 Message-Id: <3.0.1.32.20050908215948.014706d4@pop.mindspring.com> Date: Thu, 08 Sep 2005 21:59:48 -0400 To: tnadeau@cisco.com,adrian@olddog.co.uk,ccamp@ops.ietf.org From: jcucchiara@mindspring.com Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt Cc: bwijnen@lucent.com,jcucchiara@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Tom and Adrian, Here are some comments on draft-ietf-ccamp-gmpls-te-mib-09.txt. All 3 docs show a good deal of work. -Joan draft-ietf-ccamp-gmpls-te-mib-09.txt ====================================== Section 1.1 Migration Strategy ------------------------------ 1) Please remove "and OBJECT-IDENTIFIERS" Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811] and [GMPLSTCMIB]. Section 5.4 gmplsTunnelCHoptable --------------------------------- 2) Please capitalize Table in the Section's title. Section 8. GMPLS Traffic Engineering MIB Module ----------------------------------------------- smicngPRO gives the following: W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should have SIZE specified W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is identical W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is identical W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is identical W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax is identical W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", syntax is identical Disconnect of numbering in the Conformance Section \-3 gmplsTeConformance \-v-1 gmplsTeGroups | \-v-1 gmplsTunnelGroup 2 is missing | |-3 gmplsTunnelSignaledGroup | |-4 gmplsTunnelScalarGroup | |-5 gmplsTunnelIsIntfcGroup | |-6 gmplsTunnelIsNotIntfcGroup | |-7 gmplsTunnelOptionalGroup | \-8 gmplsTeNotificationGroup 3) gmplsTunnelsConfigured OBJECT-TYPE SYNTAX Unsigned32 SYNTAX should be Gauge32 4) gmplsTunnelsActive OBJECT-TYPE SYNTAX Unsigned32 SYNTAX should be Gauge32 5) gmplsTunnelTable DESCRIPTION "The row status of an entry in this table is controlled by mplsTunnelRowStatus in the corresponding entry in mplsTunnelTable. That is, it is not permitted to create a row in this table, nor to modify an existing row, when the corresponding mplsTunnelRowStatus has value active(1).... The sentence beginning with "That is," is awkward. Could you say something like: A row in this table is created when a row is created in the mplsTunnelTable. Entries in this table cannot be modified when the corresponding mplsTunnelRowStatus has a value of active(1). The exception.... Please also update this other places in this MIB (e.g gmplsTunnelHopTable). 6) gmplsTunnelEntry DESCRIPTION: "... An entry can be created by a network administrator or by an SNMP agent as instructed by a signaling protocol." Please change the above to: "An entry can be created by a network administrator via SNMP SET commands, or by the network management entity as instructed by a signaling protocol." 7) gmplsTunnelUnnumIf What IF-MIB object are referring to in the DESCRIPTION? Could you state which object in the description? 8) gmplsTunnelAttributes Could you specify what happens when the bit is set (i.e. 1) vs. 0? 9) gmplsTunnelLSPEncoding The DESCRIPTION states: ...A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling is not in use. Some objects in this MIB module may be of use for MPLS signaling extensions that do not use GMPLS signaling. By setting this object to 'tunnelLspNotGmpls', an application may indicate that only those objects meaningful in MPLS should be examined.... I believe that such objects should be put in to an MPLS MIB module and not included in this GMPLS MIB module. This is also true with the gmplsTunnelErrorTable. 10) gmplsTunnelLinkProtection Same comment as with gmplsTunnelAttributes. 11) gmplsTunnelPathComp DESCRIPTION states: This object deprecates mplsTunnelHopEntryPathComp." The term "deprecates" is loaded. Perhaps something like, this object takes precedence over mplsTunnelHopEntryPathComp. In other words, for GMPLS tunnels, the value of mplsTunnelHopEntryPathComp is meaningless. 12) gmplsTunnelUpNotRecip Need to use InetAddressType and InetAddress. IpAddress is not used in MIBs anymore. Please be sure to support both v4 and v6 IP address Types. If you can't support v6 for some reason, that should be stated clearly. Please change the name of this object to: gmplsTunnelUpstreamRecipientForNotify 13) gmplsTunnelDownNotRecip Same comment as above wrt to IpAddress. Please change the name to gmplsTunnelDownstreamRecipientForNotify 14) gmplsTunnelAdminStatusFlags (please see comments regarding the name of this TC and make adjustments to the name and DESCRIPTION of this object as appropriate). 15) gmplsTunnelExtraParamsPtr OBJECT-TYPE This object does not seem appropriate for this MIB. It would seem an enterprise MIB could do something like this (and possibly not use a RowPointer) so please explain what the intention is. 16) gmplsTunnelHopTable OBJECT-TYPE The storage type for an entry in this table is inherited from mplsTunnelHopStorageType in the corresponding entry in mplsTunnelHopTable. Please change to: The storage type for this entry is given by the value of mplsTunnelHopStorageType in the corresponding entry in the mplsTunnelHopTable. 17) gmplsTunnelHopExpLabel OBJECT-TYPE DESCRIPTION "If gmplsTunnelHopLabelStatuses object indicates that a forward label is present and gmplsTunnelHopExpLabelPtr contains the value zeroDotZero, then the label to use on this hop is found in object encoded within a 32-bit integer." Think the last part of this sentence is awkward: ...to use on this hop is represented by the value of this object. 18) gmplsTunnelHopExpLabel and gmplsTunnelHopExpLabelPtr Need to add the word "Forward" in here as in gmplsTunnelHopExpForwardLabel and gmplsTunnelHopExpForwardLabelPtr That way it will be consistent with the Reverse counterparts. 19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpRvrsLabelPtr Please change Rvrs to Reverse. 20) gmplsTunnelHopLabelStatuses and gmplsTunnelARHopLabelStatuses Please change Statuses to State. 21) gmplsTunnelARHopExpLable and gmplsTunnelARHopExpLabelPtr Need to add the word "Forward" in here as in gmplsTunnelARHopExpForwardLabel and gmplsTunnelARHopExpForwardLabelPtr 22) gmplsTunnelARHopExpRvrsLabel and gmplsTunnelARHopExpRvrsLabelPtr Please change Rvrs to Reverse 23) gmplsTunnelARHopProtection OBJECT-TYPE Please add what the BIT set (i.e. 1) vs. 0 means in the DESCRIPTION. 24) gmplsTunnelCHopLabelTable objects Similar comments regarding the objects in this table to those above with regard to naming conventions (Forward and Reverse) and DESCRIPTIONs. Will not repeat the details, please refer to above comments on the prior 2 tables. 25) gmplsTunnelReversePerfTable Please add to the DESCRIPTION how a user knows if this is a bidirectional tunnel (i.e. what object or objects in the gmplsTunnelTable need to have what values?). 26) gmplsTunnelReversePerfPackets Does this object represent the 32-bit value of the least significant part of the 64-bit value (which is contained in gmplsTunnelReversePerfHCPackets)? 27) gmplsTunnelReversePerfBytes Does this object represent the 32-bit value of the least significant part of the 64-bit value (which is contained in gmplsTunnelReversePerfHCBytes)? 28) gmplsTunnelErrorTable OBJECT-TYPE Since this table applies to MPLS, it should be put in a separate MIB module which is MPLS specific. The prefix of gmpls could be confusing. 29) gmplsTunnelErrorTLVs OBJECT-TYPE Need to add a variable size to this string. When the string size is 0 that would indicate that no TLVs are present, so the DESCRIPTION should be modified to reflect this. 30) gmplsTunnelErrorHelpString OBJECT-TYPE SYNTAX DisplayString DisplayString is not used in newer MIBs because it does not meet internationalization standards, better to use SnmpAdminString or something which meets internationalization standards. 31) Compliance Please move some of the following comment in the DESCRIPTION of gmplsTeModuleFullCompliance -- The mandatory group has to be implemented by all LSRs that -- originate, terminate or act as transit for TE-LSPs/tunnels. -- In addition, depending on the type of tunnels supported, other -- groups become mandatory as explained below. 32) gmplsTunnelUnnumIf does not appear in the ReadOnly compliance and it probably should. Section 11.2.1. IANA-GMPLS-MIB Definition ----------------------------------------- 33) Please change the name of this MIB to IANA-GMPLS-TC-MIB and instead of: ianaGmpls MODULE-IDENTITY please use: ianaGmplsTcMIB MODULE-IDENTITY 34) Please add the following to the DESCRIPTION: "Copyright (C) The Internet Society (2005). The initial version of this MIB module was published in RFC XXXX. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html 35) Please change GMPLS-TE-MIB's to GMPLS-TE-STD-MIB's [RFCXXX] (RFC-Editor please fill in the XXX based on the RFC number for draft-ietf-ccamp-gmpls-te-mib and remove this note) in the DESCRIPTION clauses of ALL TCs. 36) Please change the name IANAGmplsLSPEncoding to IANAGmplsLSPEncodingType. (more closely matches what's on IANA's website now) 37) Please change the name IANAGmplsGPid to IANAGmplsGeneralizedPid 38) I believe that the TC IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION should be put in the GMPLS-TC-STD-MIB or should just remain in the GMPLS-TE-STD-MIB. The reason is that this is not an assigned numbers list maintained by IANA, so should not be in the IANA GMPLS MIB. If I am incorrect about this please let me know, but I didn't see an IANA maintained Administrative Status Information enum. Additionally, this should be renamed to GmplsAdminStatusInformation which more closely matches rfc3471. 39) Several comments on the SYNTAX clause: 40a) smicngPRO gives the error E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS must be in contiguous positions SYNTAX BITS { delInProgress (0), adminDown (1), testing (2), reflect (31) } RFC2578 specifies that BITS should be contiguous (although there are exceptions to this, but this object does not seem to be an exception). Could delInProgress, be renamed to deleteInProgress ? Could adminDown be renamed to administrativelyDown? These names more closely match 3471. 40b) Please put in the specific section number on this reference (section 8?). -- the end -- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 09 Sep 2005 01:34:51 +0000 Message-Id: <3.0.1.32.20050908213717.014708c8@pop.mindspring.com> Date: Thu, 08 Sep 2005 21:37:17 -0400 To: tnadeau@cisco.com,adrian@olddog.co.uk,ccamp@ops.ietf.org From: jcucchiara@mindspring.com Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-07.txt Cc: bwijnen@lucent.com,jcucchiara@mindspring.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" HI Tom and Adrian, This email has 2 parts: First are comments which pertain to the 3 GMPLS MIB docs under review. I thought this was easier than repeating these comments 3 times. Following are additional comments on draft-ietf-ccamp-gmpls-tc-mib-07.txt. thanks, Joan General comments for all 3 drafts: ================================================ 1*) Suggestion only: When submitting these 3 GMPLS MIBs you may want to ask RFC-editor to give the GMPLS-TC-STD-MIB document the first RFC number, and that all 3 GMPLS MIB docs appear contiguously numbered. If you would like to incorporate this suggestion then you'd need to add a paragraph to the IANA Considerations section and put the usual RFC-editor disclaimers around your request, such as: (Note to RFC-Editor:) We request that you assign the first RFC number to the draft-ietf-ccamp-gmpls-tc-mib, and also assign contiguous numbers to all three GMPLS MIB docs, i.e. draft-ietf-ccamp-gmpls-tc-mib, draft-ietf-ccamp-gmpls-lsr-mib, and draft-ietf-ccamp-gmpls-te-mib. (Please remove this note prior to publication.) 2*) Table of Contents is incorrect, please regenerate it, (e.g. The SNMP Management Framework should be The Internet-Standard Management Framework). 3*) Question if these documents should have a contributors section. It violates the guidelines of "RFC Editorial Guidelines and Procedures" http://www.rfc-editor.org/policy.html#policy.auth2 There are many people listed under Authors but not listed on the front page, so how about adding a Contributors Section? 4*) Tom's Contact info needs to be updated to Boxborough. 5*) would be clearer to be consistent about referring to MIB modules and always use the entire MIB name and site the reference: e.g. MPLS LSR MIB module or LSR MIB module, should be MPLS-LSR-STD-MIB module [RFC3813] e.g. GMPLS LSR MIB module, should be GMPLS-LSR-STD-MIB module [RFCXXX] (NOTE to RFC-Editor: please fill in XXX with the RFC name for draft-ietf-ccamp-gmpls-lsr-mib and remove this note.) 6*) The term "extends" is used and since this term is applied to GMPLS interfaces, the more appropriate phrase is 'sparse augments'. Please change this in the text. 7*) ORGANIZATION, please add IETF as in "IETF Common Control and ...." 8*) DESCRIPTION Please change the first paragraph to: Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXX; see the RFC itself for full legal notices. The exception to this is the IANA-GMPLS-MIB module, which should include: "Copyright (C) The Internet Society (2005). The initial version of this MIB module was published in RFC XXXX. For full legal notices see the RFC itself. Supplementary information may be available on: http://www.ietf.org/copyrights/ianamib.html 9*) Please make sure to ask RFC-Editor to remove comments prior to publication, e.g. -- RFC Editor's Note (to be removed prior to publication): "Initial version published as part of RFC XXXX." -- replace XXX with actual RFC number & remove this note. 10*) Acknowledgements Section Please start off this section with: This document is a product of the CCAMP Working Group. and remove: This draft is the work of the five authors listed in the next section. 11*) Please change "Informational References" to "Informative References" 12*) There are a number of references (as discovered by Bert) that aren't in the RFC expected format. Please review all the references in this document and the other GMPLS MIB docs. Please see comments in the review of the draft-ietf-ccamp-gmpls-lsr-mib-08.txt for examples of references in the RFC format. draft-ietf-ccamp-gmpls-tc-mib-07.txt ====================================== Section 3. GMPLS Textual Conventions MIB Definitions --------------------------------------------------- 1) GmplsFreeformLabel TC 1a) Could the REFERENCE include section(s)? I suspect that this is referring to the Generalized Label described in section 3.2.1, is this correct? 1b) Please explain why this is 0..64 ? RFC3471 states that the Generalized label can be variable length, so wondering if this should be made larger? 1c) The DESCRIPTION needs a little work: DESCRIPTION "This value represents a freeform generalized MPLS Label. This can be used to represent label types which are not standard in the drafts. It may also be used by systems that do not wish to represent the labels using the specific label types." Please reword to something like: "This value represents a freeform GMPLS label. A freeform GMPLS label is specified by the system which uses it. In other words, the freeform GMPLS label is not a standard GMPLS label type, but is created by the system which uses it." 2) GmplsGeneralizedLabelTypes TC 2a) Could you change the name of the TC GmplsGeneralizedLabelTypes to GmplsLabelType It is more appropriate to have it singular when Imported and used in other MIBs, and dropping the word Generalized, because you already have the prefix Gmpls. 2b) Could the SYNTAX order be changed? Currently: SYNTAX INTEGER { gmplsMplsLabel(1), gmplsPortWavelengthLabel(2), gmplsFreeformGeneralizedLabel(3), gmplsSonetLabel(4), gmplsSdhLabel(5), gmplsWavebandLabel(6) } Proposed (NOTE also some of the names have been changed): SYNTAX INTEGER { gmplsFreeformLabelOrOther(1), gmplsMplsLabel(2), gmplsPortAndWavelengthLabel(3), gmplsSonetLabel(4), gmplsSdhLabel(5), gmplsWavebandLabel(6) } Section 4. Security Considerations ------------------------------------- 3) Change MPLS to GMPLS in the following statement: "This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MPLS MIB modules to define management objects." Section 5. IANA Considerations ------------------------------------- 4) Section 5. IANA Considerations RFC Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for "XXX" under the mib-2/mplsStdMIB subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace the "XXX" (here and in the MIB module) with the assigned value and to remove this note. 5) Section 5. IANA Considerations Please remove the last sentence of this section: "The IANA has assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB." Section 6.2 Informational References. --------------------------------------- 6) Section 6.2 Informational References. Please change to "Informative". 7) I believe the following references should be moved to the Normative section: [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), "Generalized MPLS Signaling - CR-LDP Extensions", RFC 3472, January 2003. [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. [RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual Conventions and for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3945] Mannie, E. (Editor), "Generalized Multiprotocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control", draft-ietf-ccamp-gmpls-sonet-sdh, work in progress. (the above is now RFC 3946) [GMPLS-SONET] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004. Also, as previously mentioned, need to check on the format of these References. Please see comments in the review of the draft-ietf-ccamp-gmpls-lsr-mib-08.txt for examples of references in the RFC format. --- the end --- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 08 Sep 2005 15:47:23 +0000 Message-Id: <3.0.1.32.20050908114852.0147664c@pop.mindspring.com> Date: Thu, 08 Sep 2005 11:48:52 -0400 To: tnadeau@cisco.com,adrian@olddog.co.uk,ccamp@ops.ietf.org From: jcucchiara@mindspring.com Subject: review of draft-ietf-ccamp-lsr-mib-08.txt Cc: bwijnen@lucent.com,jcucchiara@mindspring.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1126208932==_" --=====================_1126208932==_ Content-Type: text/plain; charset="us-ascii" --=====================_1126208932==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="new-review-GMPLS-LSR-STD-MIB.txt" Hello, I would like to thank Bert for his input, especially on the MIB compliances and document reference section. Thank you, -Joan draft-ietf-ccamp-gmpls-lsr-mib-08.txt ======================================= Section 1.1 Migration Strategy -------------------------------- 1) Does the following statement refer to the GMPLS LSR MIB module? "The GMPLS Label MIB module may be referenced using a row pointer from objects within the LSR MIB module." ^^^^ As previously mentioned, using the entire MIB module name would be clearer. Section 4. Outline --------------------- 2) Need to clarify the phrase "this MIB module" because there are 2 MIB modules in this document. "- Enabling GMPLS on GMPLS capable interfaces using this MIB module." (which is referring to the GMPLS-LSR-STD-MIB module??) ... "- Optionally setting up labels in the label table in this MIB module if the textual convention MplsLabel is not capable of holding the required label (for example, if the label requires more than 32 bits to encode it), or if the operator wishes to disambiguate GMPLS label types." The phrase, "in this MIB module", needs to be clarified since there are 2 mib modules in this document. Here, I think you are referring to the GMPLS-LABEL-STD-MIB, but prior to this you use a similar phrase and are referring the the GMPLS-LSR-STD-MIB. Please consistently specify the MIB modules by using their names. 3) Please move section, 4.1 MIB Modules to section 1.1, Migration Strategy. There is much overlap in these 2 sections so please combine them. Section 4.1.2 Summary of GMPLS Label MIB Module ------------------------------------------------- 4) "Generalized Labels can be of variable length and have distinct bit-by-bit interpretations according to the use that is made of them." Please change the above to: "Generalized Labels can be of variable length and have distinct bit-by-bit interpretations depending upon how they are defined by the specific service provider." 5) Same section, 4.1.2 Summary of GMPLS Label MIB Module Please remove this last sentence: These tables are described in the subsequent sections. Section 5. Bidirectional LSPs ------------------------------- 6) "This MIB module..." Please clarify which MIB module, i.e. The GMPLS-LSR-STD-MIB module 7) Please specifically call out which term you will be using in this document. Beginning with the 3rd paragraph, there is much terminology, so please add some statement such as: "In this document, the terms 'forward' and 'reverse' will be used. Section 6. Example of LSP Setup ------------------------------- 8) First and second sentences: "In this section we provide a brief example of using the MIB objects described in sections 7 and 8 to set up an LSP. While this example is not meant to illustrate every nuance of the MIB, it is intended as an aid to understanding some of the key concepts..." The phrase, "every nuance of the MIB" should probably be "every nuance of the MIB modules" since you are referring to both of the MIB modules (sections 7 and 8). 9) Typo: gmplsLableTable 10) Typo: accesible (in several places) Section 7. GMPLS-LSR-STD-MIB ====================== 11) smicngpro gives the following: E: f(GMPLS-LSR-STD-MIB), (315,8) Item "ifGeneralInformationGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (316,8) Item "ifCounterDiscontinuityGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (322,8) Item "mplsInterfaceGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (323,8) Item "mplsInSegmentGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (324,8) Item "mplsOutSegmentGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (325,8) Item "mplsXCGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (326,8) Item "mplsPerfGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (327,8) Item "mplsLsrNotificationGroup" should be IMPORTed W: f(GMPLS-LSR-STD-MIB), (358,18) For "gmplsOutSegmentTTLDecrement", syntax is identical E: f(GMPLS-LSR-STD-MIB), (378,8) Item "ifGeneralInformationGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (379,8) Item "ifCounterDiscontinuityGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (385,8) Item "mplsInterfaceGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (386,8) Item "mplsInSegmentGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (387,8) Item "mplsOutSegmentGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (388,8) Item "mplsXCGroup" should be IMPORTed E: f(GMPLS-LSR-STD-MIB), (389,8) Item "mplsPerfGroup" should be IMPORTed W: f(GMPLS-LSR-STD-MIB), (404,14) For "gmplsInterfaceSignalingCaps", syntax is identical W: f(GMPLS-LSR-STD-MIB), (415,18) For "gmplsInterfaceRsvpHelloPeriod", syntax is identical W: f(GMPLS-LSR-STD-MIB), (431,18) For "gmplsInSegmentExtraParamsPtr", syntax is identical W: f(GMPLS-LSR-STD-MIB), (447,18) For "gmplsOutSegmentTTLDecrement", syntax is identical W: f(GMPLS-LSR-STD-MIB), (454,18) For "gmplsOutSegmentExtraParamsPtr", syntax is identical Please correct the above. Also, please change the following 2 statements (which appear twice) to remove the SYNTAX, since this is redundant, unless there is a reason why you prefer to leave it. OBJECT gmplsInSegmentDirection SYNTAX GmplsSegmentDirection MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." OBJECT gmplsOutSegmentDirection SYNTAX GmplsSegmentDirection MIN-ACCESS read-only DESCRIPTION "Write access is not required. Only forward(1) needs to be supported by implementations that only support unidirectional LSPs." Compiles cleanly with smilint. 12) DESCRIPTION Please change the first paragraph to (this comment applies to the other MIB modules also.) Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXX; see the RFC itself for full legal notices. 13) Change the following: GmplsSegmentDirection FROM GMPLS-TC-STD-MIB -- GMPLSTCMIB -- RFC-Editor please resolve the reference above TO: GmplsSegmentDirection FROM GMPLS-TC-STD-MIB -- RFCXXXX -- RFC-Editor please resolve the reference above -- and remove this note. 14) Please remove: -- Notifications -- no notifications are currently defined. gmplsLsrNotifications OBJECT IDENTIFIER ::= { gmplsLsrStdMIB 0 } (You don't need to change any numbering, but no sense defining a number you don't need). 15) Please remove comments such as (this request is made for all MIB modules in all 3 documents): -- Top level components of this MIB module. -- Tables, Scalars -- Conformance -- GMPLS Interface Table. -- End of gmplsInterfaceTable -- In-segment table. etc. 16) gmplsInterfaceEntry OBJECT-TYPE "A conceptual row in this table is created automatically by an LSR for every interface capable of supporting GMPLS and which is configured to do so." Please change first sentence: "A conceptual row in this table is created automatically by an LSR when the interface is capable of supporting GMPLS and is correctly configured to do so." .... Please change the first sentence of the last paragraph: "The indexing is the same as that for mplsInterfaceTable." to: "The indexing is the same as the mplsInterfaceTable." 17) object: gmplsInterfaceSignalingCaps OBJECT-TYPE SYNTAX BITS { unknown (0), rsvpGmpls (1), crldpGmpls (2), -- note the use of CR-LDP is deprecated otherGmpls (3) } What is otherGmpls(3)?? Also, this description is confusing. How can unknown(0) and rsvpGmpls(1) be set simultaneously? Additionally, how can no bits be set? If this is a GMPLS interface, then doesn't one of these bits HAVE to be set? 18) gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE "Period, in milliseconds, between sending RSVP Hello messages on this interface. A value of 0 indicates that no Hello messages should be sent on this interface." This object is only valid if the gmplsInterfaceSignalingCaps object is set ot rsvpGmpls. Please update the description to reflect that. 19) gmplsInSegmentEntry OBJECT-TYPE "An entry in this table extends the representation of an incoming segment represented by an entry in mplsInSegmentTable. An entry can be created by a network administrator or an SNMP agent, or a GMPLS signaling protocol. Please use the phrase: "via SNMP SET commands to create an entry" in place of "SNMP agent". 20) same entry, gmplsInSegmentEntry Note that the storage type for this entry SHOULD be inherited from the corresponding entry in the mplsInSegmentTable given by the value of the mplsInSegmentStorageType object." Please change to: Note that the storage type for this entry is given by the value of mplsInSegmentStorageType in the corresponding entry of the mplsInSegmentTable. 21) gmplsInSegmentDirection OBJECT-TYPE Please use "corresponding" instead of "associated" 22) gmplsInSegmentExtraParamsPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-create STATUS current DESCRIPTION "Some Tunnels will run over transports that can usefully support technology-specific additional parameters (for example, SONET resource usage). Such can be supplied from an external table and referenced from here. A value of zeroDotzero in this attribute indicates that there is no such additional information." DEFVAL { zeroDotZero } ::= { gmplsInSegmentEntry 2 } What is meant by "external table"? If this is an enterprise-specific table, then is it necessary to have this object in the MIB. In other words, why is this MIB dictating that a row-pointer be used when an enterprise-specific MIB may which to simply use indices. I think this object is unnecessary, but maybe I don't understand something. 23) gmplsOutSegmentEntry OBJECT-TYPE Same comments as with gmplsInSegmentEntry 24) gmplsOutSegmentDirection OBJECT-TYPE Same comment as with gmplsInSegmentDirection 25) gmplsOutSegmentTTLDecrement OBJECT-TYPE "This object indicates the amount by which to decrement the TTL of any payload packets forwarded on this segment if per-hop decrementing is being done. Please change above to: This object indicates the amount to decrement the TTL... 26) same object's gmplsOutSegmentTTLDecrement OBJECT-TYPE A value of zero indicates that no decrement should be made or that per-hop decrementing is not in force. Please change: in force to enforced. 27) gmplsOutSegmentExtraParamsPtr OBJECT-TYPE Same comment as with gmplsInSegmentExtraParamsPtr 28) Compliance Statements I believe that gmplsInSegmentExtraParamsPtr and gmplsOutSegmentExtraParamsPtr do not need to be supported, so these maybe should be optional. Section 8. GMPLS-LABEL-STD-MIB =================================== smicngPRO gives the following: E: f(GMPLS-LABEL-STD-MIB), (21,13) Module "MPLS-TC-STD-MIB" has already been specified in IMPORTS clause E: f(GMPLS-LABEL-STD-MIB), (481,12) Group "gmplsLabelTableGroup" is both a MANDATORY and conditional group for module "GMPLS-LABEL-STD-MIB" Compiles cleanly with smilint. Also, disconnect in the numbering of the gmplsLabelTable: | \-v-1 gmplsLabelInterface, name "InterfaceIndexOrZero", na, current | |-2 gmplsLabelIndex, Unsigned32(0..4294967295), na, current | |-3 gmplsLabelSubindex, Unsigned32(0..4294967295), na, current | |-4 gmplsLabelType, name "GmplsGeneralizedLabelTypes", rc, current ---> 5 is missing | |-6 gmplsLabelMplsLabel, name "MplsLabel", rc, current | |-7 gmplsLabelPortWavelength, Unsigned32, rc, current | |-8 gmplsLabelFreeform, name "GmplsFreeformLabel", rc, current | |-9 gmplsLabelSonetSdhSignalIndex, Integer32(0..4095), rc, current | |-10 gmplsLabelSdhVc, Integer32(0..15), rc, current | |-11 gmplsLabelSdhVcBranch, Integer32(0..15), rc, current | |-12 gmplsLabelSonetSdhBranch, Integer32(0..15), rc, current | |-13 gmplsLabelSonetSdhGroupBranch, Integer32(0..15), rc, current | |-14 gmplsLabelWavebandId, Unsigned32, rc, current | |-15 gmplsLabelWavebandStart, Unsigned32, rc, current | |-16 gmplsLabelWavebandEnd, Unsigned32, rc, current | |-17 gmplsLabelRowStatus, name "RowStatus", rc, current | \-18 gmplsLabelStorageType, name "StorageType", rc, current 29) DESCRIPTION Please change the first paragraph to (this comment applies to the other MIB modules also.) Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC XXX; see the RFC itself for full legal notices. 30) Please remove these statements (don't need to change any numbers). -- Notifications -- no notifications are currently defined. gmplsLabelNotifications OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 0 } 31) gmplsLabelTable OBJECT-TYPE The last part of the last paragraph is awkward: "... Labels in the tables in other MIBs are referred to using row pointer into this table. The indexing of this table provides for arbitrary indexing and also for concatenation of labels." Are you saying that other MIBs can use a row pointer to point to this table? Why would they do that if they could just use the indices directly? Also, I don't follow the comment about concatenation of labels. Could you explain this? 32) gmplsLabelEntry OBJECT-TYPE The last sentence of the DESCRIPTION, please remove the word "more" from the phrase "is more persistent." I still don't understand how the subindex provides a way to concatenate the labels. Could you give an example? 33) please switch RowStatus and StorageType (this will more closely match the other MPLS MIBs). 34) gmplsLabelInterface OBJECT-TYPE DESCRIPTION also needs to specify that zero may be used to indicate that the InterfaceIndex is not known or that an InterfaceIndex exists but it is not important wrt this implementation so zero is used. 35) gmplsLabelIndex OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) 36a) I was expecting the SYNTAX to be IndexInteger due to the gmplsLabelIndexNext in the DESCRIPTION. Please explain why the use of zero is needed. You explain the use of zero in the gmplsLabelInterface and gmplsLabelSubindex indices. 36b)Please change the "may" to "should" in this statement: A management application may read the gmplsLabelIndexNext object to find a suitable value for this object." 37) gmplsLabelType OBJECT-TYPE of gmplsMplsLabel (1) denotes that a 23 bit MPLS packet label is present, but does not describe whether this is signaled using MPLS or GMPLS. Is this 23 bit value correct? Is this a FrameRelay DLCI label? 38) gmplsLabelRowStatus OBJECT-TYPE MUST explain which columns must be properly configured before the row can be made active (as per RFC2579) 39) Please clarify in the DESCRIPTION of each of the following groups, if the group is optional or needs to be supported by such implementations: GROUP gmplsLabelPacketGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support packet labels." GROUP gmplsLabelPortWavelengthGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support port and wavelength labels." GROUP gmplsLabelFreeformGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support freeform labels." GROUP gmplsLabelSonetSdhGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support SONET or SDH labels." GROUP gmplsLabelWavebandGroup DESCRIPTION "This group extends gmplsLabelTableGroup for implementations that support Waveband labels." 40) gmplsLabelModuleROCompliance MODULE-COMPLIANCE Please change the name to: gmplsLabelModuleReadOnlyCompliance to be consistent with the other MPLS and GMPLS MIB modules. 41) The ReadOnly compliance for gmplsLabelRowStatus does NOT have a MIN-ACCESS of read-only. Is this intentional? 42) Also, (related to the above) OBJECT gmplsLabelRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for notInService, createAndWait and notReady is not required." The DESCRIPTION clause conflicts with the WRITE-SYNTAX. Please clarify the intentions for this ReadOnly compliance object. Section 12.2 Informational References --------------------------------------- 43a) The title of this section should be Informative. 43b) Please move the following from Informative to Normative. [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), "Generalized MPLS Signaling - CR-LDP Extensions", RFC 3472, January 2003. [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. [GMPLSSonetSDH] Mannie, E., Papadimitriou, D. (Editors), "Generalized Multi-Protocol Label Switching Extensions for SONET and SDH Control", draft-ietf-ccamp-gmpls-sonet-sdh, work in progress. 43c) The above reference now appears to be RFC 3946. Please change the above (NOTE also the changes in the reference itself, more on the Reference format next): [GMPLS-SONET] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004. 44) There are a number of references (as discovered by Bert) that aren't in the RFC expected format. Please review all the references in this document and the other GMPLS MIB docs. Here are some to change. One suggestion is to copy a reference (if possible) from an existing RFC. Sometimes a date is missing and sometimes the authors/editors names do not appear as expected. Also, titles need to appear exactly as on the RFC. Please check the other GMPLS docs also. (NOTE: see also draft-rfc-editor-rfc2223bis-08.txt) Please change: [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. to: [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. Please change: [RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group MIB", RFC 2863, June 2000. to (author name misspelled): [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. Please change: [RFC3032] Rosen, E. et al, "MPLS Label Stack Encoding", RFC 3032, January 2001. to: [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. Please change: [RFC3212] Jamoussi, B., Aboul-Magd, O., Andersson, L., Ashwood-Smith, P., Hellstrand, F., Sundell, K., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Halpern, J., Heinanen, J., Kilty, T., Malis, A., and P. Vaananen, "Constraint-Based LSP Setup using LDP", RFC 3212, December 2001." to: [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. Please change: [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, December 2002. to: [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. Please change: [RFC3413] Levi, D., Meyer, P., Stewart, B., "SNMP Applications", RFC 3413, December 2002. to: [RFC3413] Levi, D., Meyers, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. Please change: [RFC3443] Agarwal, P. and Akyol, B., "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. to: [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003. Please change: [RFC3471] Berger, L. (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. to: [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. Please change: [RFC3472] Ashwood-Smith, P., Berger, L. (Editors), "Generalized MPLS Signaling - CR-LDP Extensions", RFC 3472, January 2003. to: [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. Please change: [RFC3473] Berger, L. (Editor), "Generalized MPLS Signaling - RSVP-TE Extensions", RFC 3473 January 2003. to: [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. --- the end ---- --=====================_1126208932==_ Content-Type: text/plain; charset="us-ascii" --=====================_1126208932==_-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Sep 2005 20:46:12 +0000 Message-ID: <046701c5b3ed$8271e310$93849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Short further last call on draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt Date: Wed, 7 Sep 2005 21:48:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Alex has reviewed this I-D as AD and says it is fine, but he thinks we should take it down the standards track as Proposed Standard not BCP as it was previously marked. This revision changes: - proposed status - IPR boilerplate - IANA clause to be a little more (about 10 words) detailed Since we have changed the proposed status, we need to check back with you guys. Let's have a two week last call on this change. If you do spot other issues as you go, then I guess we can handle them too. Last call will end 12 noon GMT on Thursday 22nd September. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Wednesday, September 07, 2005 8:50 PM Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > 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 : Node ID based RSVP Hello: A Clarification Statement > Author(s) : Z. Ali, et al. > Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > Pages : 7 > Date : 2005-9-7 > > Use of Node-ID based RSVP Hello messages is implied in a number of > cases, e.g., when data and control plan are separated, when TE links > are unnumbered. Furthermore, when link level failure detection is > performed by some means other than exchanging RSVP Hello messages, > use of Node-ID based Hello session is optimal for detecting signaling > adjacency failure for Resource reSerVation Protocol-Traffic > Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear > and this document formalizes use of Node-ID based RSVP Hello session > as a best current practice (BCP) in some scenarios. The procedure > described in this document applies to both Multi-Protocol Label > Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > 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-rsvp-node-id-based-hello-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-rsvp-node-id-based-hello-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. > -------------------------------------------------------------------------- ------ > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Sep 2005 19:51:05 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt Message-Id: Date: Wed, 07 Sep 2005 15:50:01 -0400 --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 : Node ID based RSVP Hello: A Clarification Statement Author(s) : Z. Ali, et al. Filename : draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt Pages : 7 Date : 2005-9-7 Use of Node-ID based RSVP Hello messages is implied in a number of cases, e.g., when data and control plan are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear and this document formalizes use of Node-ID based RSVP Hello session as a best current practice (BCP) in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-rsvp-node-id-based-hello-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-rsvp-node-id-based-hello-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: <2005-9-7111234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-node-id-based-hello-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-9-7111234.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 07 Sep 2005 15:04:16 +0000 Sensitivity: Subject: RE: Comments on draft-kim-ccamp-cc-protection-04 To: "Kim Young Hwa" Cc: " Message-ID: From: "Diego Caviglia" Date: Wed, 7 Sep 2005 17:02:26 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Kim, I've some further comments in line. Regards Diego "Kim Young Hwa" on 06/09/2005 09.28.03 Please respond to "Kim Young Hwa" To: , cc: Subject: RE: Comments on draft-kim-ccamp-cc-protection-04 [CUT] > > - When using the overhead bytes of SONET/SDH as a control channel, > in-fiber may require more resources such as HDLC controllers whereas > out-of-fiber could reduce the number of these resources; >[dc] This is a strange sentece. SONET/SDH DCC have not been developed for >GMPLS, are there since several years >and seems very strange to me to think about a SONET/SDH box that do not >support DCC processing. > As you guess, to use DCC overhead bytes, HDLC controllers should be considered. However, in case of out-of-fiber, there is no need to consider resources such as HDLC controllers. [dc] Actually my point was that every box that is compliant with SDH/SONET specs is able to process DCC. So it is not a point to say that "n-fiber may require more resources such as HDLC controllers" because AFAIK every SONET/SDH box in the world have that controllers. > - In case of only in-fiber, it looks that there is no room or no need > for protecting control channels. However, out-of-fiber may apply the > various and effective software based protection schemes; >[dc] Why there is no room for protecting control channels? Do you have any >figures about this? The line level DCC is 576 kbps while >the section DCC is 192 kbps. Do you thing the control traffic will be more >than that? > Contro channels are used to carry packets generated from signaling protocols, routing protocols, ,LMP, and so on. I think DCC overhaed bytes could not afford to support the bandwidth of control channels for these control protocols. [dc] I'm sorry but the sentence "I think DCC overhaed bytes could not afford to support the bandwidth of control channels for these control protocols" is not enough for a technical discussion. According to a private document, it is said the bandwidth of IS-IS protocols amount to about 7 or 8 Mbps within a certain AS. I think that DCC overhead bytes will be used for the extremely limited control traffic due to the limitation of bandwidth. DCC overhead bytes could not support routing protocols. [dc]I'm sorry again but I don't think that a private doc can be used as reference for a ID, otherwise I can state that accordingly to a private doc the bandwidth of IS-IS is less than 1 byte/day. > > - In-fiber is difficult to separate control plane from transport > plane, whereas out-of-fiber is easy to separate control plane; >[dc] IMHO this is not true and moreover you need to explain why is more >difficult. Today DCC are widely used to transport management traffic and >there are no difficulties in order to separate management from data >traffic. > I agree DCC could be used for management traffic. Even in this case, but, short management traffic could be supported. It is difficult to support long management traffic such as bulky data. [dc] Usually SW update is done remotely via DCN and DCN is also made by DCC. IMHO SW update (a.k.a. sw download) is a long management operation. My view is related to whether DCC based in-fiber is not proper in supporting generic control plane requirements, or not. However, I think a possibilty of using DCC overhead bytes as control channels should be considered in control plane. [dc] IMHO if you want to do a requirement docs you don't have to suggest implementation or say the DCC are not good for control plane. Just write down the requirements and leave to the developer the choice. > > - Because in-fiber provides the connection control function only > within a single fiber, in-fiber could not provide the connection > control function beyond a single fiber, whereas out-of-fiber has no > restriction about the number of fibers for the connection control > function. >[dc] Could you explain me a little bit more this? I don't see anything >that prevent me to set-up more that one CC on a fiber. > Here, I assumed the in-fiber control channel is used for the only own fiber. If you think an in-fiber control channel could be used for controlling other fibers, I or you share thought. Nevertheless, I think there may be a subtle gap bewteen you and me. Even though in-fiber control channels could be used in controlling physically other fibers, from the view-point of the physically other fibers, I think the control channels are not in-fiber but out-of-fiber. [dc] So there is a need to make a definition of what in-fiber means. Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Sep 2005 21:22:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Final draft of response to the OIF Date: Tue, 6 Sep 2005 16:20:10 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWxapMIbhDotaR3QWui/me39CHNnQBh6N6Q From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" , Hi All, It is interesting to note that the technically correct body text in RFC3946 (which would typically be considered normative) is being considered a 'typo' and subject to editorial change, while an example in an annex is being preserved although it appears to be in error according to the body text. A few more comments in-line below. Regards, Ben =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, September 04, 2005 11:05 AM > To: ccamp@ops.ietf.org > Subject: Re: Final draft of response to the OIF >=20 > OK. >=20 > So I see two questions here. >=20 > 1. What is meant by RFC3946? > 2. Do we want to change what is said by RFC3946? >=20 > Question 1 appears to be the question that was asked by the=20 > OIF. I think > we have a clear answer. I think some people are not happy with this > answer, but that feeds into question 2. My understanding of=20 > the answer to > question 1 is based on the input from the editors of the RFC=20 > and reading > the CCAMP archive. Thus, the response to the question from=20 > the OIF is as > follows: >=20 > This question about RFC 3946 was raised informally on the CCAMP > mailing list at the start of March this year. >=20 > Even when the signal Type value is the same (i.e. value 6) the > NCC, RCC and NVC values depend on the specific signal being > requested. >=20 > From the examples in the annex we have... >=20 > A VC-4 signal is formed by applying the following > settings to a VC-4 Elementary Signal. > RCC =3D 0 > NCC =3D 0 > NVC =3D 0 > MT =3D 1 > T =3D 0 >=20 > An STS-3c SPE signal is formed by applying the > following settings to an STS-3c SPE Elementary > Signal. > RCC =3D 1 (standard contiguous concatenation) > NCC =3D 1 > NVC =3D 0 > MT =3D 1 > T =3D 0 >=20 > Your question probably arises from the two notes and subsequent > paragraph in section 2.1 or RFC 3946. Here it says... >=20 > Note 1: when requesting a SONET STS-Nc SPE with N=3D3*X, the > Elementary Signal to use must always be an STS-3c_SPE signal > type and the value of NCC must always be equal to X. This > allows also facilitating the interworking between SONET and > SDH. In particular, it means that the contiguous > concatenation of three STS-1 SPEs can not be requested because > according to this specification, this type of signal must be > coded using the STS-3c SPE signal type. >=20 > Note 2: when requesting a transparent STS-N/STM-N signal > limited to a single contiguously concatenated STS-Nc_SPE/ > VC-4-Nc, the signal type must be STS-N/STM-N, RCC with flag 1 > and NCC set to 1. >=20 > The NCC value must be consistent with the type of contiguous > concatenation being requested in the RCC field. In particular, > this field is irrelevant if no contiguous concatenation is > requested (RCC =3D 0), in that case it must be set to zero when > sent, and should be ignored when received. A RCC value > different from 0 must imply a number of contiguous components > greater than 1. >=20 > This final sentence should read "greater than or equal to 1," and > was mistyped in the RFC. This change resolves all of your questions > and makes the text consistent with the examples. >=20 > The CCAMP working group is discussing a revision to RFC 3946 to > clarify the situation. >=20 > Question 2 is a different issue. Quite a few people have=20 > stated that they > believe that RFC 3946 with its current interpretation by the editors, > should be changed. At the moment I do not see consensus on=20 > this issue and > frankly I do not see any weighty reason to change although if the > community shows consensus in favor of a change, that would be=20 > fine *if* > someone does the work. >=20 > My observations on this point are as follows. >=20 > a. This is control plane code. It is definitively not > relevant to any interworking in the data plane.=20 Nothing CCAMP does is relevant to interworking in the data plane. However, the control plane should be reflective of the data plane. And the data plane has been made common for SONET/SDH. This is the reason that LSP Encoding Type 6 was depricated (even though at the time there were implementations that used it). We have the opportunity to maintain the same goal of properly reflecting the data plane in the control structure. Remember we're talking about a proposed standard, and taking into account implementation experience. > So > long as it is written down clearly, *any* unambiguous > control plane encoding is adequate. However, not every encoding achieves the goal of unifying SONET and SDH control. Furthermore, what has been proposed doesn't increase interoperability, but rather makes interoperability less likely. >=20 > b. Even if the data plane signal is identical, there may > be value in distinguishing between the SDH and SONET > origins of the signal. Then, as Huub asked, do we also need to distinguish SONET and SDH encodings at other rates as well? This would require a change to the current encodings. >=20 > c. We MUST support existing implementations. That means > that whatever encoding rules we end up with, we MUST > continue to support the receipt of existing encoding. > It seems to me that this dilutes the purpose of any > change. >=20 > d. Regardless of the definition of the signal encodings, > and regardless of whether fields with the same names > are used in the definition of those signals, I find > the textual descriptions of NCC and RCC in RFC 3946 > unambiguous in English. It may be that those > descriptions should be changed (or perhaps the names > of the fields should be changed?). >=20 > e. At the end of the day you are arguing about whether > there is a difference between: > - "I would like a shoal of fish, with just one fish > in the shoal." > and > - "I would like just one fish" > Do you really have time for this debate? >=20 > f. Changing an RFC does not just happen through email > exchanges. Someone has to do the work. If no-one does > the work, it is clear to the chairs how much people > care about the issue. The work is straightforward (change '1' to '0' in two places). I would think the editor(s) could handle this. >=20 > Thanks, > Adrian >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Sep 2005 07:28:17 +0000 Thread-Topic: Comments on draft-kim-ccamp-cc-protection-04 thread-index: AcWytIQtjuzcI9HjSR+FYGVxebgSVA== Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: , Cc: Bcc: Subject: RE: Comments on draft-kim-ccamp-cc-protection-04 Date: Tue, 6 Sep 2005 16:28:03 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_7359_01C5B2FF.F417EB20" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_7359_01C5B2FF.F417EB20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 ------=_NextPart_000_7359_01C5B2FF.F417EB20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBTeXN0 ZW0iPg0KPERJVj5IaSwgRGllZ288QlI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBBbmQsIHNv cnJ5IGZvciBsYXRlIHJlc3Bvc25zZS48QlI+SSBmZWVsIHRoZSBjb250ZW50cyBvZiAiTmVjZXNz aXRpZXMgZm9yIFJlc2lsaWVuY2Ugb2YgQ29udHJvbCBDaGFubmVscyIgc2hvdWxkIGJlIHJld3Jp dHRlbi48QlI+SSB0aGluayBjb250ZW50cyBvZiBvdGhlciBzZWN0aW9ucyBjb3VsZCBiZSB1cGRh dGVkIGFzIHdlbGwuPEJSPkknbSBvbiByZXdyaXRpbmcgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhl IGFyZWEgb2YgY29udHJvbCBwYWxuZSByb2J1c3RuZXNzIG9yIHJlc2lsaWVuY2UuPEJSPlBsZWFz ZSwgbG9vayBhdCBpbi1saW5lIGNvbW1lbnRzIGFib3V0IG1vcmUgZGV0YWlsZWQgdGhpbmdzLjxC Uj48QlI+UmVnYXJkczxCUj48QlI+WW91bmc8QlI+PEJSPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0gPEJSPkZyb206ICJEaWVnbyBDYXZpZ2xpYSIgJmx0O0RpZWdvLkNhdmlnbGlhQG1hcmNv bmkuY29tJmd0OyA8QlI+RnJvbSBEYXRlOiAyMDA1LTA5LTAxID8/IDc6MTM6NDQgPEJSPlRvOiAi Y2NhbXBAb3BzLmlldGYub3JnIiAmbHQ7Y2NhbXBAb3BzLmlldGYub3JnJmd0OywgInlod2tpbUBl dHJpLnJlLmtyIiAmbHQ7eWh3a2ltQGV0cmkucmUua3ImZ3Q7IDxCUj5DYzogPEJSPlN1YmplY3Q6 IENvbW1lbnRzIG9uIGRyYWZ0LWtpbS1jY2FtcC1jYy1wcm90ZWN0aW9uLTA0IDxCUj48QlI+Jmd0 OyA8QlI+PEJSPiZndDtIaSBhbGwsIDxCUj4mZ3Q7IEknZCBsaWtlIHRvIG1ha2Ugc29tZSBjb21t ZW50cyBvbiB0aGUgSUQgaW4gdGhlIHN1YmplYy4gPEJSPiZndDsgPEJSPiZndDsgPEJSPiZndDtT ZWN0aW9uIDcgPEJSPiZndDsgPEJSPiZndDsgSW4gZ2VuZXJhbCwgdGhlcmUgbWF5IGJlIHNldmVy YWwgYWR2YW50YWdlcyBvZiBvdXQtb2YtZmliZXIgb3ZlciBpbi0gPEJSPiZndDsgZmliZXIgc3Vj aCBhcyB0aGUgZm9sbG93aW5nczogPEJSPiZndDtbZGNdIEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGlz IHNlbnRlbmNlLiBJIGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgYXJlIDxCUj4mZ3Q7YWR2YW50ZXMg aW4gdGhlIHVzYWdlIG9mIG91dC1vZi1maWJlci4gPEJSPiZndDsgPEJSPiZndDsgLSBXaGVuIHVz aW5nIHRoZSBvdmVyaGVhZCBieXRlcyBvZiBTT05FVC9TREggYXMgYSBjb250cm9sIGNoYW5uZWws IDxCUj4mZ3Q7IGluLWZpYmVyIG1heSByZXF1aXJlIG1vcmUgcmVzb3VyY2VzIHN1Y2ggYXMgSERM QyBjb250cm9sbGVycyB3aGVyZWFzIDxCUj4mZ3Q7IG91dC1vZi1maWJlciBjb3VsZCByZWR1Y2Ug dGhlIG51bWJlciBvZiB0aGVzZSByZXNvdXJjZXM7IDxCUj4mZ3Q7W2RjXSBUaGlzIGlzIGEgc3Ry YW5nZSBzZW50ZWNlLiBTT05FVC9TREggRENDIGhhdmUgbm90IGJlZW4gZGV2ZWxvcGVkIGZvciA8 QlI+Jmd0O0dNUExTLCBhcmUgdGhlcmUgc2luY2Ugc2V2ZXJhbCB5ZWFycyA8QlI+Jmd0O2FuZCBz ZWVtcyB2ZXJ5IHN0cmFuZ2UgdG8gbWUgdG8gdGhpbmsgYWJvdXQgYSBTT05FVC9TREggYm94IHRo YXQgZG8gbm90IDxCUj4mZ3Q7c3VwcG9ydCBEQ0MgcHJvY2Vzc2luZy4gPEJSPiZndDs8QlI+PEJS PjxCUj48QlI+QXMgeW91IGd1ZXNzLCB0byB1c2UgRENDIG92ZXJoZWFkIGJ5dGVzLCBIRExDIGNv bnRyb2xsZXJzIHNob3VsZCBiZSBjb25zaWRlcmVkLiBIb3dldmVyLDxCUj5pbiBjYXNlIG9mIG91 dC1vZi1maWJlciwgdGhlcmUgaXMgbm8gbmVlZCB0byBjb25zaWRlciByZXNvdXJjZXMgc3VjaCBh cyBIRExDIGNvbnRyb2xsZXJzLjxCUj48QlI+Jmd0OyAtIEluIGNhc2Ugb2Ygb25seSBpbi1maWJl ciwgaXQgbG9va3MgdGhhdCB0aGVyZSBpcyBubyByb29tIG9yIG5vIG5lZWQgPEJSPiZndDsgZm9y IHByb3RlY3RpbmcgY29udHJvbCBjaGFubmVscy4gSG93ZXZlciwgb3V0LW9mLWZpYmVyIG1heSBh cHBseSB0aGUgPEJSPiZndDsgdmFyaW91cyBhbmQgZWZmZWN0aXZlIHNvZnR3YXJlIGJhc2VkIHBy b3RlY3Rpb24gc2NoZW1lczsgPEJSPiZndDtbZGNdIFdoeSB0aGVyZSBpcyBubyByb29tIGZvciBw cm90ZWN0aW5nIGNvbnRyb2wgY2hhbm5lbHM/IERvIHlvdSBoYXZlIGFueSA8QlI+Jmd0O2ZpZ3Vy ZXMgYWJvdXQgdGhpcz8gVGhlIGxpbmUgbGV2ZWwgRENDIGlzIDU3NiBrYnBzIHdoaWxlIDxCUj4m Z3Q7dGhlIHNlY3Rpb24gRENDIGlzIDE5MiBrYnBzLiBEbyB5b3UgdGhpbmcgdGhlIGNvbnRyb2wg dHJhZmZpYyB3aWxsIGJlIG1vcmUgPEJSPiZndDt0aGFuIHRoYXQ/IDxCUj4mZ3Q7PEJSPjxCUj5D b250cm8gY2hhbm5lbHMgYXJlIHVzZWQgdG8gY2FycnkgcGFja2V0cyBnZW5lcmF0ZWQgZnJvbSBz aWduYWxpbmcgcHJvdG9jb2xzLCByb3V0aW5nIHByb3RvY29scywgLExNUCwgYW5kIHNvIG9uLiBJ IHRoaW5rIERDQyBvdmVyaGFlZCBieXRlcyBjb3VsZCBub3QgYWZmb3JkIHRvIHN1cHBvcnQgdGhl IGJhbmR3aWR0aCBvZiBjb250cm9sIGNoYW5uZWxzIGZvciB0aGVzZSBjb250cm9sIHByb3RvY29s cy4gQWNjb3JkaW5nIHRvIGEgcHJpdmF0ZSBkb2N1bWVudCwgaXQgaXMgc2FpZCB0aGUgYmFuZHdp ZHRoIG9mIElTLUlTIHByb3RvY29scyBhbW91bnQgdG8gYWJvdXQgNyBvciA4IE1icHMgd2l0aGlu IGEgY2VydGFpbiBBUy4gSSB0aGluayB0aGF0IERDQyBvdmVyaGVhZCBieXRlcyB3aWxsIGJlIHVz ZWQgZm9yIHRoZSBleHRyZW1lbHkgbGltaXRlZCBjb250cm9sIHRyYWZmaWMgZHVlIHRvIHRoZSBs aW1pdGF0aW9uIG9mIGJhbmR3aWR0aC4gRENDIG92ZXJoZWFkIGJ5dGVzIGNvdWxkIG5vdCBzdXBw b3J0IHJvdXRpbmcgcHJvdG9jb2xzLjxCUj48QlI+Jmd0OyA8QlI+Jmd0OyAtIEluLWZpYmVyIGlz IGRpZmZpY3VsdCB0byBzZXBhcmF0ZSBjb250cm9sIHBsYW5lIGZyb20gdHJhbnNwb3J0IDxCUj4m Z3Q7IHBsYW5lLCB3aGVyZWFzIG91dC1vZi1maWJlciBpcyBlYXN5IHRvIHNlcGFyYXRlIGNvbnRy b2wgcGxhbmU7IDxCUj4mZ3Q7W2RjXSBJTUhPIHRoaXMgaXMgbm90IHRydWUgYW5kIG1vcmVvdmVy IHlvdSBuZWVkIHRvIGV4cGxhaW4gd2h5IGlzIG1vcmUgPEJSPiZndDtkaWZmaWN1bHQuIFRvZGF5 IERDQyBhcmUgd2lkZWx5IHVzZWQgdG8gdHJhbnNwb3J0IG1hbmFnZW1lbnQgdHJhZmZpYyBhbmQg PEJSPiZndDt0aGVyZSBhcmUgbm8gZGlmZmljdWx0aWVzIGluIG9yZGVyIHRvIHNlcGFyYXRlIG1h bmFnZW1lbnQgZnJvbSBkYXRhIDxCUj4mZ3Q7dHJhZmZpYy4gPEJSPiZndDs8QlI+PEJSPkkgYWdy ZWUgRENDIGNvdWxkIGJlIHVzZWQgZm9yIG1hbmFnZW1lbnQgdHJhZmZpYy4gRXZlbiBpbiB0aGlz IGNhc2UsIGJ1dCwgc2hvcnQgbWFuYWdlbWVudCB0cmFmZmljIGNvdWxkIGJlIHN1cHBvcnRlZC4g SXQgaXMgZGlmZmljdWx0IHRvIHN1cHBvcnQgbG9uZyBtYW5hZ2VtZW50IHRyYWZmaWMgc3VjaCBh cyBidWxreSBkYXRhLjxCUj5NeSB2aWV3IGlzIHJlbGF0ZWQgdG8gd2hldGhlciBEQ0MgYmFzZWQg aW4tZmliZXIgaXMgbm90IHByb3BlciBpbiBzdXBwb3J0aW5nIGdlbmVyaWMgY29udHJvbCBwbGFu ZSByZXF1aXJlbWVudHMsIG9yIG5vdC4gSG93ZXZlciwgSSB0aGluayBhIHBvc3NpYmlsdHkgb2Yg dXNpbmcgRENDIG92ZXJoZWFkIGJ5dGVzIGFzIGNvbnRyb2wgY2hhbm5lbHMgc2hvdWxkIGJlIGNv bnNpZGVyZWQgaW4gY29udHJvbCBwbGFuZS48QlI+PEJSPiZndDsgPEJSPiZndDsgLSBCZWNhdXNl IGluLWZpYmVyIHByb3ZpZGVzIHRoZSBjb25uZWN0aW9uIGNvbnRyb2wgZnVuY3Rpb24gb25seSA8 QlI+Jmd0OyB3aXRoaW4gYSBzaW5nbGUgZmliZXIsIGluLWZpYmVyIGNvdWxkIG5vdCBwcm92aWRl IHRoZSBjb25uZWN0aW9uIDxCUj4mZ3Q7IGNvbnRyb2wgZnVuY3Rpb24gYmV5b25kIGEgc2luZ2xl IGZpYmVyLCB3aGVyZWFzIG91dC1vZi1maWJlciBoYXMgbm8gPEJSPiZndDsgcmVzdHJpY3Rpb24g YWJvdXQgdGhlIG51bWJlciBvZiBmaWJlcnMgZm9yIHRoZSBjb25uZWN0aW9uIGNvbnRyb2wgPEJS PiZndDsgZnVuY3Rpb24uIDxCUj4mZ3Q7W2RjXSBDb3VsZCB5b3UgZXhwbGFpbiBtZSBhIGxpdHRs ZSBiaXQgbW9yZSB0aGlzPyBJIGRvbid0IHNlZSBhbnl0aGluZyA8QlI+Jmd0O3RoYXQgcHJldmVu dCBtZSB0byBzZXQtdXAgbW9yZSB0aGF0IG9uZSBDQyBvbiBhIGZpYmVyLiA8QlI+Jmd0OzxCUj48 QlI+SGVyZSwgSSBhc3N1bWVkIHRoZSBpbi1maWJlciBjb250cm9sIGNoYW5uZWwgaXMgdXNlZCBm b3IgdGhlIG9ubHkgb3duIGZpYmVyLiA8QlI+SWYgeW91IHRoaW5rIGFuIGluLWZpYmVyIGNvbnRy b2wgY2hhbm5lbCBjb3VsZCBiZSB1c2VkIGZvciBjb250cm9sbGluZyBvdGhlciBmaWJlcnMsIEkg b3IgeW91IHNoYXJlIHRob3VnaHQuPEJSPk5ldmVydGhlbGVzcywgSSB0aGluayB0aGVyZSBtYXkg YmUgYSBzdWJ0bGUgZ2FwIGJld3RlZW4geW91IGFuZCBtZS48QlI+RXZlbiB0aG91Z2ggaW4tZmli ZXIgY29udHJvbCBjaGFubmVscyBjb3VsZCBiZSB1c2VkIGluIGNvbnRyb2xsaW5nIHBoeXNpY2Fs bHkgb3RoZXIgZmliZXJzLCBmcm9tIHRoZSB2aWV3LXBvaW50IG9mIHRoZSBwaHlzaWNhbGx5IG90 aGVyIGZpYmVycywgSSB0aGluayB0aGUgY29udHJvbCBjaGFubmVscyBhcmUgbm90IGluLWZpYmVy IGJ1dCBvdXQtb2YtZmliZXIuPEJSPjxCUj4mZ3Q7IDxCUj4mZ3Q7W3F1b3RlXSA8QlI+V2hlbiB0 aGUgb3V0LW9mLWZpYmVyIGNvbmZpZ3VyYXRpb24gaXMgdXNlZCwgY29udHJvbCBjaGFubmVscyBt YXkgYmUgc2hhcmVkIDxCUj4mZ3Q7dG8gaGFuZGxlIHNldmVyYWwgZmliZXJzIDxCUj4mZ3Q7Wy9x dW90ZV0gPEJSPiZndDtbZGNdIElNSE8gdGhlIGNjIGFyZSBhc3NvY2lhdGVkIHRvIHRoZSBURSBh bmQgbm90IHRvIHRoZSBmaWJyZSwgc28gYSBzaW5nbGUgPEJSPiZndDtDQyBjYW4gc2VydmUgc2V2 ZXJhbCBURSBsaW5rIGFuZCB0aHVzIHNldmVyYWwgZmlicmU7IHRoaXMgaXMgbm90IHJlbGF0ZWQg b24gPEJSPiZndDtob3cgaXQgaXMgaW1wbGVtZW50ZWQuPEJSPjxCUj5JIHRoaW5rIGl0J3Mgb2tl eSBpZiB3ZSBhZ3JlZSB0aGF0IGNvbnRyb2wgY2hhbm5lbHMgYXJlIHVzZWQgdG8gY29udHJvbCBk YXRhIGNoYW5uZWxzIGJldHdlZW4gYWRqYWNlbnQgbm9kZXMuPEJSPjxCUj4mZ3Q7IDxCUj4mZ3Q7 W3F1b3RlXSA8QlI+Jmd0O0NvbnNlcXVlbnRseSwgdG8gcHJvdmlkZSB0aGUgcmVzaWxpZW5jZSBj YXBhYmlsaXR5IG9mIGNvbnRyb2wgY2hhbm5lbHMsIGl0IDxCUj4mZ3Q7aXMgcmVhc29uYWJsZSB0 byB1c2Ugb3V0LW9mLWZpYmVyIHJhdGhlciB0aGFuIGluLWZpYmVyIGZvciBHTVBMUy4gPEJSPiZn dDtbcXVvdGUvXSA8QlI+Jmd0O1tkY10gSSBkb24ndCBzZWUgaG93IHRoZSBwcmV2aW91cyBzZW50 ZW5jZXMgY2FuIGxlYWQgdG8gdGhpcyBzdGF0ZW1lbnQuIDxCUj4mZ3Q7V2hhdCBpcyByZWFzb25h YmxlIGlzIHRoYXQgdGhlIGNvbnRyb2wgY2hhbm5lbHMgbXVzdCBiZSByZXNpbGllbnQgYnV0IHRo aXMgPEJSPiZndDtkb24ndCBpbXBsaWVzIHRoZSBmYWN0IHRoZXkgc2hvdWxkIGJlIG91dC1vZi1m aWJlci4gPEJSPiZndDs8QlI+PEJSPkkgYWdyZWUgdG8geW91ciBwb2ludC4gSSB0aGluayB0aGF0 IGl0IGlzIG5vdCBnb29kIHRvIGFyZ3VlIHRoZSByZXNpbGllbmNlIGNhcGFiaWxpdHkgb2YgY29u dHJvbCBjaGFubmVscyB3aXRoIGluLWZpYmVyIGFuZCBvdXQtb2YtZmliZXIuIEkgd2lsbCBtb2Rp ZnkgdGhlc2UgcGFydHMgaW4gYSBmdXJ0aGVyIGRvY3VtZW50LjxCUj48QlI+Jmd0O1JlZ2FyZHMg PEJSPiZndDsgPEJSPiZndDtEaWVnbyA8QlI+PC9ESVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxh eTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0iaHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0 ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9Y2NhbXBAb3BzLmlldGYub3JnJm5hbWU9Y2NhbXAl NDBvcHMuaWV0Zi5vcmcmZnJvbWVtYWlsPXlod2tpbUBldHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0Mx ZjdhM2NlNi04ZjhmLTQ4YjgtYmU1OC05OWQ0ZmYxOWQ2ZjVAZXRyaS5yZS5rciUzRSI+ ------=_NextPart_000_7359_01C5B2FF.F417EB20-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Sep 2005 06:44:53 +0000 Thread-Topic: Comments on draft-kim-ccamp-cc-protection-04 thread-index: AcWyroGu/xD6EEqdQE+gpYcSD/Z8Sw== Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: , Cc: Bcc: Subject: Re: Comments on draft-kim-ccamp-cc-protection-04 Date: Tue, 6 Sep 2005 15:45:02 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_6677_01C5B2F9.F198A200" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_6677_01C5B2F9.F198A200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Maybe, it looks like that there is a problem on sending this email. I will try it one more. Hi, Diego Thanks for your comments. And, sorry for late resposnse. I feel the contents of "Necessities for Resilience of Control Channels" should be rewritten. I think contents of other sections could be updated as well. I'm on rewriting the requirements for the area of control palne robustness or resilience. Please, look at in-line comments about more detailed things. Regards Young ----- Original Message ----- From: "Diego Caviglia" >From Date: 2005-09-01 ?? 7:13:44 To: "ccamp@ops.ietf.org" , "yhwkim@etri.re.kr" Cc: Subject: Comments on draft-kim-ccamp-cc-protection-04 > >Hi all, > I'd like to make some comments on the ID in the subjec. > > >Section 7 > > In general, there may be several advantages of out-of-fiber over in- > fiber such as the followings: >[dc] I don't agree with this sentence. I don't think that there are >advantes in the usage of out-of-fiber. > > - When using the overhead bytes of SONET/SDH as a control channel, > in-fiber may require more resources such as HDLC controllers whereas > out-of-fiber could reduce the number of these resources; >[dc] This is a strange sentece. SONET/SDH DCC have not been developed for >GMPLS, are there since several years >and seems very strange to me to think about a SONET/SDH box that do not >support DCC processing. > As you guess, to use DCC overhead bytes, HDLC controllers should be considered. However, in case of out-of-fiber, there is no need to consider resources such as HDLC controllers. > - In case of only in-fiber, it looks that there is no room or no need > for protecting control channels. However, out-of-fiber may apply the > various and effective software based protection schemes; >[dc] Why there is no room for protecting control channels? Do you have any >figures about this? The line level DCC is 576 kbps while >the section DCC is 192 kbps. Do you thing the control traffic will be more >than that? > Contro channels are used to carry packets generated from signaling protocols, routing protocols, ,LMP, and so on. I think DCC overhaed bytes could not afford to support the bandwidth of control channels for these control protocols. According to a private document, it is said the bandwidth of IS-IS protocols amount to about 7 or 8 Mbps within a certain AS. I think that DCC overhead bytes will be used for the extremely limited control traffic due to the limitation of bandwidth. DCC overhead bytes could not support routing protocols. > > - In-fiber is difficult to separate control plane from transport > plane, whereas out-of-fiber is easy to separate control plane; >[dc] IMHO this is not true and moreover you need to explain why is more >difficult. Today DCC are widely used to transport management traffic and >there are no difficulties in order to separate management from data >traffic. > I agree DCC could be used for management traffic. Even in this case, but, short management traffic could be supported. It is difficult to support long management traffic such as bulky data. My view is related to whether DCC based in-fiber is not proper in supporting generic control plane requirements, or not. However, I think a possibilty of using DCC overhead bytes as control channels should be considered in control plane. > > - Because in-fiber provides the connection control function only > within a single fiber, in-fiber could not provide the connection > control function beyond a single fiber, whereas out-of-fiber has no > restriction about the number of fibers for the connection control > function. >[dc] Could you explain me a little bit more this? I don't see anything >that prevent me to set-up more that one CC on a fiber. > Here, I assumed the in-fiber control channel is used for the only own fiber. If you think an in-fiber control channel could be used for controlling other fibers, I or you share thought. Nevertheless, I think there may be a subtle gap bewteen you and me. Even though in-fiber control channels could be used in controlling physically other fibers, from the view-point of the physically other fibers, I think the control channels are not in-fiber but out-of-fiber. > >[quote] When the out-of-fiber configuration is used, control channels may be shared >to handle several fibers >[/quote] >[dc] IMHO the cc are associated to the TE and not to the fibre, so a single >CC can serve several TE link and thus several fibre; this is not related on >how it is implemented. I think it's okey if we agree that control channels are used to control data channels between adjacent nodes. > >[quote] >Consequently, to provide the resilience capability of control channels, it >is reasonable to use out-of-fiber rather than in-fiber for GMPLS. >[quote/] >[dc] I don't see how the previous sentences can lead to this statement. >What is reasonable is that the control channels must be resilient but this >don't implies the fact they should be out-of-fiber. > I agree to your point. I think that it is not good to argue the resilience capability of control channels with in-fiber and out-of-fiber. I will modify these parts in a further document. >Regards > >Diego ------=_NextPart_000_6677_01C5B2F9.F198A200 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_6677_01C5B2F9.F198A200-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 06 Sep 2005 06:26:06 +0000 Thread-Topic: Comments on draft-kim-ccamp-cc-protection-04 thread-index: AcWyq6X97fVOSbkaTom2uoJpK4LyFg== Content-Transfer-Encoding: 7bit Reply-To: "Kim Young Hwa" From: "Kim Young Hwa" To: "Diego Caviglia" , Cc: Bcc: Subject: RE: Comments on draft-kim-ccamp-cc-protection-04 Date: Tue, 6 Sep 2005 15:24:34 +0900 Comment: GQ19@|@ZEk=E?,18?x, OAM1b MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_62BF_01C5B2F7.15E73F70" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_62BF_01C5B2F7.15E73F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Diego Thanks for your comments. And, sorry for late resposnse. I feel the contents of "Necessities for Resilience of Control Channels" should be rewritten. I think contents of other sections could be updated as well. I'm on rewriting the requirements for the area of control palne robustness or resilience. Please, look at in-line comments about more detailed things. Regards Young ----- Original Message ----- From: "Diego Caviglia" >From Date: 2005-09-01 ?? 7:13:44 To: "ccamp@ops.ietf.org" , "yhwkim@etri.re.kr" Cc: Subject: Comments on draft-kim-ccamp-cc-protection-04 > >Hi all, > I'd like to make some comments on the ID in the subjec. > > >Section 7 > > In general, there may be several advantages of out-of-fiber over in- > fiber such as the followings: >[dc] I don't agree with this sentence. I don't think that there are >advantes in the usage of out-of-fiber. > > - When using the overhead bytes of SONET/SDH as a control channel, > in-fiber may require more resources such as HDLC controllers whereas > out-of-fiber could reduce the number of these resources; >[dc] This is a strange sentece. SONET/SDH DCC have not been developed for >GMPLS, are there since several years >and seems very strange to me to think about a SONET/SDH box that do not >support DCC processing. > As you guess, to use DCC overhead bytes, HDLC controllers should be considered. However, in case of out-of-fiber, there is no need to consider resources such as HDLC controllers. > - In case of only in-fiber, it looks that there is no room or no need > for protecting control channels. However, out-of-fiber may apply the > various and effective software based protection schemes; >[dc] Why there is no room for protecting control channels? Do you have any >figures about this? The line level DCC is 576 kbps while >the section DCC is 192 kbps. Do you thing the control traffic will be more >than that? > Contro channels are used to carry packets generated from signaling protocols, routing protocols, ,LMP, and so on. I think DCC overhaed bytes could not afford to support the bandwidth of control channels for these control protocols. According to a private document, it is said the bandwidth of IS-IS protocols amount to about 7 or 8 Mbps within a certain AS. I think that DCC overhead bytes will be used for the extremely limited control traffic due to the limitation of bandwidth. DCC overhead bytes could not support routing protocols. > > - In-fiber is difficult to separate control plane from transport > plane, whereas out-of-fiber is easy to separate control plane; >[dc] IMHO this is not true and moreover you need to explain why is more >difficult. Today DCC are widely used to transport management traffic and >there are no difficulties in order to separate management from data >traffic. > I agree DCC could be used for management traffic. Even in this case, but, short management traffic could be supported. It is difficult to support long management traffic such as bulky data. My view is related to whether DCC based in-fiber is not proper in supporting generic control plane requirements, or not. However, I think a possibilty of using DCC overhead bytes as control channels should be considered in control plane. > > - Because in-fiber provides the connection control function only > within a single fiber, in-fiber could not provide the connection > control function beyond a single fiber, whereas out-of-fiber has no > restriction about the number of fibers for the connection control > function. >[dc] Could you explain me a little bit more this? I don't see anything >that prevent me to set-up more that one CC on a fiber. > Here, I assumed the in-fiber control channel is used for the only own fiber. If you think an in-fiber control channel could be used for controlling other fibers, I or you share thought. Nevertheless, I think there may be a subtle gap bewteen you and me. Even though in-fiber control channels could be used in controlling physically other fibers, from the view-point of the physically other fibers, I think the control channels are not in-fiber but out-of-fiber. > >[quote] When the out-of-fiber configuration is used, control channels may be shared >to handle several fibers >[/quote] >[dc] IMHO the cc are associated to the TE and not to the fibre, so a single >CC can serve several TE link and thus several fibre; this is not related on >how it is implemented. I think it's okey if we agree that control channels are used to control data channels between adjacent nodes. > >[quote] >Consequently, to provide the resilience capability of control channels, it >is reasonable to use out-of-fiber rather than in-fiber for GMPLS. >[quote/] >[dc] I don't see how the previous sentences can lead to this statement. >What is reasonable is that the control channels must be resilient but this >don't implies the fact they should be out-of-fiber. > I agree to your point. I think that it is not good to argue the resilience capability of control channels with in-fiber and out-of-fiber. I will modify these parts in a further document. >Regards > >Diego ------=_NextPart_000_62BF_01C5B2F7.15E73F70 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_62BF_01C5B2F7.15E73F70-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 04 Sep 2005 16:05:04 +0000 Message-ID: <00d901c5b16a$8bc37760$93849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Re: Final draft of response to the OIF Date: Sun, 4 Sep 2005 17:04:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit OK. So I see two questions here. 1. What is meant by RFC3946? 2. Do we want to change what is said by RFC3946? Question 1 appears to be the question that was asked by the OIF. I think we have a clear answer. I think some people are not happy with this answer, but that feeds into question 2. My understanding of the answer to question 1 is based on the input from the editors of the RFC and reading the CCAMP archive. Thus, the response to the question from the OIF is as follows: This question about RFC 3946 was raised informally on the CCAMP mailing list at the start of March this year. Even when the signal Type value is the same (i.e. value 6) the NCC, RCC and NVC values depend on the specific signal being requested. From the examples in the annex we have... A VC-4 signal is formed by applying the following settings to a VC-4 Elementary Signal. RCC = 0 NCC = 0 NVC = 0 MT = 1 T = 0 An STS-3c SPE signal is formed by applying the following settings to an STS-3c SPE Elementary Signal. RCC = 1 (standard contiguous concatenation) NCC = 1 NVC = 0 MT = 1 T = 0 Your question probably arises from the two notes and subsequent paragraph in section 2.1 or RFC 3946. Here it says... Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the Elementary Signal to use must always be an STS-3c_SPE signal type and the value of NCC must always be equal to X. This allows also facilitating the interworking between SONET and SDH. In particular, it means that the contiguous concatenation of three STS-1 SPEs can not be requested because according to this specification, this type of signal must be coded using the STS-3c SPE signal type. Note 2: when requesting a transparent STS-N/STM-N signal limited to a single contiguously concatenated STS-Nc_SPE/ VC-4-Nc, the signal type must be STS-N/STM-N, RCC with flag 1 and NCC set to 1. The NCC value must be consistent with the type of contiguous concatenation being requested in the RCC field. In particular, this field is irrelevant if no contiguous concatenation is requested (RCC = 0), in that case it must be set to zero when sent, and should be ignored when received. A RCC value different from 0 must imply a number of contiguous components greater than 1. This final sentence should read "greater than or equal to 1," and was mistyped in the RFC. This change resolves all of your questions and makes the text consistent with the examples. The CCAMP working group is discussing a revision to RFC 3946 to clarify the situation. Question 2 is a different issue. Quite a few people have stated that they believe that RFC 3946 with its current interpretation by the editors, should be changed. At the moment I do not see consensus on this issue and frankly I do not see any weighty reason to change although if the community shows consensus in favor of a change, that would be fine *if* someone does the work. My observations on this point are as follows. a. This is control plane code. It is definitively not relevant to any interworking in the data plane. So long as it is written down clearly, *any* unambiguous control plane encoding is adequate. b. Even if the data plane signal is identical, there may be value in distinguishing between the SDH and SONET origins of the signal. c. We MUST support existing implementations. That means that whatever encoding rules we end up with, we MUST continue to support the receipt of existing encoding. It seems to me that this dilutes the purpose of any change. d. Regardless of the definition of the signal encodings, and regardless of whether fields with the same names are used in the definition of those signals, I find the textual descriptions of NCC and RCC in RFC 3946 unambiguous in English. It may be that those descriptions should be changed (or perhaps the names of the fields should be changed?). e. At the end of the day you are arguing about whether there is a difference between: - "I would like a shoal of fish, with just one fish in the shoal." and - "I would like just one fish" Do you really have time for this debate? f. Changing an RFC does not just happen through email exchanges. Someone has to do the work. If no-one does the work, it is clear to the chairs how much people care about the issue. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Sep 2005 17:36:59 +0000 Message-ID: <43173BBA.4020608@grotto-networking.com> Date: Thu, 01 Sep 2005 10:34:50 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: "Mack-Crane, T. Benjamin" CC: Dimitri.Papadimitriou@alcatel.be, Huub van Helvoort , bertk@txc.com, dpapadimitriou@psg.com, Adrian Farrel , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Concur with Ben and Huub. This is also why all current framer chips support both SONET and SDH. STS-3c == VC-4. Greg B. Mack-Crane, T. Benjamin wrote: > Dimitri, > > The control plane is intended to control the data plane, not the > naming of data plane signals in various standards. The fact that two > names are used in SONET and SDH for the same data plane signal is not > justification for creating two encodings in the control plane. > > This should be a simple thing to fix, if we (CCAMP) are willing to fix it. > > Regards, > Ben > > ------------------------------------------------------------------------ > *From:* owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] > *On Behalf Of *Dimitri.Papadimitriou@alcatel.be > *Sent:* Thursday, September 01, 2005 6:53 AM > *To:* Huub van Helvoort > *Cc:* Dimitri.Papadimitriou@alcatel.be; bertk@txc.com; > dpapadimitriou@psg.com; Adrian Farrel; ccamp@ops.ietf.org > *Subject:* Re: Final draft of response to the OIF > > huub, > > > > > Standard contiguous concatenated STS-Nc SPE is actually > STS-3c-Xc SPE > > > > with N=3X and X=4,16,64,... which explains the coding with a > STS-3c SPE > > > > elementary signal and NCC=X. So we code the STS-Nc SPE and > VC-4-Xc > > > > identical (examples 3 and 9) but not their base signal ?!?... > > > > > > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET > base spec) > > > you will that your interpretation is not the one specified in this > > > recommendation > > > > > > " Super rates services are mapped into and transported as > STS-Nc SPE > > > [N=3X there X = 1, 4, 16, 64 or 256]" > > > > Somehow you left out the last part between the square brackets: > > "or SDH VC-4 or VC-4-Xc, where X=N/3]" > > > > This clearly means that an STS-3c == VC-4 == super rate of STS-1. > > indeed but we are not discussing this issue or put this > "equivalence" under questioning (in fact this is reproduced in the > signal type 6 definition) the RFC took as logic (control plane) to > set the RCC value when the notation of the signal included a "c" > we could have created yet another exception but we did not - for > several reasons - > > > > > this is exactly what we used in RFC 3946 > > > -- > ================================================================ > > http://www.gironet.nl/home/idefiks/ > http://members.chello.nl/hhelvoort/ > > ================================================================ > Always remember that you are unique...just like everyone else... > >============================================================ >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, 01 Sep 2005 14:27:16 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AF01.36D2C69E" Subject: RE: Final draft of response to the OIF Date: Thu, 1 Sep 2005 09:26:34 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWu7BNpifROSQ+hSAa9OevYQ0xcNAAFFmXw From: "Mack-Crane, T. Benjamin" To: , "Huub van Helvoort" Cc: , , "Adrian Farrel" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AF01.36D2C69E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Dimitri, The control plane is intended to control the data plane, not the naming of data plane signals in various standards. The fact that two names are used in SONET and SDH for the same data plane signal is not justification for creating two encodings in the control plane. This should be a simple thing to fix, if we (CCAMP) are willing to fix it. Regards, Ben ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Dimitri.Papadimitriou@alcatel.be Sent: Thursday, September 01, 2005 6:53 AM To: Huub van Helvoort Cc: Dimitri.Papadimitriou@alcatel.be; bertk@txc.com; dpapadimitriou@psg.com; Adrian Farrel; ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF huub, > > > Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE > > > with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE > > > elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc > > > identical (examples 3 and 9) but not their base signal ?!?... > > > > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET base spec) > > you will that your interpretation is not the one specified in this > > recommendation > > > > " Super rates services are mapped into and transported as STS-Nc SPE > > [N=3X there X = 1, 4, 16, 64 or 256]" > > Somehow you left out the last part between the square brackets: > "or SDH VC-4 or VC-4-Xc, where X=N/3]" > > This clearly means that an STS-3c == VC-4 == super rate of STS-1. indeed but we are not discussing this issue or put this "equivalence" under questioning (in fact this is reproduced in the signal type 6 definition) the RFC took as logic (control plane) to set the RCC value when the notation of the signal included a "c" we could have created yet another exception but we did not - for several reasons - > > this is exactly what we used in RFC 3946 -- ================================================================ http://www.gironet.nl/home/idefiks/ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... ============================================================ 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 ============================================================ ------_=_NextPart_001_01C5AF01.36D2C69E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii"
Dimitri,
 
The control plane is intended to control the data plane, not the naming of data plane signals in various standards.  The fact that two names are used in SONET and SDH for the same data plane signal is not justification for creating two encodings in the control plane.
 
This should be a simple thing to fix, if we (CCAMP) are willing to fix it.
 
Regards,
Ben

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Thursday, September 01, 2005 6:53 AM
To: Huub van Helvoort
Cc: Dimitri.Papadimitriou@alcatel.be; bertk@txc.com; dpapadimitriou@psg.com; Adrian Farrel; ccamp@ops.ietf.org
Subject: Re: Final draft of response to the OIF

huub,

> > > Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE
> > > with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE
> > > elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc
> > > identical (examples 3 and 9) but not their base signal ?!?...
> >
> > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET base spec)
> > you will that your interpretation is not the one specified in this
> > recommendation
> >
> > " Super rates services are mapped into and transported as STS-Nc SPE
> > [N=3X there X = 1, 4, 16, 64 or 256]"
>
> Somehow you left out the last part between the square brackets:
> "or SDH VC-4 or VC-4-Xc, where X=N/3]"
>
> This clearly means that an STS-3c == VC-4 == super rate of STS-1.

indeed but we are not discussing this issue or put this "equivalence" under questioning (in fact this is reproduced in the signal type 6 definition) the RFC took as logic (control plane) to set the RCC value when the notation of the signal included a "c" we could have created yet another exception but we did not - for several reasons -


> > this is exactly what we used in RFC 3946


--
================================================================

================================================================
Always remember that you are unique...just like everyone else...

============================================================
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
============================================================
------_=_NextPart_001_01C5AF01.36D2C69E-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Sep 2005 14:18:03 +0000 Message-ID: <43170D40.90208@txc.com> Date: Thu, 01 Sep 2005 16:16:32 +0200 From: Bert Klaps Reply-To: bertk@txc.com User-Agent: Mozilla Thunderbird 1.0 (X11/20041215) MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: dpapadimitriou@psg.com, "Mack-Crane, T. Benjamin" , Adrian Farrel , Richard Rabbat , Huub van Helvoort , ccamp@ops.ietf.org Subject: Re: {Spam?} Re: Final draft of response to the OIF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dimitri, Dimitri.Papadimitriou@alcatel.be wrote: > > Note 2 refers to transparent STS-N/STM-N signals only (signal types 7 > > through 12), OIF is requesting clarification on the coding of STS-3c SPE > > versus VC-4 (both signal type 6). > > yes, i noticed ;-) this was not the purpose of my first comment > > > Since VC-4 == STS-3c SPE it should be possible to swap both terms > > without making a technical change which is not the case for examples 1 > > and 8. Any such difference is confusing and a potential interworking > > problem. > > so you can flexibily swap between local configuration and not have that > flexibility in the control plane ? This way the control plane will make a distinction which is not present in the data plane and therefore will confuse. > > Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE > > with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE > > elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc > > identical (examples 3 and 9) but not their base signal ?!?... > > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET base spec) > you will that your interpretation is not the one specified in this > recommendation Er, I'm quite familiar with the contents of T1.105-2001 ;-) That content doesn't change my observations about the signal structure above. Note that T1.105 at multiple locations states the VC-4 == STS-3c SPE equivalence. E.g. from the definitions: 3.5 "The equivalent SDH term for an STS-3c SPE is a VC-4. The equivalent SDH term for an STS-Nc (N>3) SPE is a VC-4-Xc, where X=N/3." or, 3.73 "A VC-4 is equivalent to an STS-3c SPE, and a VC-4-Xc is equivalent to an STS-Nc (N=3X) SPE." > " Super rates services are mapped into and transported as STS-Nc SPE > [N=3X there X = 1, 4, 16, 64 or 256]" This is a list of signal names with a "c" in them, as you put it. You have to look at the figures to understand the signal structure and how they relate to each other, which was my point. Also from 7.3: "Two methods for concatenation are defined; contiguous and virtual concatenation. Both methods provide concatenated bandwidth of X times the SPE payload capacity at the path termination." A STS-Nc SPE has a payload capicity of X times the payload capacity of a STS-3c SPE with N=3X. However a STS-Nc SPE does _not_ have a payload capacity of N times the payload capacity of a STS-1 SPE, not even for N=3... > this is exactly what we used in RFC 3946 Regards, Bert Klaps > dimitri papadimitriou wrote: > > ben, > > > > the purpose of the sentence you were initially pointing out addresses as > > generic rule more than the specific case under discussion (reason why i > > pointed to this note 2) from the initial clarification asked by the OIF > > - ditto > > > > "Clarification is requested from IETF CCAMP as to which setting is > > considered correct, or if both settings should be accepted (this > > procedure was used during testing at Supercomm)." > > > > hence, any further discussion is involving much more than the requested > > clarification since questioning the logic behind the settings specified > > in this RFC; as these are pure conventions we may debated them forever, > > however, it suffice that one logic gets consensus (with all what it > > implies), which is the case otherwise this would have not become an RFC > > > > --- > > > > > > Mack-Crane, T. Benjamin wrote: > > > >> Dimitri, > >> > >> Note 2 on page 6 refers to transparent mode, which is a > >> different thing altogether. I think this encoding is > >> poorly chosen as well (and may not allow for the full > >> flexibility of equipment that provides various levels > >> of transparent STS-N/STM-N switching), but that is not > >> currently under discussion. > >> > >> Regards, > >> Ben > >> > >>> -----Original Message----- > >>> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] Sent: > >>> Wednesday, August 31, 2005 2:38 PM > >>> To: Mack-Crane, T. Benjamin > >>> Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort; > ccamp@ops.ietf.org > >>> Subject: Re: Final draft of response to the OIF > >>> > >>> > >>> to clarify: > >>> > >>> > >>>> The example did not adhere to the rule RCC=1 implies NCC>1 > >>>> which was stated in the RFC (and is technically sound) thus > >>>> one could reasonable presume the example was in error. > >>> > >>> > >>> actually your interpretation is not correct - see note 2 of RFC 3946 > >>> (page 6) where the settings RCC=1 can imply NCC=1 is explicitly > stated - > >>> > >>> this said, one of the reason for this setting wrt the specific point > >>> raised by the OIF is due to the logic that has been used in making > >>> use of RCC and NCC value when the signal spelling include a "c" i.e. > >>> STS-(3xN)c SPE so for STS-3c SPE the setting is a logical consequence > >>> of N = 1 > >>> > >>> however, editors have been using a wording for the generic rule which > >>> has not been understood as expected hence the clarification stated > >>> last march on this list - and reproduced in the bis version - > >>> > >>> in brief, all this doesn't deserve this flurry of e-mails wrt to the > >>> specific point to be addressed > >>> > >>> > >>> > >>> > >> > >> ============================================================ > >> 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, 01 Sep 2005 11:55:21 +0000 To: Huub van Helvoort Cc: Dimitri.Papadimitriou@alcatel.be, bertk@txc.com, dpapadimitriou@psg.com, Adrian Farrel , ccamp@ops.ietf.org MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Final draft of response to the OIF Date: Thu, 1 Sep 2005 13:52:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmh1dWIsIDxCUj48QlI+Jmd0OyAmZ3Q7 ICZndDsgU3RhbmRhcmQgY29udGlndW91cyBjb25jYXRlbmF0ZWQgU1RTLU5jIFNQRSBpcyBhY3R1 YWxseSBTVFMtM2MtWGMgU1BFPEJSPiZndDsgJmd0OyAmZ3Q7IHdpdGggTj0zWCBhbmQgWD00LDE2 LDY0LC4uLiB3aGljaCBleHBsYWlucyB0aGUgY29kaW5nIHdpdGggYSBTVFMtM2MgU1BFPEJSPiZn dDsgJmd0OyAmZ3Q7IGVsZW1lbnRhcnkgc2lnbmFsIGFuZCBOQ0M9WC4gU28gd2UgY29kZSB0aGUg U1RTLU5jIFNQRSBhbmQgVkMtNC1YYzxCUj4mZ3Q7ICZndDsgJmd0OyBpZGVudGljYWwgKGV4YW1w bGVzIDMgYW5kIDkpIGJ1dCBub3QgdGhlaXIgYmFzZSBzaWduYWwgPyE/Li4uPEJSPiZndDsgJmd0 OzxCUj4mZ3Q7ICZndDsgaSByZWZlciB5b3UgdG8gc2VjdGlvbiA3LjMuMSBvZiBBTlNJIFQxLjEw NSAtIDIwMDEgKGFrYSBTT05FVCBiYXNlIHNwZWMpPEJSPiZndDsgJmd0OyB5b3Ugd2lsbCB0aGF0 IHlvdXIgaW50ZXJwcmV0YXRpb24gaXMgbm90IHRoZSBvbmUgc3BlY2lmaWVkIGluIHRoaXM8QlI+ Jmd0OyAmZ3Q7IHJlY29tbWVuZGF0aW9uPEJSPiZndDsgJmd0OzxCUj4mZ3Q7ICZndDsgJnF1b3Q7 IFN1cGVyIHJhdGVzIHNlcnZpY2VzIGFyZSBtYXBwZWQgaW50byBhbmQgdHJhbnNwb3J0ZWQgYXMg U1RTLU5jIFNQRTxCUj4mZ3Q7ICZndDsgW049M1ggdGhlcmUgWCA9IDEsIDQsIDE2LCA2NCBvciAy NTZdJnF1b3Q7PEJSPiZndDs8QlI+Jmd0OyBTb21laG93IHlvdSBsZWZ0IG91dCB0aGUgbGFzdCBw YXJ0IGJldHdlZW4gdGhlIHNxdWFyZSBicmFja2V0czo8QlI+Jmd0OyAmcXVvdDtvciBTREggVkMt NCBvciBWQy00LVhjLCB3aGVyZSBYPU4vM10mcXVvdDs8QlI+Jmd0OzxCUj4mZ3Q7IFRoaXMgY2xl YXJseSBtZWFucyB0aGF0IGFuIFNUUy0zYyA9PSBWQy00ID09IHN1cGVyIHJhdGUgb2YgU1RTLTEu PEJSPjwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmluZGVlZCBi dXQgd2UgYXJlIG5vdCBkaXNjdXNzaW5nIHRoaXMgaXNzdWUgb3IgcHV0IHRoaXMgJnF1b3Q7ZXF1 aXZhbGVuY2UmcXVvdDsgdW5kZXIgcXVlc3Rpb25pbmcgKGluIGZhY3QgdGhpcyBpcyByZXByb2R1 Y2VkIGluIHRoZSBzaWduYWwgdHlwZSA2IGRlZmluaXRpb24pIHRoZSBSRkMgdG9vayBhcyBsb2dp YyAoY29udHJvbCBwbGFuZSkgdG8gc2V0IHRoZSBSQ0MgdmFsdWUgd2hlbiB0aGUgbm90YXRpb24g b2YgdGhlIHNpZ25hbCBpbmNsdWRlZCBhICZxdW90O2MmcXVvdDsgd2UgY291bGQgaGF2ZSBjcmVh dGVkIHlldCBhbm90aGVyIGV4Y2VwdGlvbiBidXQgd2UgZGlkIG5vdCAtIGZvciBzZXZlcmFsIHJl YXNvbnMgLTwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPjxCUj4m Z3Q7ICZndDsgdGhpcyBpcyBleGFjdGx5IHdoYXQgd2UgdXNlZCBpbiBSRkMgMzk0NjxCUj48L0ZP TlQ+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+LS08QlI+PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwv Rk9OVD48L1A+PFVMPjxVTD48VUw+PFVMPjxVTD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmll ciI+PEEgSFJFRj1odHRwOi8vd3d3Lmdpcm9uZXQubmwvaG9tZS9pZGVmaWtzLz5odHRwOi8vd3d3 Lmdpcm9uZXQubmwvaG9tZS9pZGVmaWtzLzwvQT48QlI+PEEgSFJFRj1odHRwOi8vbWVtYmVycy5j aGVsbG8ubmwvaGhlbHZvb3J0Lz5odHRwOi8vbWVtYmVycy5jaGVsbG8ubmwvaGhlbHZvb3J0Lzwv QT48L0ZPTlQ+PC9VTD48L1VMPjwvVUw+PC9VTD48L1VMPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFj ZSxDb3VyaWVyIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PEJSPkFsd2F5cyByZW1lbWJlciB0aGF0IHlvdSBhcmUgdW5pcXVl Li4uanVzdCBsaWtlIGV2ZXJ5b25lIGVsc2UuLi48L0ZPTlQ+PC9QPg== Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Sep 2005 10:47:16 +0000 Message-ID: <4316DC09.3010801@chello.nl> Date: Thu, 01 Sep 2005 12:46:33 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: Dimitri.Papadimitriou@alcatel.be CC: bertk@txc.com, dpapadimitriou@psg.com, Adrian Farrel , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Dimitri, You quoted T1.105: --8<-- snipped > > Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE > > with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE > > elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc > > identical (examples 3 and 9) but not their base signal ?!?... > > i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET base spec) > you will that your interpretation is not the one specified in this > recommendation > > " Super rates services are mapped into and transported as STS-Nc SPE > [N=3X there X = 1, 4, 16, 64 or 256]" Somehow you left out the last part between the square brackets: "or SDH VC-4 or VC-4-Xc, where X=N/3]" This clearly means that an STS-3c == VC-4 == super rate of STS-1. > this is exactly what we used in RFC 3946 -- ================================================================ http://www.gironet.nl/home/idefiks/ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Sep 2005 10:18:59 +0000 To: bertk@txc.com Cc: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, "Mack-Crane, T. Benjamin" , Adrian Farrel , Richard Rabbat , Huub van Helvoort , ccamp@ops.ietf.org MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Final draft of response to the OIF Date: Thu, 1 Sep 2005 12:18:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpLDxCUj4gPEJSPiZndDsgSGkgRGlt aXRyaSw8QlI+Jmd0OzxCUj4mZ3Q7IE5vdGUgMiByZWZlcnMgdG8gdHJhbnNwYXJlbnQgU1RTLU4v U1RNLU4gc2lnbmFscyBvbmx5IChzaWduYWwgdHlwZXMgNzxCUj4mZ3Q7IHRocm91Z2ggMTIpLCBP SUYgaXMgcmVxdWVzdGluZyBjbGFyaWZpY2F0aW9uIG9uIHRoZSBjb2Rpbmcgb2YgU1RTLTNjIFNQ RTxCUj4mZ3Q7IHZlcnN1cyBWQy00IChib3RoIHNpZ25hbCB0eXBlIDYpLjxCUj48L0ZPTlQ+PC9Q PjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj55ZXMsIGkgbm90aWNlZCA7LSkgdGhp cyB3YXMgbm90IHRoZSBwdXJwb3NlIG9mIG15IGZpcnN0IGNvbW1lbnQgPC9GT05UPjwvUD48UD48 Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+PEJSPiZndDsgU2luY2UgVkMtNCA9PSBTVFMt M2MgU1BFIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBzd2FwIGJvdGggdGVybXM8QlI+Jmd0OyB3 aXRob3V0IG1ha2luZyBhIHRlY2huaWNhbCBjaGFuZ2Ugd2hpY2ggaXMgbm90IHRoZSBjYXNlIGZv ciBleGFtcGxlcyAxPEJSPiZndDsgYW5kIDguIEFueSBzdWNoIGRpZmZlcmVuY2UgaXMgY29uZnVz aW5nIGFuZCBhIHBvdGVudGlhbCBpbnRlcndvcmtpbmc8QlI+Jmd0OyBwcm9ibGVtLjxCUj48L0ZP TlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5zbyB5b3UgY2FuIGZsZXhp YmlseSBzd2FwIGJldHdlZW4gbG9jYWwgY29uZmlndXJhdGlvbiBhbmQgbm90IGhhdmUgdGhhdCBm bGV4aWJpbGl0eSBpbiB0aGUgY29udHJvbCBwbGFuZSA/PC9GT05UPjwvUD48UD48Rk9OVCBGQUNF PSJNb25vc3BhY2UsQ291cmllciI+PEJSPiZndDsgU3RhbmRhcmQgY29udGlndW91cyBjb25jYXRl bmF0ZWQgU1RTLU5jIFNQRSBpcyBhY3R1YWxseSBTVFMtM2MtWGMgU1BFPEJSPiZndDsgd2l0aCBO PTNYIGFuZCBYPTQsMTYsNjQsLi4uIHdoaWNoIGV4cGxhaW5zIHRoZSBjb2Rpbmcgd2l0aCBhIFNU Uy0zYyBTUEU8QlI+Jmd0OyBlbGVtZW50YXJ5IHNpZ25hbCBhbmQgTkNDPVguIFNvIHdlIGNvZGUg dGhlIFNUUy1OYyBTUEUgYW5kIFZDLTQtWGM8QlI+Jmd0OyBpZGVudGljYWwgKGV4YW1wbGVzIDMg YW5kIDkpIGJ1dCBub3QgdGhlaXIgYmFzZSBzaWduYWwgPyE/Li4uPEJSPjwvRk9OVD48L1A+PFA+ PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmkgcmVmZXIgeW91IHRvIHNlY3Rpb24gNy4z LjEgb2YgQU5TSSBUMS4xMDUgLSAyMDAxIChha2EgU09ORVQgYmFzZSBzcGVjKSB5b3Ugd2lsbCB0 aGF0IHlvdXIgaW50ZXJwcmV0YXRpb24gaXMgbm90IHRoZSBvbmUgc3BlY2lmaWVkIGluIHRoaXMg cmVjb21tZW5kYXRpb248L0ZPTlQ+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVy Ij4mcXVvdDsgU3VwZXIgcmF0ZXMgc2VydmljZXMgYXJlIG1hcHBlZCBpbnRvIGFuZCB0cmFuc3Bv cnRlZCBhcyBTVFMtTmMgU1BFIFtOPTNYIHRoZXJlIFggPSAxLCA0LCAxNiwgNjQgb3IgMjU2XSZx dW90OzwvRk9OVD48L1A+PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPnRoaXMgaXMg ZXhhY3RseSB3aGF0IHdlIHVzZWQgaW4gUkZDIDM5NDY8L0ZPTlQ+PC9QPjxQPiZuYnNwOzwvUD48 UD48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+dGhhbmtzIGFuZCBnb29kIGJ5ZTwvRk9O VD48L1A+PFA+Jm5ic3A7PC9QPjxQPiZuYnNwOzwvUD48UD4mbmJzcDs8L1A+PFA+PEJSPjxGT05U IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5SZWdhcmRzLDxCUj5CZXJ0IEtsYXBzPEJSPjwvRk9O VD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmRpbWl0cmkgcGFwYWRpbWl0cmlv dSB3cm90ZTo8QlI+Jmd0OyBiZW4sPEJSPiZndDs8QlI+Jmd0OyB0aGUgcHVycG9zZSBvZiB0aGUg c2VudGVuY2UgeW91IHdlcmUgaW5pdGlhbGx5IHBvaW50aW5nIG91dCBhZGRyZXNzZXMgYXM8QlI+ Jmd0OyBnZW5lcmljIHJ1bGUgbW9yZSB0aGFuIHRoZSBzcGVjaWZpYyBjYXNlIHVuZGVyIGRpc2N1 c3Npb24gKHJlYXNvbiB3aHkgaTxCUj4mZ3Q7IHBvaW50ZWQgdG8gdGhpcyBub3RlIDIpIGZyb20g dGhlIGluaXRpYWwgY2xhcmlmaWNhdGlvbiBhc2tlZCBieSB0aGUgT0lGPEJSPiZndDsgLSBkaXR0 bzxCUj4mZ3Q7PEJSPiZndDsgJnF1b3Q7Q2xhcmlmaWNhdGlvbiBpcyByZXF1ZXN0ZWQgZnJvbSBJ RVRGIENDQU1QIGFzIHRvIHdoaWNoIHNldHRpbmcgaXM8QlI+Jmd0OyBjb25zaWRlcmVkIGNvcnJl Y3QsIG9yIGlmIGJvdGggc2V0dGluZ3Mgc2hvdWxkIGJlIGFjY2VwdGVkICh0aGlzPEJSPiZndDsg cHJvY2VkdXJlIHdhcyB1c2VkIGR1cmluZyB0ZXN0aW5nIGF0IFN1cGVyY29tbSkuJnF1b3Q7PEJS PiZndDs8QlI+Jmd0OyBoZW5jZSwgYW55IGZ1cnRoZXIgZGlzY3Vzc2lvbiBpcyBpbnZvbHZpbmcg bXVjaCBtb3JlIHRoYW4gdGhlIHJlcXVlc3RlZDxCUj4mZ3Q7IGNsYXJpZmljYXRpb24gc2luY2Ug cXVlc3Rpb25pbmcgdGhlIGxvZ2ljIGJlaGluZCB0aGUgc2V0dGluZ3Mgc3BlY2lmaWVkPEJSPiZn dDsgaW4gdGhpcyBSRkM7IGFzIHRoZXNlIGFyZSBwdXJlIGNvbnZlbnRpb25zIHdlIG1heSBkZWJh dGVkIHRoZW0gZm9yZXZlciw8QlI+Jmd0OyBob3dldmVyLCBpdCBzdWZmaWNlIHRoYXQgb25lIGxv Z2ljIGdldHMgY29uc2Vuc3VzICh3aXRoIGFsbCB3aGF0IGl0PEJSPiZndDsgaW1wbGllcyksIHdo aWNoIGlzIHRoZSBjYXNlIG90aGVyd2lzZSB0aGlzIHdvdWxkIGhhdmUgbm90IGJlY29tZSBhbiBS RkM8QlI+Jmd0OzxCUj4mZ3Q7IC0tLTxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBNYWNrLUNyYW5l LCBULiBCZW5qYW1pbiB3cm90ZTo8QlI+Jmd0OzxCUj4mZ3Q7Jmd0OyBEaW1pdHJpLDxCUj4mZ3Q7 Jmd0OzxCUj4mZ3Q7Jmd0OyBOb3RlIDIgb24gcGFnZSA2IHJlZmVycyB0byB0cmFuc3BhcmVudCBt b2RlLCB3aGljaCBpcyBhPEJSPiZndDsmZ3Q7IGRpZmZlcmVudCB0aGluZyBhbHRvZ2V0aGVyLiAm bmJzcDtJIHRoaW5rIHRoaXMgZW5jb2RpbmcgaXM8QlI+Jmd0OyZndDsgcG9vcmx5IGNob3NlbiBh cyB3ZWxsIChhbmQgbWF5IG5vdCBhbGxvdyBmb3IgdGhlIGZ1bGw8QlI+Jmd0OyZndDsgZmxleGli aWxpdHkgb2YgZXF1aXBtZW50IHRoYXQgcHJvdmlkZXMgdmFyaW91cyBsZXZlbHM8QlI+Jmd0OyZn dDsgb2YgdHJhbnNwYXJlbnQgU1RTLU4vU1RNLU4gc3dpdGNoaW5nKSwgYnV0IHRoYXQgaXMgbm90 PEJSPiZndDsmZ3Q7IGN1cnJlbnRseSB1bmRlciBkaXNjdXNzaW9uLjxCUj4mZ3Q7Jmd0OzxCUj4m Z3Q7Jmd0OyBSZWdhcmRzLDxCUj4mZ3Q7Jmd0OyBCZW48QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsm Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPiZndDsmZ3Q7Jmd0OyBGcm9tOiBkaW1p dHJpIHBhcGFkaW1pdHJpb3UgW21haWx0bzpkcGFwYWRpbWl0cmlvdUBwc2cuY29tXSBTZW50OjxC Uj4mZ3Q7Jmd0OyZndDsgV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMDUgMjozOCBQTTxCUj4mZ3Q7 Jmd0OyZndDsgVG86IE1hY2stQ3JhbmUsIFQuIEJlbmphbWluPEJSPiZndDsmZ3Q7Jmd0OyBDYzog QWRyaWFuIEZhcnJlbDsgUmljaGFyZCBSYWJiYXQ7IEh1dWIgdmFuIEhlbHZvb3J0OyBjY2FtcEBv cHMuaWV0Zi5vcmc8QlI+Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBGaW5hbCBkcmFmdCBvZiBy ZXNwb25zZSB0byB0aGUgT0lGPEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0 OyZndDsmZ3Q7IHRvIGNsYXJpZnk6PEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDs8QlI+ Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgZXhhbXBsZSBkaWQgbm90IGFkaGVyZSB0byB0aGUgcnVsZSBS Q0M9MSBpbXBsaWVzIE5DQyZndDsxPEJSPiZndDsmZ3Q7Jmd0OyZndDsgd2hpY2ggd2FzIHN0YXRl ZCBpbiB0aGUgUkZDIChhbmQgaXMgdGVjaG5pY2FsbHkgc291bmQpIHRodXM8QlI+Jmd0OyZndDsm Z3Q7Jmd0OyBvbmUgY291bGQgcmVhc29uYWJsZSBwcmVzdW1lIHRoZSBleGFtcGxlIHdhcyBpbiBl cnJvci48QlI+Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDsgYWN0 dWFsbHkgeW91ciBpbnRlcnByZXRhdGlvbiBpcyBub3QgY29ycmVjdCAtIHNlZSBub3RlIDIgb2Yg UkZDIDM5NDY8QlI+Jmd0OyZndDsmZ3Q7IChwYWdlIDYpIHdoZXJlIHRoZSBzZXR0aW5ncyBSQ0M9 MSBjYW4gaW1wbHkgTkNDPTEgaXMgZXhwbGljaXRseSBzdGF0ZWQgLTxCUj4mZ3Q7Jmd0OyZndDs8 QlI+Jmd0OyZndDsmZ3Q7IHRoaXMgc2FpZCwgb25lIG9mIHRoZSByZWFzb24gZm9yIHRoaXMgc2V0 dGluZyB3cnQgdGhlIHNwZWNpZmljIHBvaW50PEJSPiZndDsmZ3Q7Jmd0OyByYWlzZWQgYnkgdGhl IE9JRiBpcyBkdWUgdG8gdGhlIGxvZ2ljIHRoYXQgaGFzIGJlZW4gdXNlZCBpbiBtYWtpbmc8QlI+ Jmd0OyZndDsmZ3Q7IHVzZSBvZiBSQ0MgYW5kIE5DQyB2YWx1ZSB3aGVuIHRoZSBzaWduYWwgc3Bl bGxpbmcgaW5jbHVkZSBhICZxdW90O2MmcXVvdDsgaS5lLjxCUj4mZ3Q7Jmd0OyZndDsgU1RTLSgz eE4pYyBTUEUgc28gZm9yIFNUUy0zYyBTUEUgdGhlIHNldHRpbmcgaXMgYSBsb2dpY2FsIGNvbnNl cXVlbmNlPEJSPiZndDsmZ3Q7Jmd0OyBvZiBOID0gMTxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0OyZn dDsmZ3Q7IGhvd2V2ZXIsIGVkaXRvcnMgaGF2ZSBiZWVuIHVzaW5nIGEgd29yZGluZyBmb3IgdGhl IGdlbmVyaWMgcnVsZSB3aGljaDxCUj4mZ3Q7Jmd0OyZndDsgaGFzIG5vdCBiZWVuIHVuZGVyc3Rv b2QgYXMgZXhwZWN0ZWQgaGVuY2UgdGhlIGNsYXJpZmljYXRpb24gc3RhdGVkPEJSPiZndDsmZ3Q7 Jmd0OyBsYXN0IG1hcmNoIG9uIHRoaXMgbGlzdCAtIGFuZCByZXByb2R1Y2VkIGluIHRoZSBiaXMg dmVyc2lvbiAtPEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDsgaW4gYnJpZWYsIGFsbCB0 aGlzIGRvZXNuJ3QgZGVzZXJ2ZSB0aGlzIGZsdXJyeSBvZiBlLW1haWxzIHdydCB0byB0aGU8QlI+ Jmd0OyZndDsmZ3Q7IHNwZWNpZmljIHBvaW50IHRvIGJlIGFkZHJlc3NlZDxCUj4mZ3Q7Jmd0OyZn dDs8QlI+Jmd0OyZndDsmZ3Q7PEJSPiZndDsmZ3Q7Jmd0OzxCUj4mZ3Q7Jmd0OyZndDs8QlI+Jmd0 OyZndDs8QlI+Jmd0OyZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PEJSPiZndDsmZ3Q7IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBwcml2aWxlZ2VkPEJSPiZndDsmZ3Q7IGFuZCBjb25m aWRlbnRpYWwgYW5kIHByb3RlY3RlZCBmcm9tIGRpc2Nsb3N1cmUuIElmIHRoZSByZWFkZXI8QlI+ Jmd0OyZndDsgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBv ciBhbiBlbXBsb3llZTxCUj4mZ3Q7Jmd0OyBvciBhZ2VudCByZXNwb25zaWJsZSBmb3IgZGVsaXZl cmluZyB0aGlzIG1lc3NhZ2UgdG8gdGhlPEJSPiZndDsmZ3Q7IGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgcmVwcm9kdWN0aW9uLDxCUj4mZ3Q7Jmd0 OyBkaXNzZW1pbmF0aW9uIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMg c3RyaWN0bHk8QlI+Jmd0OyZndDsgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBjb21tdW5pY2F0aW9uIGluIGVycm9yLDxCUj4mZ3Q7Jmd0OyBwbGVhc2Ugbm90aWZ5IHVzIGlt bWVkaWF0ZWx5IGJ5IHJlcGx5aW5nIHRvIHRoZSBtZXNzYWdlIGFuZDxCUj4mZ3Q7Jmd0OyBkZWxl dGluZyBpdCBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlvdS4gVGVsbGFiczxCUj4mZ3Q7Jmd0 OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDs8QlI+Jmd0OyZndDsgLjxCUj4mZ3Q7Jmd0OzxC Uj4mZ3Q7PC9GT05UPjwvUD4= Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Sep 2005 10:15:05 +0000 Sensitivity: Subject: Comments on draft-kim-ccamp-cc-protection-04 To: ccamp@ops.ietf.org, yhwkim@etri.re.kr Message-ID: From: "Diego Caviglia" Date: Thu, 1 Sep 2005 12:13:44 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi all, I'd like to make some comments on the ID in the subjec. Section 7 In general, there may be several advantages of out-of-fiber over in- fiber such as the followings: [dc] I don't agree with this sentence. I don't think that there are advantes in the usage of out-of-fiber. - When using the overhead bytes of SONET/SDH as a control channel, in-fiber may require more resources such as HDLC controllers whereas out-of-fiber could reduce the number of these resources; [dc] This is a strange sentece. SONET/SDH DCC have not been developed for GMPLS, are there since several years and seems very strange to me to think about a SONET/SDH box that do not support DCC processing. - In case of only in-fiber, it looks that there is no room or no need for protecting control channels. However, out-of-fiber may apply the various and effective software based protection schemes; [dc] Why there is no room for protecting control channels? Do you have any figures about this? The line level DCC is 576 kbps while the section DCC is 192 kbps. Do you thing the control traffic will be more than that? - In-fiber is difficult to separate control plane from transport plane, whereas out-of-fiber is easy to separate control plane; [dc] IMHO this is not true and moreover you need to explain why is more difficult. Today DCC are widely used to transport management traffic and there are no difficulties in order to separate management from data traffic. - Because in-fiber provides the connection control function only within a single fiber, in-fiber could not provide the connection control function beyond a single fiber, whereas out-of-fiber has no restriction about the number of fibers for the connection control function. [dc] Could you explain me a little bit more this? I don't see anything that prevent me to set-up more that one CC on a fiber. [quote] When the out-of-fiber configuration is used, control channels may be shared to handle several fibers [/quote] [dc] IMHO the cc are associated to the TE and not to the fibre, so a single CC can serve several TE link and thus several fibre; this is not related on how it is implemented. [quote] Consequently, to provide the resilience capability of control channels, it is reasonable to use out-of-fiber rather than in-fiber for GMPLS. [quote/] [dc] I don't see how the previous sentences can lead to this statement. What is reasonable is that the control channels must be resilient but this don't implies the fact they should be out-of-fiber. Regards Diego Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 01 Sep 2005 08:46:00 +0000 Message-ID: <4316BF41.1070204@txc.com> Date: Thu, 01 Sep 2005 10:43:45 +0200 From: Bert Klaps Reply-To: bertk@txc.com User-Agent: Mozilla Thunderbird 1.0 (X11/20041215) MIME-Version: 1.0 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be CC: "Mack-Crane, T. Benjamin" , Adrian Farrel , Richard Rabbat , Huub van Helvoort , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dimitri, Note 2 refers to transparent STS-N/STM-N signals only (signal types 7 through 12), OIF is requesting clarification on the coding of STS-3c SPE versus VC-4 (both signal type 6). Since VC-4 == STS-3c SPE it should be possible to swap both terms without making a technical change which is not the case for examples 1 and 8. Any such difference is confusing and a potential interworking problem. Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc identical (examples 3 and 9) but not their base signal ?!?... Regards, Bert Klaps dimitri papadimitriou wrote: > ben, > > the purpose of the sentence you were initially pointing out addresses as > generic rule more than the specific case under discussion (reason why i > pointed to this note 2) from the initial clarification asked by the OIF > - ditto > > "Clarification is requested from IETF CCAMP as to which setting is > considered correct, or if both settings should be accepted (this > procedure was used during testing at Supercomm)." > > hence, any further discussion is involving much more than the requested > clarification since questioning the logic behind the settings specified > in this RFC; as these are pure conventions we may debated them forever, > however, it suffice that one logic gets consensus (with all what it > implies), which is the case otherwise this would have not become an RFC > > --- > > > Mack-Crane, T. Benjamin wrote: > >> Dimitri, >> >> Note 2 on page 6 refers to transparent mode, which is a >> different thing altogether. I think this encoding is >> poorly chosen as well (and may not allow for the full >> flexibility of equipment that provides various levels >> of transparent STS-N/STM-N switching), but that is not >> currently under discussion. >> >> Regards, >> Ben >> >>> -----Original Message----- >>> From: dimitri papadimitriou [mailto:dpapadimitriou@psg.com] Sent: >>> Wednesday, August 31, 2005 2:38 PM >>> To: Mack-Crane, T. Benjamin >>> Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort; ccamp@ops.ietf.org >>> Subject: Re: Final draft of response to the OIF >>> >>> >>> to clarify: >>> >>> >>>> The example did not adhere to the rule RCC=1 implies NCC>1 >>>> which was stated in the RFC (and is technically sound) thus >>>> one could reasonable presume the example was in error. >>> >>> >>> actually your interpretation is not correct - see note 2 of RFC 3946 >>> (page 6) where the settings RCC=1 can imply NCC=1 is explicitly stated - >>> >>> this said, one of the reason for this setting wrt the specific point >>> raised by the OIF is due to the logic that has been used in making >>> use of RCC and NCC value when the signal spelling include a "c" i.e. >>> STS-(3xN)c SPE so for STS-3c SPE the setting is a logical consequence >>> of N = 1 >>> >>> however, editors have been using a wording for the generic rule which >>> has not been understood as expected hence the clarification stated >>> last march on this list - and reproduced in the bis version - >>> >>> in brief, all this doesn't deserve this flurry of e-mails wrt to the >>> specific point to be addressed >>> >>> >>> >>> >> >> ============================================================ >> 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 >> ============================================================ >> >> >> . >> >