From owner-ccamp@ops.ietf.org Mon Aug 01 04:16:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzVTZ-0004I5-6Z for ccamp-archive@megatron.ietf.org; Mon, 01 Aug 2005 04:16: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 EAA04643 for ; Mon, 1 Aug 2005 04:16:43 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzVzn-0003Ui-Oo for ccamp-archive@ietf.org; Mon, 01 Aug 2005 04:50:04 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzVLY-000Ner-8n for ccamp-data@psg.com; Mon, 01 Aug 2005 08:08:28 +0000 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzVLU-000NeP-I9 for ccamp@ops.ietf.org; Mon, 01 Aug 2005 08:08:24 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 10:08:18 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt Date: Mon, 1 Aug 2005 10:08:17 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt Thread-Index: AcWU6UF6wMowosxgRreHsS9OWN0BPQBhkwkg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , Cc: , , X-OriginalArrivalTime: 01 Aug 2005 08:08:18.0507 (UTC) FILETIME=[2CFAE1B0:01C59670] 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: 2d133cc328f58695161c98bb4f4dc213 Content-Transfer-Encoding: quoted-printable Hi Adrian, See inline =20 > -----Message d'origine----- > De : Adrian Farrel [mailto:olddog@clara.co.uk]=20 > Envoy=E9 : samedi 30 juillet 2005 11:30 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Dimitri.Papadimitriou@alcatel.be > Cc : arthi@juniper.net; ccamp@ops.ietf.org; jpv@cisco.com;=20 > zzx-adrian@olddog.co.uk > Objet : Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt >=20 > Hi,=20 >=20 > Time for me to speak out about the omission of hitherto=20 > mandatory objects from signaling messages.=20 >=20 > I would MUCH prefer that you keep the objects (Upstream Label=20 > or Path, Label on Resv) and use a special label value=20 > (implicit null? some new reserved label value?) to mean=20 > "stitch this".=20 I agree with you.=20 Actually this is what I suggested in the previous email, see below > > JLLR: Yes, and what about defining a new MPLS label value, let say=20 > > label > > 4 =3D "No label assigned", with a semantic distinct from label=20 > >3 semantic (=3Dlabel pop). The UPSTREAM label object with this=20 > >new label value would be included in the end-to-end Path=20 > >message over the LSP-Segment... Regards, JL >=20 > For me this is more natural and is less of a significant=20 > change to the existing protocol and implementation.=20 >=20 > It also solves the bidirection problem.=20 >=20 > Opinions?=20 >=20 > Cheers, > Adrian=20 >=20 >=20 > ----- Original Message ----- > From: > To: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > Cc: "Arthi Ayyangar" ;=20 > ; > Sent: Friday, July 29, 2005 9:39 PM > Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt=20 >=20 >=20 > > > > hi j-l, arthi > > > > > > > > -In section 4.1.2 you partially describe bidirectional LSP > > > stitching > > > > procedure. You mention that an Upstream Label MUST NOT be > > > allocated by > > > > the end-to-end LSP on the LSP segment, which is OK. But > > > then how the > > > > LSP-Segment Egress will now that the end-to-end LSP is > > > bidirectional? > > > AA--------> Excellent point. > > > > > > > What about defining a flag in the Attributes Flags TLV of the=20 > > > > LSP_ATTRIBUTE object so as to indicate that the LSP is > > > bidirectional? > > > AA------> That would be a change to the processing that GMPLS > > > nodes use > > > AA------> to > > > detect bidirectionality, isn't it ? Normally nodes look for the=20 > > > Upstream Label object to detect bidirectionality. > > > > > > So let us say that an LSP is bidirectional if a) an=20 > Upstream Label=20 > > > is present or b) no Upstream Label, but bit set in=20 > LSP_ATTRIBUTE or=20 > > > c) both However, reliance on an e2e attributes bit set by=20 > head end,=20 > > > means existing head ends will not be setting this bit, so=20 > that will=20 > > > be an issue (wrt compatibility). > > > > JLLR: I agree this may raise some backward compatibility issues. > > This would require that head-ends be upgraded...=20 > > > > > > DP: the other issue is having two methods for indicating the same=20 > > thing > is also not advisable > >=20 > > > > > Could be nice if this signaling was just between the node=20 > doing the=20 > > > stitching and the end point of the LSP segment, since this is the=20 > > > hop that the bidirectionality information is lost. Let me think=20 > > > about this. > > > > JLLR: Yes, and what about defining a new MPLS label value, let say=20 > > label > 4 =3D "No label assigned", with a semantic distinct from label=20 > 3 semantic (=3Dlabel pop). The UPSTREAM label object with this=20 > new label value would be included in the end-to-end Path=20 > message over the LSP-Segment... > >=20 > > > > DP: assuming an information has to be passed for the indicating this > capability i do also think a method like passing an implicit=20 > indication in the upstream label value would be more=20 > appropriated (note that the initial issue is due to the fact=20 > one would allow for unidirectional e2e LSP making use of=20 > bidirectional LSP segments - see comment from J-L here below=20 > - and not maintaining a 1:1 relationship for the=20 > directionality between the e2e LSP and the LSP segment that=20 > can be retrieved with the procedure described in section=20 > 4.2.4 - and so the first question is it worth allowing this?) > >=20 > > > > > > Also the selection of the LSP segment in case of=20 > bidirectional LSP=20 > > > > should be detailed (e.g. If the end-to-end LSP is > > > bidirecitonal then > > > > the LSP-segment MUST be bidirectional. Also shall we allow that=20 > > > > two unidrectional end-to-end LSP use the same bidirectional LSP=20 > > > > segment (one in each direction)? > > > AA----> Yes, this should be okay. IMO. > > > > > > > -At the end of section 4.2.5 you mention that LSP-Segment > > > failure or > > > > maintenance SHOULD be treated as a failure event for the > > > end-to-end LSP. > > > > I agree for LSP-Segment failure but not for LSP-Segment=20 > maintenance. > > > > LSP-Segment maintenance should be treated as TE-link > > > maintenance for > > > > the end-to-end LSP, and procedures defined in GMPLS > > > graceful TE-link > > > > shutdown draft may be useful (Specific RSVP error code=20 > and TE-link=20 > > > > attribute)... > > > AA---> Yes, I agree; we will mention this. Actually the graceful=20 > > > AA---> teardown > > > sentence occurs few paragraphs before, but not in the=20 > right context.=20 > > > So we will clarify the above. > > > > > > DP: i am not sure to understand the comment, the sentence=20 > speaks about > deletion of the LSP segment due to failure/maintenance should=20 > be treated as a failure event for the e2e LSP, so i don't=20 > think the initial sentence was meant to translated the=20 > initial comment, anyway it would be of interest that you=20 > detail the error code > > > > DP: note also that section 4.2.5 indicates that for stitched LSPs > Graceful deletion can be used - i perfectly agree - but the=20 > sequence should be detailed as part of this section > >=20 > > > > > > Hope this helps, > > > AA---> Sure does. > > > > > > > > > Thanks! > > > > > > -arthi > > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > De : owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] De la part de=20 > > > > > Internet-Drafts@ietf.org Envoy=E9 : vendredi 15 juillet > > > 2005 21:50 =C0 : > > > > > i-d-announce@ietf.org Cc : ccamp@ops.ietf.org Objet : I-D=20 > > > > > ACTION:draft-ietf-ccamp-lsp-stitching-01.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=20 > Measurement=20 > > > > > Plane Working Group of the IETF. > > > > > > > > > > Title: Label Switched Path Stitching with Generalized MPLS=20 > > > > > Traffic Engineering > > > > > Author(s): A. Ayyangar, J. Vasseur > > > > > Filename: draft-ietf-ccamp-lsp-stitching-01.txt > > > > > Pages: 19 > > > > > Date: 2005-7-15 > > > > > > > > > > In certain scenarios, there may be a need to combine=20 > together two > > > > > 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 achieved 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=20 > 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 might be > > > possible to > > > > > configure a GMPLS node to switch the traffic from=20 > an LSP for=20 > > > > > which it > > > > > is the egress, to another LSP for which it is the > > > ingress, without > > > > > requiring any signaling or routing extensions whatsoever,=20 > > > > > completely > > > > > transparent to other nodes. This will also result in > > > LSP stitching > > > > > in the data plane. However, this document does=20 > not cover this > > > > > scenario of LSP stitching. > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitc > > > > hing-01.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.=20 > > > > > After logging in, type "cd internet-drafts" and then "get=20 > > > > > draft-ietf-ccamp-lsp-stitching-01.txt". > > > > > > > > > > A list of Internet-Drafts directories can be found in=20 > > > > > http://www.ietf.org/shadow.html or=20 > > > > > 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-01.txt". > > > > > > > > > > NOTE:The mail server at ietf.org can return the document in=20 > > > > > MIME-encoded form by using the "mpack" utility. To use this=20 > > > > > feature, insert the command "ENCODING mime" before the "FILE" > > > > > command. To decode the response(s), you will need=20 > "munpack" or=20 > > > > > a MIME-compliant mail reader. Different MIME-compliant mail=20 > > > > > readers exhibit different behavior, especially when=20 > dealing with=20 > > > > > "multipart" MIME messages (i.e. documents which have=20 > been split=20 > > > > > up into multiple messages), so check your local=20 > documentation on=20 > > > > > how to manipulate these messages. > > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant=20 > mail reader=20 > > > > > implementation to automatically retrieve the ASCII version of=20 > > > > > the Internet-Draft. > > > > > > > > > > > >=20 > > >=20 >=20 From owner-ccamp@ops.ietf.org Mon Aug 01 20:13:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzkPh-0003SZ-Tw for ccamp-archive@megatron.ietf.org; Mon, 01 Aug 2005 20:13: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 UAA03948 for ; Mon, 1 Aug 2005 20:13:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzkw4-0008II-CP for ccamp-archive@ietf.org; Mon, 01 Aug 2005 20:47:13 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzkGD-000BaW-NK for ccamp-data@psg.com; Tue, 02 Aug 2005 00:03:57 +0000 Received: from [86.255.2.7] (helo=pollux.ietf63.ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzkGB-000BaC-3a for ccamp@ops.ietf.org; Tue, 02 Aug 2005 00:03:55 +0000 Received: from Puppy (unknown [86.255.16.120]) by pollux.ietf63.ietf.org (Postfix) with SMTP id 4C7F437; Mon, 1 Aug 2005 17:03:54 -0700 (PDT) Message-ID: <00b001c596f6$07f38c10$7810ff56@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Huub van Helvoort" , "ccamp" References: <42ECDE6F.5000903@chello.nl> Subject: Re: LCAS and GMPLS Date: Tue, 2 Aug 2005 01:04:34 +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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Hi Huub, Wataru, I think the original proposal is that SG15 may want to send CCAMP a liaison about this work. That would certainly be fine. I don't think that CCAMP can send a liaison back to support the work without having seen it first. With regard to the solution space for the problem: - If the solution lies entirely within LCAS then it is out of scope for CCAMP. The LSP will simply be torn down when the LCAS synchronization has been done. - If the problem is to be solved within GMPLS, then we have a suitable mechanism already. Thus, it turns out that it is important to scope problems not just functionally, but according to which components are intended to resolve them. Very obviously, the industry does not need or want two solutions to the same problem. Adrian ----- Original Message ----- From: "Huub van Helvoort" To: "ccamp" Sent: Sunday, July 31, 2005 3:21 PM Subject: Re: LCAS and GMPLS > Hello Wataru, > > You wrote: > > > I forward a nice comment from Mr. Huub van Helvoort. > > Thank you for forwarding. > (I hope I can send this message the list myself). > > > His comments indicates we need liason from ITU-T SG-15 regarding to > > this issue. > > This is a good proposal, it will indicate to ITU-T SG15/Q11 > that IETF/CCAMP supports this enhancement. > > Kind regards, Huub. > > --- from message 27-7-2005 --- > > >> > >> One point for the problem statement could be that in order to > >> guarantee a hitless removal of one of the members in a VCG > >> (decrease of bandwidth) there is a mandatory sequence: > >> First remove member at ingress node, wait for confirm and > >> only then remove path and member at egress node. > >> > >> However, a solution was presented at the last ITU-T SG15/q11 > >> meeting that removes this requirement. > >> > >> Cheers, Huub. > > -- > ================================================================ > http://members.chello.nl/hhelvoort/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > From owner-ccamp@ops.ietf.org Mon Aug 01 20:35:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzkkT-0007rk-0n for ccamp-archive@megatron.ietf.org; Mon, 01 Aug 2005 20:35:13 -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 UAA04967 for ; Mon, 1 Aug 2005 20:35:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzlGj-0000bf-AN for ccamp-archive@ietf.org; Mon, 01 Aug 2005 21:08:41 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dzke2-000Def-CE for ccamp-data@psg.com; Tue, 02 Aug 2005 00:28:34 +0000 Received: from [216.82.255.211] (helo=mail120.messagelabs.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1Dzkdz-000DeP-Py for ccamp@ops.ietf.org; Tue, 02 Aug 2005 00:28:31 +0000 X-VirusChecked: Checked X-Env-Sender: adrian@olddog.co.uk X-Msg-Ref: server-3.tower-120.messagelabs.com!1122942401!4769554!10 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.167.132] Received: (qmail 10466 invoked from network); 2 Aug 2005 00:28:30 -0000 Received: from unknown (HELO attrh2i.attrh.att.com) (192.128.167.132) by server-3.tower-120.messagelabs.com with SMTP; 2 Aug 2005 00:28:30 -0000 Received: from ACCLUST04EVS1.ugd.att.com (135.37.16.12) by attrh2i.attrh.att.com (7.2.052) id 42DA81B8004DCD92; Mon, 1 Aug 2005 20:28:30 -0400 Received: from mail pickup service by ACCLUST04EVS1.ugd.att.com with Microsoft SMTPSVC; Mon, 1 Aug 2005 20:28:29 -0400 Received: from acclust03evs1.ugd.att.com ([135.37.16.10]) by ACCLUST04EVS1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Aug 2005 20:07:02 -0400 Received: from ocfe02.ugd.att.com ([135.38.164.17]) by acclust03evs1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Aug 2005 20:07:02 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ocfe02.ugd.att.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Aug 2005 19:07:00 -0500 Received: from mail120.messagelabs.com (216.82.255.211) by attrh5i.attrh.att.com (7.2.052) id 42DA81F0003D512E; Mon, 1 Aug 2005 20:07:00 -0400 X-VirusChecked: Checked X-Env-Sender: owner-ccamp@ops.ietf.org X-Msg-Ref: server-3.tower-120.messagelabs.com!1122941218!4768926!1 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [147.28.0.62] X-SpamReason: No, hits=0.0 required=7.0 tests= Received: (qmail 32647 invoked from network); 2 Aug 2005 00:06:58 -0000 Received: from psg.com (147.28.0.62) by server-3.tower-120.messagelabs.com with SMTP; 2 Aug 2005 00:06:58 -0000 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzkGD-000BaW-NK for ccamp-data@psg.com; Tue, 02 Aug 2005 00:03:57 +0000 Received: from [86.255.2.7] (helo=pollux.ietf63.ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzkGB-000BaC-3a for ccamp@ops.ietf.org; Tue, 02 Aug 2005 00:03:55 +0000 Received: from Puppy (unknown [86.255.16.120]) by pollux.ietf63.ietf.org (Postfix) with SMTP id 4C7F437; Mon, 1 Aug 2005 17:03:54 -0700 (PDT) Message-ID: <00b001c596f6$07f38c10$7810ff56@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Huub van Helvoort" , "ccamp" References: <42ECDE6F.5000903@chello.nl> Subject: Re: LCAS and GMPLS Date: Tue, 2 Aug 2005 01:04:34 +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-OriginalArrivalTime: 02 Aug 2005 00:07:00.0992 (UTC) FILETIME=[1B0D8800:01C596F6] 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=unavailable version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Hi Huub, Wataru, I think the original proposal is that SG15 may want to send CCAMP a liaison about this work. That would certainly be fine. I don't think that CCAMP can send a liaison back to support the work without having seen it first. With regard to the solution space for the problem: - If the solution lies entirely within LCAS then it is out of scope for CCAMP. The LSP will simply be torn down when the LCAS synchronization has been done. - If the problem is to be solved within GMPLS, then we have a suitable mechanism already. Thus, it turns out that it is important to scope problems not just functionally, but according to which components are intended to resolve them. Very obviously, the industry does not need or want two solutions to the same problem. Adrian ----- Original Message ----- From: "Huub van Helvoort" To: "ccamp" Sent: Sunday, July 31, 2005 3:21 PM Subject: Re: LCAS and GMPLS > Hello Wataru, > > You wrote: > > > I forward a nice comment from Mr. Huub van Helvoort. > > Thank you for forwarding. > (I hope I can send this message the list myself). > > > His comments indicates we need liason from ITU-T SG-15 regarding to > > this issue. > > This is a good proposal, it will indicate to ITU-T SG15/Q11 > that IETF/CCAMP supports this enhancement. > > Kind regards, Huub. > > --- from message 27-7-2005 --- > > >> > >> One point for the problem statement could be that in order to > >> guarantee a hitless removal of one of the members in a VCG > >> (decrease of bandwidth) there is a mandatory sequence: > >> First remove member at ingress node, wait for confirm and > >> only then remove path and member at egress node. > >> > >> However, a solution was presented at the last ITU-T SG15/q11 > >> meeting that removes this requirement. > >> > >> Cheers, Huub. > > -- > ================================================================ > http://members.chello.nl/hhelvoort/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > From owner-ccamp@ops.ietf.org Tue Aug 02 05:05:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzsho-0001EO-3j for ccamp-archive@megatron.ietf.org; Tue, 02 Aug 2005 05:05:00 -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 FAA01181 for ; Tue, 2 Aug 2005 05:04:57 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztEA-0003jp-Q9 for ccamp-archive@ietf.org; Tue, 02 Aug 2005 05:38:32 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzsSs-000OE8-O5 for ccamp-data@psg.com; Tue, 02 Aug 2005 08:49:34 +0000 Received: from [213.46.243.25] (helo=amsfep16-int.chello.nl) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzsSq-000OCy-58 for ccamp@ops.ietf.org; Tue, 02 Aug 2005 08:49:32 +0000 Received: from [192.168.1.4] (really [24.132.27.149]) by amsfep16-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050802084927.OYFB2060.amsfep16-int.chello.nl@[192.168.1.4]>; Tue, 2 Aug 2005 10:49:27 +0200 Message-ID: <42EF3395.5@chello.nl> Date: Tue, 02 Aug 2005 10:49:25 +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: ccamp CC: Adrian Farrel Subject: Re: LCAS and GMPLS References: <42ECDE6F.5000903@chello.nl> <00b001c596f6$07f38c10$7810ff56@Puppy> In-Reply-To: <00b001c596f6$07f38c10$7810ff56@Puppy> Content-Type: text/plain; charset=windows-1252; 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: 1.2 (+) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA01181 Hello Adrian, Thanks for your comments. I shall try to give some more insight. You wrote: > I think the original proposal is that SG15 may want to send CCAMP a > liaison about this work. That would certainly be fine. [hvh] I tried but did not get enough support > I don't think that CCAMP can send a liaison back to support the work > without having seen it first. [hvh] both draft-imajuku-ccamp-gmpls-vcat-lagr-req and draft-bernstein-LCAS-GMPLS refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this recommendation contains the following note: "NOTE =96 If a permanent removal of an active member is initiated at the=20 Sk, this will result in a hit to the reconstructed data. The duration of=20 this hit will be from the time the member is removed (starts sending MST=20 =3D FAIL) until the DNU would have been received from the So." So I supposed the authors of these drafts were aware of this note, and consequently the mandatory sequence for a hitless decrease of bandwidth: remove member at source node first, wait for confirmation, remove member at sink node (and network path). Maybe the authors were not aware of a possible solution presented at the recent SG 15 meeting. > With regard to the solution space for the problem: > - If the solution lies entirely within LCAS then it is out of scope for > CCAMP. The LSP will simply be torn down when the LCAS synchronization h= as > been done. [hvh] indeed the solution is within the LCAS protocol, but has an impact on the control plane: it removes the mandatory sequence for hitless decrease. > - If the problem is to be solved within GMPLS, then we have a suitable > mechanism already. [hvh] if you mean that GMPLS can take care of or guarantee the above mentioned mandatory sequence, then indeed there is no problem. However IMHO it may be a complex solution. > Thus, it turns out that it is important to scope problems not just > functionally, but according to which components are intended to resolve > them. [hvh] I hope I did above. > Very obviously, the industry does not need or want two solutions to the > same problem. [hvh] the solution proposed in the last plenary meeting of ITU-T SG15 delayed document D.286 did not get concensus in the Q11 meeting. When presented in the Q14 meeting it was agreed that this proposal would simplify the control of LCAS LSPs. If this solution is not accepted soon, more LCAS implementations will be cast in silicon (currently the majority is in SW) and t will be very hard to get it accepted at a later date. When CCAMP sees the need for adding this enhancement that removes the mandatory remove sequence, shouldn't a liaison be sent to SG15/Q11 to express their concern? Cheers, Huub. > Adrian > ----- Original Message -----=20 > From: "Huub van Helvoort" > To: "ccamp" > Sent: Sunday, July 31, 2005 3:21 PM > Subject: Re: LCAS and GMPLS >=20 >>Hello Wataru, >> >>You wrote: >> >>>I forward a nice comment from Mr. Huub van Helvoort. >> >>Thank you for forwarding. >>(I hope I can send this message the list myself). >> >>>His comments indicates we need liason from ITU-T SG-15 regarding to >>>this issue. >> >>This is a good proposal, it will indicate to ITU-T SG15/Q11 >>that IETF/CCAMP supports this enhancement. >> >>Kind regards, Huub. >> >>--- from message 27-7-2005 --- >> >> >>>>One point for the problem statement could be that in order to >>>>guarantee a hitless removal of one of the members in a VCG >>>>(decrease of bandwidth) there is a mandatory sequence: >>>>First remove member at ingress node, wait for confirm and >>>>only then remove path and member at egress node. >>>> >>>>However, a solution was presented at the last ITU-T SG15/q11 >>>>meeting that removes this requirement. >>>> >>>>Cheers, Huub. --=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=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 http://members.chello.nl/hhelvoort/ =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=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 Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Tue Aug 02 05:45:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztKq-0002zD-2i for ccamp-archive@megatron.ietf.org; Tue, 02 Aug 2005 05:45:20 -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 FAA03207 for ; Tue, 2 Aug 2005 05:45:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztrC-0005X4-Bv for ccamp-archive@ietf.org; Tue, 02 Aug 2005 06:18:52 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DztFa-0002Iv-9K for ccamp-data@psg.com; Tue, 02 Aug 2005 09:39:54 +0000 Received: from [86.255.2.7] (helo=pollux.ietf63.ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DztFY-0002IZ-4t for ccamp@ops.ietf.org; Tue, 02 Aug 2005 09:39:52 +0000 Received: from Puppy (open-25-118.ietf63.ietf.org [86.255.25.118]) by pollux.ietf63.ietf.org (Postfix) with SMTP id EDC0D48; Tue, 2 Aug 2005 02:39:50 -0700 (PDT) Message-ID: <013b01c59746$7d268af0$7810ff56@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Huub van Helvoort" , "ccamp" References: <42ECDE6F.5000903@chello.nl> <00b001c596f6$07f38c10$7810ff56@Puppy> <42EF3395.5@chello.nl> Subject: Re: LCAS and GMPLS Date: Tue, 2 Aug 2005 10:42:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA03207 Hi Huub, > > I think the original proposal is that SG15 may want to send CCAMP a > > liaison about this work. That would certainly be fine. > > [hvh] I tried but did not get enough support That is a shame because it is hard for CCAMP to work on this without a clear statement of the requirements and we look to the ITU-T to supply th= e details of LCAS. If we can identify more precisely what it is we need to know, then we can liaise a request for information. > > I don't think that CCAMP can send a liaison back to support the work > > without having seen it first. > > [hvh] both draft-imajuku-ccamp-gmpls-vcat-lagr-req > and draft-bernstein-LCAS-GMPLS > refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this > recommendation contains the following note: > "NOTE =96 If a permanent removal of an active member is initiated at th= e > Sk, this will result in a hit to the reconstructed data. The duration o= f > this hit will be from the time the member is removed (starts sending MS= T > =3D FAIL) until the DNU would have been received from the So." > > So I supposed the authors of these drafts were aware > of this note, and consequently the mandatory sequence > for a hitless decrease of bandwidth: remove member at > source node first, wait for confirmation, remove member > at sink node (and network path). > Maybe the authors were not aware of a possible solution > presented at the recent SG 15 meeting. I can't speak for the authors. Speaking for myself, I was not aware of the work at the SG15 meeting. I am certain that the majority of CCAMP was not aware. > > With regard to the solution space for the problem: > > - If the solution lies entirely within LCAS then it is out of scope for > > CCAMP. The LSP will simply be torn down when the LCAS synchronization has > > been done. > > [hvh] indeed the solution is within the LCAS protocol, but has an > impact on the control plane: it removes the mandatory sequence > for hitless decrease. Yes. it removes a requirement. It doesn't remove any protocol elements because they already exist. It changes the solutions doc, because there is no need to describe a non-requirement. > > - If the problem is to be solved within GMPLS, then we have a suitabl= e > > mechanism already. > > [hvh] if you mean that GMPLS can take care of or guarantee the > above mentioned mandatory sequence, then indeed there is > no problem. > However IMHO it may be a complex solution. Well, if we establish that this *is* a requirement we have to solve it. That will start a discussion of how simple/practical the solution is. IM(NS)HO this is easy work using existing GMPLS tools. > > Thus, it turns out that it is important to scope problems not just > > functionally, but according to which components are intended to resolve > > them. > > [hvh] I hope I did above. Thanks, yes. But in order to understand the requirements here we must understand what we are tyring to support. Do we need to support existing LCAS implementations, or can we assume that the SG15 proposals will come to agreement/standardisation and will be implemented ubiquitously? See below... > > Very obviously, the industry does not need or want two solutions to the > > same problem. > > [hvh] the solution proposed in the last plenary meeting of ITU-T > SG15 delayed document D.286 did not get concensus in the Q11 > meeting. When presented in the Q14 meeting it was agreed that > this proposal would simplify the control of LCAS LSPs. > > If this solution is not accepted soon, more LCAS implementations > will be cast in silicon (currently the majority is in SW) and > t will be very hard to get it accepted at a later date. > > When CCAMP sees the need for adding this enhancement that > removes the mandatory remove sequence, shouldn't a liaison > be sent to SG15/Q11 to express their concern? I think CCAMP will understand the need for hitless add/remove. If CCAMP sees/believes that LCAS does not support this function, then CCAMP will attempt to deliver this function. If CCAMP sees/believes that LCAS already delivers the function, this will not be something that CCAMP discusses further. However, it is not for CCAMP to comment on the function contained within LCAS. LCAS is not our protocol to comment on. Thanks, Adrian > > Cheers, Huub. > > > Adrian > > ----- Original Message -----=20 > > From: "Huub van Helvoort" > > To: "ccamp" > > Sent: Sunday, July 31, 2005 3:21 PM > > Subject: Re: LCAS and GMPLS > > > >>Hello Wataru, > >> > >>You wrote: > >> > >>>I forward a nice comment from Mr. Huub van Helvoort. > >> > >>Thank you for forwarding. > >>(I hope I can send this message the list myself). > >> > >>>His comments indicates we need liason from ITU-T SG-15 regarding to > >>>this issue. > >> > >>This is a good proposal, it will indicate to ITU-T SG15/Q11 > >>that IETF/CCAMP supports this enhancement. > >> > >>Kind regards, Huub. > >> > >>--- from message 27-7-2005 --- > >> > >> > >>>>One point for the problem statement could be that in order to > >>>>guarantee a hitless removal of one of the members in a VCG > >>>>(decrease of bandwidth) there is a mandatory sequence: > >>>>First remove member at ingress node, wait for confirm and > >>>>only then remove path and member at egress node. > >>>> > >>>>However, a solution was presented at the last ITU-T SG15/q11 > >>>>meeting that removes this requirement. > >>>> > >>>>Cheers, Huub. > > --=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=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 > http://members.chello.nl/hhelvoort/ > =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=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 > Always remember that you are unique...just like everyone else... > > From owner-ccamp@ops.ietf.org Tue Aug 02 06:56:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuRp-0001lI-8n for ccamp-archive@megatron.ietf.org; Tue, 02 Aug 2005 06:56: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 GAA09451 for ; Tue, 2 Aug 2005 06:56:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzuyD-0000z8-U5 for ccamp-archive@ietf.org; Tue, 02 Aug 2005 07:30:10 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzuJF-0007ib-Pi for ccamp-data@psg.com; Tue, 02 Aug 2005 10:47:45 +0000 Received: from [217.6.95.238] (helo=tcmail31.telekom.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzuJC-0007iE-Or for ccamp@ops.ietf.org; Tue, 02 Aug 2005 10:47:43 +0000 Received: from g8pbu.blf01.telekom.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 2 Aug 2005 12:47:41 +0200 Received: by G8PBU.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Aug 2005 12:46:19 +0200 Message-Id: From: Michael.Dueser@t-systems.com To: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: AW: LCAS and GMPLS Date: Tue, 2 Aug 2005 12:46:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: 1.4 (+) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: quoted-printable Hi,=20 Clearly CCAMP is not supposed to do TU-T's job... I have a feeling we = need more clarification of the actual requrirements, and then assess = which functionalities are supported by SONET/SDH or GMPLS already to = identify the missing bits. It may then turn out that we actually most = of the mechanisms in place, but need a BCP to clarify how to use them = properly. My suggestion to take this forward is that we briefly discuss = the two drafts tomorrow, then refine the requirements and the solution = drafts until the next IETF meeting. Again, there is definitive interest = by operators to get the SDH and GMPLS interworking as clear as = possible. Regards, Michael=20 -----Urspr=FCngliche Nachricht----- Von: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] Im = Auftrag von Adrian Farrel Gesendet: Dienstag, 2. August 2005 11:42 An: Huub van Helvoort; ccamp Betreff: Re: LCAS and GMPLS Hi Huub, > > I think the original proposal is that SG15 may want to send CCAMP a = > > liaison about this work. That would certainly be fine. > > [hvh] I tried but did not get enough support That is a shame because it is hard for CCAMP to work on this without a = clear statement of the requirements and we look to the ITU-T to supply = the details of LCAS. If we can identify more precisely what it is we need to know, then we = can liaise a request for information. > > I don't think that CCAMP can send a liaison back to support the = work=20 > > without having seen it first. > > [hvh] both draft-imajuku-ccamp-gmpls-vcat-lagr-req > and draft-bernstein-LCAS-GMPLS > refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this > recommendation contains the following note: > "NOTE - If a permanent removal of an active member is initiated at = the=20 > Sk, this will result in a hit to the reconstructed data. The duration = > of this hit will be from the time the member is removed (starts=20 > sending MST =3D FAIL) until the DNU would have been received from the = > So." > > So I supposed the authors of these drafts were aware > of this note, and consequently the mandatory sequence > for a hitless decrease of bandwidth: remove member at > source node first, wait for confirmation, remove member > at sink node (and network path). > Maybe the authors were not aware of a possible solution > presented at the recent SG 15 meeting. I can't speak for the authors. Speaking for myself, I was not aware of the work at the SG15 meeting. I = am certain that the majority of CCAMP was not aware. > > With regard to the solution space for the problem: > > - If the solution lies entirely within LCAS then it is out of scope for > > CCAMP. The LSP will simply be torn down when the LCAS=20 > > synchronization has > > been done. > > [hvh] indeed the solution is within the LCAS protocol, but has an > impact on the control plane: it removes the mandatory sequence > for hitless decrease. Yes. it removes a requirement. It doesn't remove any protocol elements because they already exist. It = changes the solutions doc, because there is no need to describe a = non-requirement. > > - If the problem is to be solved within GMPLS, then we have a=20 > > suitable mechanism already. > > [hvh] if you mean that GMPLS can take care of or guarantee the > above mentioned mandatory sequence, then indeed there is > no problem. > However IMHO it may be a complex solution. Well, if we establish that this *is* a requirement we have to solve it. = That will start a discussion of how simple/practical the solution is. = IM(NS)HO this is easy work using existing GMPLS tools. > > Thus, it turns out that it is important to scope problems not just=20 > > functionally, but according to which components are intended to resolve > > them. > > [hvh] I hope I did above. Thanks, yes. But in order to understand the requirements here we must understand = what we are tyring to support. Do we need to support existing LCAS = implementations, or can we assume that the SG15 proposals will come to = agreement/standardisation and will be implemented ubiquitously? See below... > > Very obviously, the industry does not need or want two solutions to the > > same problem. > > [hvh] the solution proposed in the last plenary meeting of ITU-T > SG15 delayed document D.286 did not get concensus in the Q11 > meeting. When presented in the Q14 meeting it was agreed that > this proposal would simplify the control of LCAS LSPs. > > If this solution is not accepted soon, more LCAS = implementations > will be cast in silicon (currently the majority is in SW) and > t will be very hard to get it accepted at a later date. > > When CCAMP sees the need for adding this enhancement that > removes the mandatory remove sequence, shouldn't a liaison > be sent to SG15/Q11 to express their concern? I think CCAMP will understand the need for hitless add/remove. If CCAMP = sees/believes that LCAS does not support this function, then CCAMP will = attempt to deliver this function. If CCAMP sees/believes that LCAS = already delivers the function, this will not be something that CCAMP = discusses further. However, it is not for CCAMP to comment on the function contained = within LCAS. LCAS is not our protocol to comment on. Thanks, Adrian > > Cheers, Huub. > > > Adrian > > ----- Original Message ----- > > From: "Huub van Helvoort" > > To: "ccamp" > > Sent: Sunday, July 31, 2005 3:21 PM > > Subject: Re: LCAS and GMPLS > > > >>Hello Wataru, > >> > >>You wrote: > >> > >>>I forward a nice comment from Mr. Huub van Helvoort. > >> > >>Thank you for forwarding. > >>(I hope I can send this message the list myself). > >> > >>>His comments indicates we need liason from ITU-T SG-15 regarding = to=20 > >>>this issue. > >> > >>This is a good proposal, it will indicate to ITU-T SG15/Q11 that=20 > >>IETF/CCAMP supports this enhancement. > >> > >>Kind regards, Huub. > >> > >>--- from message 27-7-2005 --- > >> > >> > >>>>One point for the problem statement could be that in order to=20 > >>>>guarantee a hitless removal of one of the members in a VCG=20 > >>>>(decrease of bandwidth) there is a mandatory sequence: First=20 > >>>>remove member at ingress node, wait for confirm and only then=20 > >>>>remove path and member at egress node. > >>>> > >>>>However, a solution was presented at the last ITU-T SG15/q11=20 > >>>>meeting that removes this requirement. > >>>> > >>>>Cheers, Huub. > > -- > = =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=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 > http://members.chello.nl/hhelvoort/ > = =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=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 > Always remember that you are unique...just like everyone else... > > From owner-ccamp@ops.ietf.org Tue Aug 02 08:12:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzvcy-00023a-28 for ccamp-archive@megatron.ietf.org; Tue, 02 Aug 2005 08:12:12 -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 IAA14404 for ; Tue, 2 Aug 2005 08:12:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzw9L-0004fv-9D for ccamp-archive@ietf.org; Tue, 02 Aug 2005 08:45:46 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzvXK-000E4X-P0 for ccamp-data@psg.com; Tue, 02 Aug 2005 12:06:22 +0000 Received: from [86.255.2.7] (helo=pollux.ietf63.ietf.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzvXI-000E49-7s for ccamp@ops.ietf.org; Tue, 02 Aug 2005 12:06:20 +0000 Received: from Puppy (open-25-118.ietf63.ietf.org [86.255.25.118]) by pollux.ietf63.ietf.org (Postfix) with SMTP id 3883237; Tue, 2 Aug 2005 05:06:19 -0700 (PDT) Message-ID: <01ab01c5975a$f386dd80$7810ff56@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , References: Subject: Re: LCAS and GMPLS Date: Tue, 2 Aug 2005 13:08:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 1.1 (+) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA14404 Thanks Michael, That fits with my assessment. Its a plan. Adrian ----- Original Message -----=20 From: To: ; Sent: Tuesday, August 02, 2005 11:46 AM Subject: AW: LCAS and GMPLS Hi, Clearly CCAMP is not supposed to do TU-T's job... I have a feeling we nee= d more clarification of the actual requrirements, and then assess which functionalities are supported by SONET/SDH or GMPLS already to identify the missing bits. It may then turn out that we actually most of the mechanisms in place, but need a BCP to clarify how to use them properly. My suggestion to take this forward is that we briefly discuss the two drafts tomorrow, then refine the requirements and the solution drafts until the next IETF meeting. Again, there is definitive interest by operators to get the SDH and GMPLS interworking as clear as possible. Regards, Michael -----Urspr=FCngliche Nachricht----- Von: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] Im Auftra= g von Adrian Farrel Gesendet: Dienstag, 2. August 2005 11:42 An: Huub van Helvoort; ccamp Betreff: Re: LCAS and GMPLS Hi Huub, > > I think the original proposal is that SG15 may want to send CCAMP a > > liaison about this work. That would certainly be fine. > > [hvh] I tried but did not get enough support That is a shame because it is hard for CCAMP to work on this without a clear statement of the requirements and we look to the ITU-T to supply th= e details of LCAS. If we can identify more precisely what it is we need to know, then we can liaise a request for information. > > I don't think that CCAMP can send a liaison back to support the work > > without having seen it first. > > [hvh] both draft-imajuku-ccamp-gmpls-vcat-lagr-req > and draft-bernstein-LCAS-GMPLS > refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this > recommendation contains the following note: > "NOTE - If a permanent removal of an active member is initiated at the > Sk, this will result in a hit to the reconstructed data. The duration > of this hit will be from the time the member is removed (starts > sending MST =3D FAIL) until the DNU would have been received from the > So." > > So I supposed the authors of these drafts were aware > of this note, and consequently the mandatory sequence > for a hitless decrease of bandwidth: remove member at > source node first, wait for confirmation, remove member > at sink node (and network path). > Maybe the authors were not aware of a possible solution > presented at the recent SG 15 meeting. I can't speak for the authors. Speaking for myself, I was not aware of the work at the SG15 meeting. I a= m certain that the majority of CCAMP was not aware. > > With regard to the solution space for the problem: > > - If the solution lies entirely within LCAS then it is out of scope for > > CCAMP. The LSP will simply be torn down when the LCAS > > synchronization has > > been done. > > [hvh] indeed the solution is within the LCAS protocol, but has an > impact on the control plane: it removes the mandatory sequence > for hitless decrease. Yes. it removes a requirement. It doesn't remove any protocol elements because they already exist. It changes the solutions doc, because there is no need to describe a non-requirement. > > - If the problem is to be solved within GMPLS, then we have a > > suitable mechanism already. > > [hvh] if you mean that GMPLS can take care of or guarantee the > above mentioned mandatory sequence, then indeed there is > no problem. > However IMHO it may be a complex solution. Well, if we establish that this *is* a requirement we have to solve it. That will start a discussion of how simple/practical the solution is. IM(NS)HO this is easy work using existing GMPLS tools. > > Thus, it turns out that it is important to scope problems not just > > functionally, but according to which components are intended to resolve > > them. > > [hvh] I hope I did above. Thanks, yes. But in order to understand the requirements here we must understand what we are tyring to support. Do we need to support existing LCAS implementations, or can we assume that the SG15 proposals will come to agreement/standardisation and will be implemented ubiquitously? See below... > > Very obviously, the industry does not need or want two solutions to the > > same problem. > > [hvh] the solution proposed in the last plenary meeting of ITU-T > SG15 delayed document D.286 did not get concensus in the Q11 > meeting. When presented in the Q14 meeting it was agreed that > this proposal would simplify the control of LCAS LSPs. > > If this solution is not accepted soon, more LCAS implementations > will be cast in silicon (currently the majority is in SW) and > t will be very hard to get it accepted at a later date. > > When CCAMP sees the need for adding this enhancement that > removes the mandatory remove sequence, shouldn't a liaison > be sent to SG15/Q11 to express their concern? I think CCAMP will understand the need for hitless add/remove. If CCAMP sees/believes that LCAS does not support this function, then CCAMP will attempt to deliver this function. If CCAMP sees/believes that LCAS alread= y delivers the function, this will not be something that CCAMP discusses further. However, it is not for CCAMP to comment on the function contained within LCAS. LCAS is not our protocol to comment on. Thanks, Adrian > > Cheers, Huub. > > > Adrian > > ----- Original Message ----- > > From: "Huub van Helvoort" > > To: "ccamp" > > Sent: Sunday, July 31, 2005 3:21 PM > > Subject: Re: LCAS and GMPLS > > > >>Hello Wataru, > >> > >>You wrote: > >> > >>>I forward a nice comment from Mr. Huub van Helvoort. > >> > >>Thank you for forwarding. > >>(I hope I can send this message the list myself). > >> > >>>His comments indicates we need liason from ITU-T SG-15 regarding to > >>>this issue. > >> > >>This is a good proposal, it will indicate to ITU-T SG15/Q11 that > >>IETF/CCAMP supports this enhancement. > >> > >>Kind regards, Huub. > >> > >>--- from message 27-7-2005 --- > >> > >> > >>>>One point for the problem statement could be that in order to > >>>>guarantee a hitless removal of one of the members in a VCG > >>>>(decrease of bandwidth) there is a mandatory sequence: First > >>>>remove member at ingress node, wait for confirm and only then > >>>>remove path and member at egress node. > >>>> > >>>>However, a solution was presented at the last ITU-T SG15/q11 > >>>>meeting that removes this requirement. > >>>> > >>>>Cheers, Huub. > > -- > =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=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 > http://members.chello.nl/hhelvoort/ > =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=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 > Always remember that you are unique...just like everyone else... > > From owner-ccamp@ops.ietf.org Wed Aug 03 13:00:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Mbw-0001lT-Cr for ccamp-archive@megatron.ietf.org; Wed, 03 Aug 2005 13:00:56 -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 NAA01060 for ; Wed, 3 Aug 2005 13:00:53 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0N8W-00029V-Vu for ccamp-archive@ietf.org; Wed, 03 Aug 2005 13:34:45 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0MS7-00044m-FG for ccamp-data@psg.com; Wed, 03 Aug 2005 16:50:47 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0MS5-000437-Gd for ccamp@ops.ietf.org; Wed, 03 Aug 2005 16:50:45 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j73GodQ07251 for ; Wed, 3 Aug 2005 12:50:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: draft-ashwood-ccacmp-gmpls-constraints Date: Wed, 3 Aug 2005 12:50:37 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA403615077@zrtphxm2> Thread-Topic: draft-ashwood-ccacmp-gmpls-constraints Thread-Index: AcWR8KZ24x4uqrZrQTmtl148bcRRTwGVHAgg From: "Don Fedyk" To: 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: 9466e0365fc95844abaf7c3f15a05c7d Hi Since we did not get through all the CCAMP agenda today, I would still like to get feedback on the following draft. Link Viability Constraints Don Fedyk (5 mins) http://home.clara.net/olddog/63/draft-ashwood-ccamp-gmpls-constraint-req ts-00.ppt http://www.ietf.org/internet-drafts/draft-ashwood-ccamp-gmpls-constraint -reqts-00.txt Note the draft is about interfacing a dynamic optical system to a GMPLS control plane but puts forward the argument we can avoid for now the standardization of the detailed optical constraints. I would like to see this in Scope for the IETF (CCAMP) even though I realize the detailed (or complex) optical constraints may be years from being in scope and standardization. The current draft is a requirements draft with some preliminary ideas on how this can be achieved. I would like to solicit others who are interested in working this problem. Please send feedback, I'm around till Friday if anyone would like to discuss in person, Thanks, Don From owner-ccamp@ops.ietf.org Thu Aug 04 05:42:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cEn-0005Pe-4y for ccamp-archive@megatron.ietf.org; Thu, 04 Aug 2005 05:42:05 -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 FAA16927 for ; Thu, 4 Aug 2005 05:42:02 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0clZ-0000M2-V1 for ccamp-archive@ietf.org; Thu, 04 Aug 2005 06:16:03 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0c5C-0003YC-5i for ccamp-data@psg.com; Thu, 04 Aug 2005 09:32:10 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0c5A-0003Xr-AU for ccamp@ops.ietf.org; Thu, 04 Aug 2005 09:32:08 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id 1C23698B2; Thu, 4 Aug 2005 05:32:07 -0400 (EDT) Received: from 86.255.26.2 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Thu, 4 Aug 2005 05:32:07 -0400 (EDT) Message-ID: <4995.86.255.26.2.1123147927.squirrel@webmail.movaz.com> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA403615077@zrtphxm2> References: <34B3EAA5B3066A42914D28C5ECF5FEA403615077@zrtphxm2> Date: Thu, 4 Aug 2005 05:32:07 -0400 (EDT) Subject: Re: draft-ashwood-ccacmp-gmpls-constraints From: ibryskin@movaz.com To: "Don Fedyk" Cc: ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal 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,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA16927 Hi, I believe this is a very useful draft. The described blocking problem (a limited ability of a node to cross-connect resources on input and output links wrt a particular LSP) exists not only in the Virtual Node scenario: there could be =93real=94 network elements experiencing the problem (perh= aps, because of the hardware limitations). Hence there is a need for a routing controller to be capable to advertise a map of acceptable (or unacceptable) input-output link combinations, and for a path computer to account for such a constraint (which is not trivial). I also would suggest the authors to consider the Virtual Link mode, that is, representing the domain to the outside world as a bunch of PEs interconnected by abstract (virtual) links. This approach may require mor= e advertisements compared to the Virtual Node mode; however, it does reliev= e external path computers from handling the interface maps, plus it gives the idea about the cost and attributes of feasible paths across the domain. Igor > > Since we did not get through all the CCAMP agenda today, I would still > like to get feedback on the following draft. > > Link Viability Constraints Don Fedyk (5 mins) > http://home.clara.net/olddog/63/draft-ashwood-ccamp-gmpls-constraint-re= q > ts-00.ppt > http://www.ietf.org/internet-drafts/draft-ashwood-ccamp-gmpls-constrain= t > -reqts-00.txt > > Note the draft is about interfacing a dynamic optical system to a GMPLS > control plane but puts forward the argument we can avoid for now the > standardization of the detailed optical constraints. I would like to > see this in Scope for the IETF (CCAMP) even though I realize the > detailed (or complex) optical constraints may be years from being in > scope and standardization. The current draft is a requirements draft > with some preliminary ideas on how this can be achieved. I would like t= o > solicit others who are interested in working this problem. > > Please send feedback, I'm around till Friday if anyone would like to > discuss in person, > Thanks, > Don > > > > > > From owner-ccamp@ops.ietf.org Thu Aug 04 06:01:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cXW-0005ox-6x for ccamp-archive@megatron.ietf.org; Thu, 04 Aug 2005 06:01: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 GAA18563 for ; Thu, 4 Aug 2005 06:01:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0d4K-0001OK-Sm for ccamp-archive@ietf.org; Thu, 04 Aug 2005 06:35:24 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0cOE-000589-Ni for ccamp-data@psg.com; Thu, 04 Aug 2005 09:51:50 +0000 Received: from [63.118.39.27] (helo=mdmxm02.ciena.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0cOB-00056w-PG for ccamp@ops.ietf.org; Thu, 04 Aug 2005 09:51:47 +0000 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: draft-ashwood-ccacmp-gmpls-constraints Date: Thu, 4 Aug 2005 05:51:41 -0400 Message-ID: <0901D1988E815341A0103206A834DA07555CB6@mdmxm02.ciena.com> Thread-Topic: draft-ashwood-ccacmp-gmpls-constraints Thread-Index: AcWY2A9cRcxBNRNWRBqnPuo6V05ZKAAAMbuw From: "Ong, Lyndon" To: , "Don Fedyk" Cc: 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Hi Igor, I was wondering also about using a virtual link model, that seems to=20 be able to carry similar or more information, with maybe a bit more overhead. Cheers, Lyndon=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ibryskin@movaz.com Sent: Thursday, August 04, 2005 2:32 AM To: Don Fedyk Cc: ccamp@ops.ietf.org Subject: Re: draft-ashwood-ccacmp-gmpls-constraints Hi, I believe this is a very useful draft. The described blocking problem (a limited ability of a node to cross-connect resources on input and output links wrt a particular LSP) exists not only in the Virtual Node scenario: there could be "real" network elements experiencing the problem (perhaps, because of the hardware limitations). Hence there is a need for a routing controller to be capable to advertise a map of acceptable (or unacceptable) input-output link combinations, and for a path computer to account for such a constraint (which is not trivial). I also would suggest the authors to consider the Virtual Link mode, that is, representing the domain to the outside world as a bunch of PEs interconnected by abstract (virtual) links. This approach may require more advertisements compared to the Virtual Node mode; however, it does relieve external path computers from handling the interface maps, plus it gives the idea about the cost and attributes of feasible paths across the domain. Igor > > Since we did not get through all the CCAMP agenda today, I would still > like to get feedback on the following draft. > > Link Viability Constraints Don Fedyk (5 mins)=20 > http://home.clara.net/olddog/63/draft-ashwood-ccamp-gmpls-constraint-r > eq > ts-00.ppt > http://www.ietf.org/internet-drafts/draft-ashwood-ccamp-gmpls-constrai > nt > -reqts-00.txt > > Note the draft is about interfacing a dynamic optical system to a=20 > GMPLS control plane but puts forward the argument we can avoid for now > the standardization of the detailed optical constraints. I would like > to see this in Scope for the IETF (CCAMP) even though I realize the=20 > detailed (or complex) optical constraints may be years from being in=20 > scope and standardization. The current draft is a requirements draft=20 > with some preliminary ideas on how this can be achieved. I would like=20 > to solicit others who are interested in working this problem. > > Please send feedback, I'm around till Friday if anyone would like to=20 > discuss in person, Thanks, Don > > > > > > From owner-ccamp@ops.ietf.org Thu Aug 04 06:07:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0cdY-0007Zz-Ai for ccamp-archive@megatron.ietf.org; Thu, 04 Aug 2005 06:07: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 GAA18896 for ; Thu, 4 Aug 2005 06:07:37 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dAO-0001dh-3k for ccamp-archive@ietf.org; Thu, 04 Aug 2005 06:41:38 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0cZz-0006S9-4V for ccamp-data@psg.com; Thu, 04 Aug 2005 10:03:59 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0cZx-0006Rk-6D for ccamp@ops.ietf.org; Thu, 04 Aug 2005 10:03:57 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j74A3ql29889; Thu, 4 Aug 2005 06:03:52 -0400 (EDT) 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: draft-ashwood-ccamp-gmpls-constraints Date: Thu, 4 Aug 2005 06:03:50 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4036157B7@zrtphxm2> Thread-Topic: draft-ashwood-ccamp-gmpls-constraints Thread-Index: AcWY127F1UPE2b1sQ0Syyj3IohxigQAA6fdw From: "Don Fedyk" To: Cc: 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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Igor Thanks for the feedback I would like to work with you to capture the Virtual Link Mode into the draft.=20 Regards, Don=20 > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com]=20 > Sent: Thursday, August 04, 2005 5:32 AM >=20 > Hi, >=20 > I believe this is a very useful draft. The described blocking=20 > problem (a limited ability of a node to cross-connect=20 > resources on input and output links wrt a particular LSP)=20 > exists not only in the Virtual Node scenario: there could be=20 > "real" network elements experiencing the problem (perhaps,=20 > because of the hardware limitations). Hence there is a need=20 > for a routing controller to be capable to advertise a map of=20 > acceptable (or > unacceptable) input-output link combinations, and for a path=20 > computer to account for such a constraint (which is not trivial). >=20 > I also would suggest the authors to consider the Virtual Link=20 > mode, that is, representing the domain to the outside world=20 > as a bunch of PEs interconnected by abstract (virtual) links.=20 > This approach may require more advertisements compared to the=20 > Virtual Node mode; however, it does relieve external path=20 > computers from handling the interface maps, plus it gives the=20 > idea about the cost and attributes of feasible paths across=20 > the domain. >=20 > Igor From owner-ccamp@ops.ietf.org Thu Aug 04 06:36:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0d5A-0002zU-BF for ccamp-archive@megatron.ietf.org; Thu, 04 Aug 2005 06:36:12 -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 GAA24340 for ; Thu, 4 Aug 2005 06:36:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0dc0-0003Nm-H3 for ccamp-archive@ietf.org; Thu, 04 Aug 2005 07:10:10 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0cyt-0008V6-Hh for ccamp-data@psg.com; Thu, 04 Aug 2005 10:29:43 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0cys-0008Uo-1T for ccamp@ops.ietf.org; Thu, 04 Aug 2005 10:29:42 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id 55DC1B085; Thu, 4 Aug 2005 06:29:41 -0400 (EDT) Received: from 86.255.26.2 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Thu, 4 Aug 2005 06:29:41 -0400 (EDT) Message-ID: <1254.86.255.26.2.1123151381.squirrel@webmail.movaz.com> In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA4036157B7@zrtphxm2> References: <34B3EAA5B3066A42914D28C5ECF5FEA4036157B7@zrtphxm2> Date: Thu, 4 Aug 2005 06:29:41 -0400 (EDT) Subject: RE: draft-ashwood-ccamp-gmpls-constraints From: ibryskin@movaz.com To: "Don Fedyk" Cc: ibryskin@movaz.com, ccamp@ops.ietf.org 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 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,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 8bit Sure. We can meet today after lunch, otherwise, by email. Igor > Igor > > Thanks for the feedback I would like to work with you to capture the > Virtual Link Mode into the draft. > > Regards, > Don > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Thursday, August 04, 2005 5:32 AM >> >> Hi, >> >> I believe this is a very useful draft. The described blocking >> problem (a limited ability of a node to cross-connect >> resources on input and output links wrt a particular LSP) >> exists not only in the Virtual Node scenario: there could be >> "real" network elements experiencing the problem (perhaps, >> because of the hardware limitations). Hence there is a need >> for a routing controller to be capable to advertise a map of >> acceptable (or >> unacceptable) input-output link combinations, and for a path >> computer to account for such a constraint (which is not trivial). >> >> I also would suggest the authors to consider the Virtual Link >> mode, that is, representing the domain to the outside world >> as a bunch of PEs interconnected by abstract (virtual) links. >> This approach may require more advertisements compared to the >> Virtual Node mode; however, it does relieve external path >> computers from handling the interface maps, plus it gives the >> idea about the cost and attributes of feasible paths across >> the domain. >> >> Igor > > From owner-ccamp@ops.ietf.org Mon Aug 08 06:39:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2524-0007C4-Eb for ccamp-archive@megatron.ietf.org; Mon, 08 Aug 2005 06:39:00 -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 GAA12262 for ; Mon, 8 Aug 2005 06:38:57 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E25Zl-0003M0-1a for ccamp-archive@ietf.org; Mon, 08 Aug 2005 07:13:49 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E24ti-000P4l-5O for ccamp-data@psg.com; Mon, 08 Aug 2005 10:30:22 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E24tg-000P4R-Gk for ccamp@ops.ietf.org; Mon, 08 Aug 2005 10:30:20 +0000 Received: from du-069-0008.access.clara.net ([217.158.132.8] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E24te-000Dg8-IH; Mon, 08 Aug 2005 11:30:19 +0100 Message-ID: <00dd01c59c04$8ad14560$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Alan Davey" Subject: GMPLS Addressing draft Date: Fri, 5 Aug 2005 15:30:49 +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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Hi, In CCAMP in Paris Dimitri raised a specific question about section 9.3 of draft-ietf-ccamp-gmpls-addressing-01.txt. As I understood this question, Dimitri wants only to include material that is relevant to current testing or operational experience. He asks, therefore, whether anyone has deployed or tested scenarios where the source is IPv4 and the destination is IPv6 or vice versa. My view is that we should avoid completeness arguments and limit ourselves to implementations and likely deployments. So if anyone has direct experience of this scenario we will keep the text - otherwise section 9.3 will be deleted. Thanks, Adrian From owner-ccamp@ops.ietf.org Mon Aug 08 15:54:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Di3-0004uq-Nw for ccamp-archive@megatron.ietf.org; Mon, 08 Aug 2005 15:54: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 PAA14331 for ; Mon, 8 Aug 2005 15:54:53 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2EFg-0002PF-Jh for ccamp-archive@ietf.org; Mon, 08 Aug 2005 16:29:49 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2DXw-000LH5-V0 for ccamp-data@psg.com; Mon, 08 Aug 2005 19:44:28 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2DXu-000LGr-QS for ccamp@ops.ietf.org; Mon, 08 Aug 2005 19:44:27 +0000 Received: from ib (unknown [172.16.24.122]) by jera.movaz.com (Postfix) with SMTP id ABBAE164E; Mon, 8 Aug 2005 15:44:24 -0400 (EDT) Message-ID: <00d701c59c51$94875bb0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Don Fedyk" Cc: References: <34B3EAA5B3066A42914D28C5ECF5FEA4036157B7@zrtphxm2> Subject: Re: draft-ashwood-ccamp-gmpls-constraints Date: Mon, 8 Aug 2005 15:44:24 -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 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: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Don, You can find a detailed description of the Virtual Link mode in the Layer 1 VPN WG documents. In brief, in this mode a domain is represented to the outside routing domain not as a single node (as in case of the Virtual Node mode), but as a set of PEs interconnected by virtual (more correctly, abstract) links. The Virtual Link mode has some serious advantages compared to the Virtual Node mode. Here is some of them: 1. In the Virtual Node mode there is some synchronization required between PEs: in order for the outside routing domain to perceive the hidden domain as a single node all PEs need either to generate exactly the same advertisings ( specifically, they need to agree on the Virtual Node Router ID, learn about every other PE and the links interconnecting the PE with the outside routing domain, etc.) or identify the outside routing domain segments interconnected exclusively by the means of the hidden domain and elect for each of them a single PE that would generate the Virtual Node advertisings. Neither of these approaches is trivial to implement. On the contrary, PEs in the Virtual Link mode advertise information into the outside routing domain completely independently. 2. In order to advertise a matrix of acceptable input-output link combinations a PE must periodically solve ALL PEs -TO-ALL PEs constraint based path computation problem. It is far more difficult problem to solve compared to a single PE -TO-ALL PEs constraint based path computation (which is as complex as a single source - single destination path computation) required in the Virtual Link mode; 3. The constraints used during the computation of the input-output link matrix is not advertised and not available for the external path computer, which diminishes the value of the matrix advertising. In other words, even when the external path computer uses the matrix as a constraint, there is still a significant blocking probability of the LSP setup using the computed path because there is no guarantee that the sets of the "external" and "internal" path computation constraints match. There is no such problem in the Virtual Link mode where the internal path computation constraints could be advertised as abstract TE link attributes and hence could be considered explicitly by the external path computer 4. The matrix of input-output link combinations does not provide information about the cost of a particular input-output binding across the hidden domain. This means that suboptimal path selection is quite possible. On the contrary, each abstract TE link advertising has a TE metric sub-TLV; 5. It is not trivial to use the matrix of input-output link combinations as a constraint, and some modifications of the external path computation engine algorithms are required. There is no such a requirement for the Virtual Link mode. The major disadvantage of the Virtual Link mode, of course, is scalability: the number of the abstract links grows proportionally to the square of number of PEs. Because of that the Virtual Node mode could be the only choice to hide a domain with large number of PEs. Hope this helps. Igor ----- Original Message ----- From: "Don Fedyk" To: Cc: Sent: Thursday, August 04, 2005 6:03 AM Subject: RE: draft-ashwood-ccamp-gmpls-constraints Igor Thanks for the feedback I would like to work with you to capture the Virtual Link Mode into the draft. Regards, Don > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > Sent: Thursday, August 04, 2005 5:32 AM > > Hi, > > I believe this is a very useful draft. The described blocking > problem (a limited ability of a node to cross-connect > resources on input and output links wrt a particular LSP) > exists not only in the Virtual Node scenario: there could be > "real" network elements experiencing the problem (perhaps, > because of the hardware limitations). Hence there is a need > for a routing controller to be capable to advertise a map of > acceptable (or > unacceptable) input-output link combinations, and for a path > computer to account for such a constraint (which is not trivial). > > I also would suggest the authors to consider the Virtual Link > mode, that is, representing the domain to the outside world > as a bunch of PEs interconnected by abstract (virtual) links. > This approach may require more advertisements compared to the > Virtual Node mode; however, it does relieve external path > computers from handling the interface maps, plus it gives the > idea about the cost and attributes of feasible paths across > the domain. > > Igor From owner-ccamp@ops.ietf.org Tue Aug 09 10:07:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Uld-0006R2-Kf for ccamp-archive@megatron.ietf.org; Tue, 09 Aug 2005 10:07: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 KAA08852 for ; Tue, 9 Aug 2005 10:07:43 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2VJN-0000Sv-3C for ccamp-archive@ietf.org; Tue, 09 Aug 2005 10:42:48 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2UW9-0003oR-LM for ccamp-data@psg.com; Tue, 09 Aug 2005 13:51:45 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2UW7-0003nk-8Z for ccamp@ops.ietf.org; Tue, 09 Aug 2005 13:51:43 +0000 Received: from du-069-0483.access.clara.net ([217.158.145.229] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E2UVv-0007Ol-7i for ccamp@ops.ietf.org; Tue, 09 Aug 2005 14:51:42 +0100 Message-ID: <043401c59ce9$d17647f0$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft minutes - comments please Date: Tue, 9 Aug 2005 13:09:15 +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: 876202f9cbc0933cffbc58102e40f8f2 Content-Transfer-Encoding: 7bit IETF-63 Paris August 2005 CCAMP Working Group Minutes thanks to Deborah Brungard and Don Fedyk Admin Adrian reviewed slides of agenda WG Status Adrian reviewed draft status and milestones ITU and OIF liaison report - Lyndon Ong Reviewed slides - Q14 Plan to share g7713 before goes for consent - No signaling activities, routing they are waiting for our DT response, next meeting in Chicago - OIF activities - OIF communication to IETF with identified issues from demo Adrian: Understand that there is no urgency for responding Will respond as quickly as possible, will post on mailing list. Lyndon: These are results of the demo so there is no dependence but they are important. Dimitri: Were these issues identified before or after demo? Lyndon: Some before, some after. Dimitri: Why not asked over the list for those before? Lyndon: Some of the issues were, like the encoding. The first issue was on an informal response. So we want a formal response. The other issues we made some implementation decisions so we want to verify the decisions. Interdomain RSVP - Arthi Ayyangar - Reviewed slides - Hope to get comments before do next revision (soon) then hope to go for last call Dimitri: Do you plan to keep the examples in the document or as appendix? Arthi: Do you think it affects readability? Dimitri: Prefer as appendix Arthi: OK Adrian: Is this an example or is it normative? Arthi: The example only describes the overall working. LSP stitching: Arthi Ayyangar - Reviewed slides - Summarized discussion on list - First point - Are procedures required for both PSC and non-PSC LSPs? - Discussion on list indicated yes Adrian: Also from a control plane point of view it is better to have a consistent behavior - 2nd point - Should allow stitching while traversing region boundaries? Dimitri: I see no reason for this, why are we still discussing? Adrian: I said yes on the list because of the last bullet on the slide. Why disallow it? Kireeti: I think yes also, why disallow it? Dimitri: Why allow it? Adrian: If we take it out of scope now, we may have to change later, so why remove it now? Yet we don't want to do it speculatively. Igor: Question for kireeti: Can we stitch PSC1 with PSC2 LSP? And we said while we could do this with a label stack, but we shouldn't allow it as these LSPs were provisioned for a reason as two different types (PSC1 and PSC2). In the non-packet world this more clear. Use hierarchy and adaptation. Kireeti: Not so clear for me. PSC1 & PSC2 We understand but Non-PSC we don't understand. For non PSC, we don't know where it will go, e.g. wavelength switching. So why prevent it? Igor: It is not complex but it is pointless. Kireeti: You can always say no when you receive a request to stitch. Arthi and Igor: No, you can't say no Lou: What is the difference between stitching and hierarchical LSP. The LSP on top (inner label) uses all the bandwidth of the one below (outer label). Adrian: The difference is if you add a label for the passenger LSP. Arthi: It's not just label allocation it's resource allocation. I'll address this later. - Bidirectional LSPs and control of labels - Current proposal resolves this by not sending a Label. - 4 options: In Slides: Lou: Minor suggestion; use a different C-type. Call it Option 2 Prime. Arthi: You can, but it is still an issue. Adrian: You have to do special processing when you do stitching anyway. Arthi: You still have to implement the C-type. Kireeti: You don't have to allocate a special label. Adrian: Agree Point 4: Need to provide end-to-end bidirectional service. For example for mpls/gmpls migration. Need to stitch two unidirectional LSPs in the middle. Arthi: Or could do 2nd part of (4). This is not really any changes Just need stronger description on what we are doing Personally like a sending label that is ignored. Adrian: Who likes this 2nd part? - Send any label and have receiver ignore it # Some show of hands Adrian: Anyone prefer one of the other solutions? # (No one?) Adrian: Seems a preference for this 2nd option, will take to list Lou: Clear to make the change. Change the text to Must. Dimitri: Can you make clear on the stitching for bidirectionality Arthi: Should it be required for non PSC? Lou: Anyone that supports stitching MUST support the procedures if they support stitching. Arthi: But if you are not following this document. You could be doing data plane stitching and not control plane stitching. Lou: If it is outside the standard then it is out of scope. If you follow the document you MUST follow the procedures. Per-Domain-Paths - JP Vasseur Would like to get feedback on last issue on slides. Adrian: I think the use of IP reachability information is important. The WG must make a conscious decision. JP: This I-D is only describing reachability outside of domain Adrian: We should say so more clearly Dimitri: I sent feedback. We should cover this question. Not sure if part of this document. This is a problem in several documents. If we have IP reachability, but don't know switching capability, then it's not sure if we can make the connection. This an issue when have a mixture of switching capabilities. Igor: When we compute path, we consider TE resources, not IP reachability. Should not rely on knowing reachability. Once you have a mix of terminating points this is a real issue. Adrian: We need to have a global solution. Igor: You want to compute path consider the resources TE resource reachability of destination. Not to rely on the IP but have static information that you can reach the path. JP: Just want to rely on IP reachability to reach next domain, and then let next domain decide if it can satisfy the request. Igor: OK - maybe could do aggregation rules You can have a static TE entry. JP: But we don't have information on resources Janis ??: Agree that if we are separating data and control plane, this will not work Adrian: Specifying what information to use for path computation is not covered anywhere. It is part of the algorithm, but not part of the protocol. CSPF can use any information including IP reachability or the weather. Arthi: So how do we find next hop? How do you get to the next domain? Adrian: If we don't do this process inside the domain, why do we have to have a way to get out of the domain? JP: So we should remove next hop? Arthi: Does not make sense. How to do crankback? Kireeti: OK - we need to consider further Addresses in GMPLS networks - Richard Rabbat Reviewed slides Arthi: why you are proposing as a std track? Adrian: This decision was a result of a loose poll based on whether this advises, recommends or mandates. Arthi: Can we do again the poll Adrian: We can, who prefers: # BCP - some show of hands # Stds track - less show of hands Arthi: My concern is that it is good to have this document, but it is using items from other docs and making some changes Have to change the Musts and Shoulds. Adrian: If text is repeating the same must/should from another document then it should be deleted. If this is new must/should language then it should be std track Need to clarify definitions. If you are Restating with same values, its BCP. If you change values it is Standards updating an existing RFC or a new Standards track document. Arthi: Then this should be std track as it is already doing it Lou: It is bringing together many items - would suggest informational Could be informational. I did not vote because I was waiting for informational. Adrian: Who wants informational? # almost same show of hands as BCP Lou: If it's implementation then BCP, but if bringing together info, then informational The document is putting recommendations on implementing. Is it just for building and deploying? Or is it Defining a new field or procedure? Adrian: OK we should discuss more Dimitri: I thought the same - it is bringing together experience on using addresses, not saying how to do, and not covering future issues. So I have issue with 9.3 which is not based on experience Adrian: The WG needs to decide how want to do Kireeti: We will discuss with ADs and take to list Arthi: For example, for the FA it says a MUST for how to use, but it doesn't say what to do for static case, so doesn't cover all cases Richard: Yakov: Slide #3. Why the decision on FA LSP, this is a change to the protocol. Richard: You don't know it is a FA LSP. How do you know that it is to be advertised back? John Drake: It is covered in RFC3477. Lou: That is unnumbered interfaces. Adrian: Numbered FA LSPs need a way to indicate to the egress that they will be used as FAs. Compare with unnumbered LSPs that have a special object. Arthi: What is the point of changing it to 0? Kireeti: Let's discuss on the list GMPLS/ASON Lexicography - Igor Bryskin Reviewed slides Igor: If anyone is interested in furthering ason-gmpls convergence, talk to Adrian or myself to help Richard: What is your objective? Igor: Have consensus in the group and expand the dictionary. Richard: Saw in one the drafts on ASON there is an appendix. With ASON terms. Should we integrate the ason-gmpls documents' reference terms into this document? Dimitri: No, that work was for CCAMP people to understand ASON. This is a different purpose Igor: Agree. This is for ITU people to understand GMPLS ASON routing evaluation - Dimitri Papadimitriou Reviewed slides Adrian: Who from DT is in the room? # Dimitri and Lyndon Adrian: Thanks for work. Does the DT think this is ready for last call? Lyndon: Yes. Just some minor editing Adrian: Anyone object to last call # None Alex: Doesn't WG need to read this first Adrian: Yes, need to read it for last call OK take to list for last call ASON signaling - Dimitri Papadimitriou Reviewed slides Dimitri: The community that wants to use this document needs it to be recognized as an RFC, it is important to finish Alex: Any technical issues on this or the last document that need to discuss now? Dimitri: Only this item on simultaneous call/connection signaling Alex: Please summarize the technical issues. Please focus the time in the meeting to raise and discuss open issues Lyndon: Will you liaison to SG15 before last call? Kireeti: Yes Steve Trowbridge: Should also include specific changes against g7713.2 Adrian: What is the intention? Steve: Should be for alignment, should not have two normative versions of ASON signaling Adrian: ITU already has versions .1, .2, .3 Steve: State how it differs from .2 version Adrian: OK. This is GMPLS. 7713.2 is not GMPLS. We can do a comparative analysis. Principal difference is call/connection piggybacking Lyndon: Is this UNI/ENNI/INNI? Dimitri: The document states clearly this if you read it Answer is all three Alex: Are the technical issues complete? It would be much better if we have the technical summary. Not just say this work is ready or work is stable. Adrian: We owe the WG status. Kireeti: Dimitri, can you start the liaison? Dimitri: OK CCAMP Work Plan Kireeti reviewed the slide on options what to do - We have pretty much cleared the documents in our queue, and we are reviewing the charter to update Alex: - I have 12 documents submitted to me, 10 docs in id list. - Documents are done when finished also IESG review, I don't expect to wait for this though before going on to new items. Alex reviewed slide on potential new work - Inter domain OK - Layer 2 switching: where is this? Kireeti: We will have a discussion on where to put it Alex continues: - L1VPN New WG - doesn't seem any objection, should prioritize and timeline - Are these Milestones or Work items? Kireeti: - Could do milestones, but defining work items is easier - For example, MPLS/GMPLS interworking is implicit in the charter but not specifically covered. Alex: Can identify high priority items now Adrian: - We already asked the working group and this is on the first slide. - There are six items shown on the slide Alex: Six items that need some work. Is that too much? Adrian: - Not all things are the same size. - Interoperability issues are already on the plate. - Layer 2 switching Moderate size thing. - MPLS/GMPLS migration moderate size. - Second slide shows recent new topics. Maybe take on new items. - Signaling Issues: - Routing issues - GMPLS OAM requirements. Alex: These items are also important Kireeti: Should look at pipelining work as we already started first slide. It all depends on how long it takes to do charter. We have been waiting now for more than a year Alex: Can prioritize and identify if can spin off work to a new, separate working group. Just like Layer 1 VPN that uses GMPLS. Take out other lumps and put in other WGs? Chairs should identify items. Adrian: We can discuss which could spin off, though we need to decide, and not delay, as many items are already being worked on. Bijan Jabbari: When I look at what is being implemented by vendors there is a mismatch with what this group is doing. Perhaps should look at short term. Alex: Yes my thoughts should look at 1 year to 2 years. Bijan: Not really clear what is being implemented Bijan: I work with Academia and industry, and the answer is not clear. You see implementations but you don't see deployments. Business reasons etc. New way of thinking that takes time. Alex: When go for standard track, do need implementation Kireeti: Also need deployments, and that takes time JP: Regarding the item on "input to PCE requirements". Not sure if need this input Adrian: Explain history is that CCAMP made a commitment to assist PCE Could agree to remove this commitment Alex: Yes we should discuss more in both groups. Don't want to make commitment to remove this before discussing it. If we have consensus maybe we don't need the document. JP: On advertisement of TE/GMPLS capabilities, we have implemented and deployed in 5 large service providers, so would like to expedite this Lou: Slide Back to Slide3: For the item on charter - missing is ASON. What do we do about alignment, and that we have two versions of RSVP? There is only one version of GMPLS, what do we need to do? What steps that we need to take as a WG? Alex: ASON is on our charter Lou: It's on charter - we have completed our documents. We can send to SG15, but what do we do from there to align GMPLS and ASON solutions? Adrian: Added it to slides Richard: On recent new topics - do we know what is in-charter currently? Alex: It is up to chairs: Adrian: If it is in the scope of the charter, we will do milestones There will be discussion on the list. Dimitri: Why is "deployment considerations" considered marginal? If you want feedback, how can this be classified as marginal? Please prioritize and please discuss. Adrian: This is from the community view gathered on the list last year Dimitri: Then how will we have deployment Kireeti: You can do canvassing to get people to discuss. We will take back to the list to do a poll again GMPLS for Ethernet - Dimitri Papadimitriou Reviewed slides Define a set of scenarios: 4 Scenarios -Aggregation -Metro -Unified? Core -Transport Dimitri asked if interest to do this work Don Fedyk: We still don't know what is actually meant by GMPLS Ethernet. The document does not go far enough today with enough detail. The document is too open ended and we don't know what exactly is being specified. I asked for more detailed specification. Dimitri: Ali Sajassi: Ethernet differs from other data planes as it's not point to point. Do you want to keep it as in the perspective of IEEE? Other comments: you want to replace existing Ethernet control plane with GMPLS: again how will you do multipoint? Shortest path may overlap with issues discussed in TRILL. How are you going to coordinate with other WGs? Loa: Not speaking for the DT as we didn't discuss it: I have experience running a medium/large scale Ethernet network as a point-to-point network (unified/core). It would be very applicable to add a gmpls control plane. Note that if we can't do it as a standard we (deployers) will do it ourselves. It is pretty straight forward. Ali: I can see for point to point, it's for multipoint that I see it will have issues Dimitri: OK. Can you input specifics? These questions are relevant. How do we work and overlap with various working groups? Richard Spencer: Can you confirm that using GMPLS in enterprise is out of scope? Dimitri: As no one has expressed interest I would say it is out of scope Richard S: Will there be any changes to Ethernet control/data plane? What would be the potential difficulties? Have a discussion with the IEEE and see where they would be impacted. Dimitri: I can not say what will be the solution chosen, we already suggested we work with IEEE Richard S: I see little value for aggregation. I don't see in metro why a provider would want to use this instead of VPLS Dimitri: I have replied to some of the issues on the list. We should discuss more on list Kireeti: We will not change the Ethernet data plane here. If we conclude it may need to be changed, we will liaise to IEEE and get their agreement. CCAMP is focused on core tunneling technologies, though we don't say how you will use them - metro or core - I would like us to continue not to be specific for access or core. If there is anything specifically different for access, then need to add to charter. Lyndon: There is a lot of interest in other groups (ITU, OIF, MEF). I think there is interest. Where people are uncertain is how. Need to look at more on supporting pt to pt or multipt. Don O'Conner: How does this differ from l2vpn? Dimitri: It differs in that this is not mpls. Kireeti: L2VPON charter is different. L2VPN sets up vpns. This work is on signaling and routing in Ethernet networks. Tom Nadeau: Is this in the scope of CCAMP today? Adrian: Yes this is in the scope as a core network. GMPLS handles packet transport networks. Maybe this is could be a new working group. Tom: Seems similar to TRILL. Adrian: Yes. Need to determine if there is overlap. Perhaps this work should go there. Alternatively, perhaps this work goes in a new WG. Dimitri: Some of the items have been discussed. Loa: Trill is in campus networks. Alex: For structuring this work, we need to be very clear what data path modifications need to be done. Should communicate with IEEE liaison, preferably before BOF. MPLS working group is a specific example. : What would be the way to contact the IEEE to do this? Can I get a Liaison? Alex: We have an established liaison relationship with IEEE. Kireeti: First need to decide if we need a change in the data plane. Then talk to the IEEE. Adrian: Also need to tell IEEE what we plan to do, no matter how we do it. Smith: There are limits to the use of VLAN-ID. There are only 4K of them. Will you use this as the label? Adrian: We haven't decided anything about how forwarding will occur yet Dinesh Mohan: I haven't heard yet that there is planned a change to the data plane. Need to understand better. Should look at this as a new control plane using existing data plane. It would be nice to have the GMPLS Control plane but is there no intent to change the control plane? The basic assumption is that you have a different control plane then that should be the assumption. This is fine to explore, but the starting point is not to modify the data plane. Adrian: When we control SDH we did not mess with the data plane. We should not be modifying the transport technology. Monique Morrow: Echo what Alex said, any modification we need to talk to the IEEE. Dimitri: OK, but we are not talking in the context that there is a change to data plane. Ali: Trill and this are using ISIS. Trill plan to change the data plane. Kireeti: Please stop, take to list. Ali: Several vendors offer Ethernet switches that offer point to point using MPLS control plane supporting millions of connections. Yakov: How? Could you tell me whether they carry a label? Ali: Yes. They are MPLS switches Yakov: So it is a router, an LSR , that you can call an Ethernet switch and you are done? Adrian: That is indeed a suggestion. Don O'C: Ethernet is connectionless and now GMPLS is connection- oriented, so this is different. This is redefining Ethernet to make it connection oriented. Is that the intent? Is this making VLAN tags look like GMPLS labels? Adrian: Again, this has not been discussed Loa: From experience, we don't want to remove VLAN tags. Need something else. And the chairs said to the design team not to do that, yet 80% of CCAMP are already assuming this is what we want to do. Adrian: Design team job is done - Thanks. We need now for the WG to discuss. Time is over. Other drafts that we didn't get to discuss, take to list. From owner-ccamp@ops.ietf.org Wed Aug 10 05:44:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2n8n-0003OR-Os for ccamp-archive@megatron.ietf.org; Wed, 10 Aug 2005 05:44: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 FAA16674 for ; Wed, 10 Aug 2005 05:44:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2ngm-0000NJ-Pw for ccamp-archive@ietf.org; Wed, 10 Aug 2005 06:20:07 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2mz5-000BH2-79 for ccamp-data@psg.com; Wed, 10 Aug 2005 09:34:51 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2mz4-000BGg-5g for ccamp@ops.ietf.org; Wed, 10 Aug 2005 09:34:50 +0000 Received: from pc6 (1Cust196.tnt27.lnd4.gbr.da.uu.net [62.188.154.196]) by blaster.systems.pipex.net (Postfix) with SMTP id 92B1FE000224; Wed, 10 Aug 2005 10:34:38 +0100 (BST) Message-ID: <000f01c59d86$306c2760$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , References: <069201c54cb9$7ec46cb0$1c849ed9@Puppy> Subject: Re: Last call complete on GMPLS MIBs Date: Wed, 10 Aug 2005 10:30:45 +0200 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.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Adrian I finally got to look at the new versions of the GMPLS MIBs that came out in June and am pleased to see my previous comments in use:-). Some follow up thoughts. In draft-ietf-ccamp-gmpls-te-mib-09, I see that IANAGmplsSwitchingType ::= TEXTUAL-CONVENTION still references "1. Kompella, K., Rekhter, Y. (Editors), Routing Extensions in Support of Generalized Multi-Protocol Label Switching draft-ietf-ccamp-gmpls-routing, work in progress. which I think should be draft-ietf-ccamp-ospf-gmpls-extensions for l2sc (51). The former introduces the concept but does not give a value; the latter assigns the value 51. IANAGmplsLSPEncoding has a reference to D. Papadimitriou (Editor), Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control, draft-ietf-ccamp-gmpls-g709, work in progress which I think should make that a normative reference. And, more generally with these references to I-Ds which are normative, should we add a note to tell the RFC editor to replace this with a reference to the RFC when it emerges? That would be business as usual in the References section but might need a little encouragement buried in a MIB module DESCRIPTION. IANAGmplsAdminStatusFlags defines BITS as delInProgress (0), adminDown (1), testing (2), reflect (31) while RFC3471 has reflect as bit 0 and delInProgress as bit 31. Is that correct? (I assume that the intent is to keep them in line and I don't know which way round BITS go; I assumed bit 0 came first and was MSB. If ITU and IETF part company over this, we should be using IETF nomenclature:-) In draft-ietf-ccamp-gmpls-lsr-mib-08.txt, I would like you to give the RFC Editor a little more help in resolving GMPLSTCMIB by explicitly stating that it is the RFC produced from draft-ietf-ccamp-gmpls-tc-mib-07.txt Somewhat bigger issue; I am concerned that no constraint is placed on the allocation by IANA of new values in the IANA MIB module, where the base documents call for more stringent action (although there is some disagreement as to what that is). As it stands, it seems to me that anyone in the world can e-mail IANA and get a new value assigned in the IANA MIB module, whereas I think it should be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing or draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, perhaps by Expert Review ie the existence of a new name/number mapping is documented in an RFC or I-D and Expert Review allows that mapping to be added to IANA MIB module. We could require the RFC that introduces a new mapping to have an IANA section that updates the MIB module but I fear that most editors would forget to include it, so Expert Review seems best. Finally, I would prefer the IANA MIB modules to be retained in the published RFC with a note that the authoritative source is IANA; this gives us an audit trail of how we got to where we are, or not as the case may be. There has been a case just recently elsewhere where the RFC and IANA are different and it is valuable to see just what it was that was last called and approved by all concerned. As and when the RFC containing the IANA MIB module is reissued, then there would be no need to replicate it. Tom Petch From owner-ccamp@ops.ietf.org Wed Aug 10 14:47:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vbX-0000Ga-UB for ccamp-archive@megatron.ietf.org; Wed, 10 Aug 2005 14:47:08 -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 OAA17400 for ; Wed, 10 Aug 2005 14:47:06 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2w9h-0007iC-1N for ccamp-archive@ietf.org; Wed, 10 Aug 2005 15:22:26 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2vSJ-0002Yy-BR for ccamp-data@psg.com; Wed, 10 Aug 2005 18:37:35 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2vSH-0002YZ-BX for ccamp@ops.ietf.org; Wed, 10 Aug 2005 18:37:33 +0000 Received: from du-069-0215.access.clara.net ([217.158.132.215] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E2vSE-0009qi-HY for ccamp@ops.ietf.org; Wed, 10 Aug 2005 19:37:32 +0100 Message-ID: <076101c59dda$f00c0c80$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Liaison to ITU-T Q3/15 about your Liaison "Reply on GMPLS/ASON Lexicography" Date: Wed, 10 Aug 2005 19:32:42 +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: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Hi, This response from Hiroshi Ohta rapporteur of ITU-T Q3/15 indicates that no specific action was required to their liaison, but that we should keep them informed of our progress on the lexicography I-D. Adrian ----- Original Message ----- From: "Hiroshi Ohta" To: "Adrian Farrel" ; Cc: ; ; ; ; ; ; ; ; Sent: Thursday, August 04, 2005 8:45 AM Subject: Re: Liaison to ITU-T Q3/15 about your Liaison "Reply on GMPLS/ASON Lexicography" > Dear Adrian, > > As we talked after the ccamp session yesterday, Q.3/15 expects > a response to our liaison from ccamp in some form and hopes to > continue this on-going dialog between ccamp and some Questions > within SG15. This is the reason for the mark "For: Action". > > Best regards, > > Hiroshi Ohta > Q.3/15 rapporteur > > > At 17:09 05/06/03 +0100, Adrian Farrel wrote: > >Title: Liaison to ITU-T Q3/15 about your Liaison "Reply on GMPLS/ASON > >Lexicography" > >To: ITU-T Study Group 15 Question 3 > >From: IETF CCAMP Working Group > >For: Action > >Deadline: August 1, 2005 > > > >CCAMP would like to thank Q3/15 for their liaison and the useful > >explanatory information it contains. > > > >The liaison is marked "For: Action" with a deadline of August 31,2005. > >However, there are no obvious requests for action within the liaison. > > > >Can you please clarify whether there was an intent to request specific > >action. > > > >Thank you. > > > >Adrian Farrel and Kireeti Kompella > >CCAMP Working Group Co-Chairs > > > From owner-ccamp@ops.ietf.org Thu Aug 11 08:40:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3CM8-0007H3-P2 for ccamp-archive@megatron.ietf.org; Thu, 11 Aug 2005 08:40:20 -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 IAA28080 for ; Thu, 11 Aug 2005 08:40:19 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3CuO-0003Xt-5i for ccamp-archive@ietf.org; Thu, 11 Aug 2005 09:15:48 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3CBu-000OaZ-2X for ccamp-data@psg.com; Thu, 11 Aug 2005 12:29:46 +0000 Received: from [47.140.192.55] (helo=zrtps0kn.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3CBp-000OaA-SS for ccamp@ops.ietf.org; Thu, 11 Aug 2005 12:29:42 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7BCTbE05071 for ; Thu, 11 Aug 2005 08:29:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message Subject: RE: draft-ashwood-ccamp-gmpls-constraints Date: Thu, 11 Aug 2005 08:29:20 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA403846FC8@zrtphxm2> Thread-Topic: draft-ashwood-ccamp-gmpls-constraints Thread-Index: AcWcUaICAhsxzeXeQB2k63l/OCm87QArBlFQ From: "Don Fedyk" To: "Igor Bryskin" Cc: 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: b7b9551d71acde901886cc48bfc088a6 Hi Igor Thanks for this text. We will incorporate some this text into the next version of the draft. Hamid had asked me to involve the L1VPN list in this activity going forward. Regards, Don > -----Original Message----- > From: Igor Bryskin [mailto:ibryskin@movaz.com] > Sent: Monday, August 08, 2005 3:44 PM > > Don, > > You can find a detailed description of the Virtual Link mode in the > Layer 1 VPN WG documents. > > In brief, in this mode a domain is represented to the outside routing > domain not as a single node (as in case of the Virtual Node mode), but > as a set of PEs interconnected by virtual (more correctly, abstract) > links. The Virtual Link mode has some serious advantages compared to > the Virtual Node mode. Here is some of them: > > 1. In the Virtual Node mode there is some synchronization required > between > PEs: in order for the outside routing domain to perceive the > hidden domain as a single node all PEs need either to > generate exactly the same advertisings ( specifically, they > need to agree on the Virtual Node Router ID, learn about > every other PE and the links interconnecting the PE with the > outside routing domain, etc.) or identify the outside routing > domain segments interconnected exclusively by the means of > the hidden domain and elect for each of them a single PE that > would generate the Virtual Node advertisings. Neither of > these approaches is trivial to implement. On the contrary, > PEs in the Virtual Link mode advertise information into the > outside routing domain completely independently. > > 2. In order to advertise a matrix of acceptable input-output link > combinations a PE must periodically solve ALL PEs -TO-ALL PEs > constraint based path computation problem. It is far more difficult > problem to solve compared to a single PE -TO-ALL PEs constraint based > path computation (which is as complex as a single source - single > destination path > computation) required in the Virtual Link mode; > > 3. The constraints used during the computation of the input-output > link matrix is not advertised and not available for the external path > computer, which diminishes the value of the matrix advertising. In > other words, even when the external path computer uses the matrix as a > constraint, there is still a significant blocking probability of the > LSP setup using the computed path because there is no guarantee that > the sets of the "external" and "internal" path computation > constraints match. There is no such problem in the Virtual > Link mode where the internal path computation constraints > could be advertised as abstract TE link attributes and hence > could be considered explicitly by the external path computer > > 4. The matrix of input-output link combinations does not provide > information about the cost of a particular input-output binding across > the hidden domain. This means that suboptimal path selection is quite > possible. On the contrary, each abstract TE link advertising has a TE > metric sub-TLV; > > 5. It is not trivial to use the matrix of input-output link > combinations as a constraint, and some modifications of the external > path computation engine algorithms are required. There is no such a > requirement for the Virtual Link mode. > > The major disadvantage of the Virtual Link mode, of course, is > scalability: the number of the abstract links grows proportionally to > the square of number of PEs. Because of that the Virtual Node mode > could be the only choice to hide a domain with large number of PEs. > > Hope this helps. > Igor > > From owner-ccamp@ops.ietf.org Thu Aug 11 08:49:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3CVH-0000qh-IZ for ccamp-archive@megatron.ietf.org; Thu, 11 Aug 2005 08:49: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 IAA28601 for ; Thu, 11 Aug 2005 08:49:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3D3S-0003lk-Nt for ccamp-archive@ietf.org; Thu, 11 Aug 2005 09:25:15 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3CNN-000PW9-7U for ccamp-data@psg.com; Thu, 11 Aug 2005 12:41:37 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3CNL-000PVu-1c for ccamp@ops.ietf.org; Thu, 11 Aug 2005 12:41:35 +0000 Received: from du-069-0050.access.clara.net ([217.158.132.50] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E3CN4-0009yb-80 for ccamp@ops.ietf.org; Thu, 11 Aug 2005 13:41:34 +0100 Message-ID: <08c901c59e72$56e425e0$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <00f001c592ed$e72f0510$0601a8c0@Puppy> Subject: Responding to the OIF Date: Thu, 11 Aug 2005 13:42:56 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08C6_01C59E7A.94425120" 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_20_30, HTML_MESSAGE autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: dd9ffe26482d533f4d1fa531728a7327 This is a multi-part message in MIME format. ------=_NextPart_000_08C6_01C59E7A.94425120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As Lyndon noted in Paris, the OIF has sent us a communication requesting = some guidance on a bunch of questions. This is to start the business of constructing a reply. thanks to Dimitri = for supplying some of this text. Please send comments and improvements. Adrian =3D=3D=3D=3D=3D=3D To: Jim Jones, OIF Technical Committee Chair From: Adrian Farrel and Kireeti Kompella,=20 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 >=20 > 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. >=20 > 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.=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. 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 =3D 0 NCC =3D 0 NVC =3D 0 MT =3D 1 T =3D 0 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 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=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. 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 =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. We believe that this final sentence should read "greater than or equal = to 1," and that this interpretation resolves all of your issues and = makes the text consistent with the examples. > 2. Setting of NVC for VCAT connections >=20 > 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 >=20 > 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. >=20 > 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=20 LSP b/w 2 4 bytes=20 LSP b/w 3 4 bytes=20 LSP b/w 4 4 bytes=20 LSP b/w 5 4 bytes=20 LSP b/w 6 4 bytes=20 LSP b/w 7 4 bytes min b/w 4 bytes indication 1 byte =3D=3D 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 >=20 > 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: >=20 > "The absence of the object is equivalent to receiving an object = containing > values all set to zero (0)." >=20 > 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 >=20 > 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. >=20 > 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, an 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. > 6. Symmetry of Refresh Reduction usage >=20 > 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. >=20 > 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. >=20 > 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.=20 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=20 to an LSR that is not setting the refresh-reduction-capable=20 bit. - An LSR may send refresh reduction options or messages =20 to an LSR that is setting the refresh-reduction-capable bit. - An LSR that wishes to successfully use responded refresh=20 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 >=20 > 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. >=20 > 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=20 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... ::=3D [ ] 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 is currently discussing the use of GMPLS for = control of Ethernet devices. We will respond to this point in a separate = email. Best regards, Adrian Farrel Kireeti Kompella ------=_NextPart_000_08C6_01C59E7A.94425120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

As Lyndon noted in Paris, = the OIF has=20 sent us a communication requesting some guidance on a bunch of=20 questions.

This is to start the business of constructing a reply. = thanks=20 to Dimitri for supplying some of this text.

Please send comments = and=20 improvements.

Adrian

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

To: Jim = Jones, OIF Technical=20 Committee Chair
From: Adrian Farrel and Kireeti Kompella,=20
          WG Co-Chairs = for IETF=20 CCAMP
Copy: Alex Zinin and Bill Fenner, IETF Routing Area=20 Directors
Subject: Response to your questions about GMPLS=20 parameters.

Dear Jim,

Thanks for your correspondence about = the=20 questions with respect to GMPLS parameters that arose before and during = your=20 interoperability testing. CCAMP is pleased to receive such questions and = is glad=20 to have the opportunity to explain the intended operation of the GMPLS=20 protocols.
 
Much of the material supplied below = can be simply=20 extracted from the relevant RFCs.


> 1. Use of the NCC and RCC fields for STS-3c/VC-4=20 connections
>
> During OIF testing it was noted that some = ambiguity=20 exists in the
> specification of encoding of NCC, RCC and NVC for = certain=20 types of
> connections: NCC and RCC for an STS-3c/VC-4 connection = can be=20 set to 0 or
> to 1 depending on which example of RFC 3946 is=20 followed.
>
> Clarification is requested from IETF CCAMP as = to=20 which setting is
> considered correct, or if both settings should = be=20 accepted (this procedure
> was used during testing at=20 Supercomm).

This question about RFC 3946 was raised informally on = the=20 CCAMP mailing list at the start of March this year.

Even when = the signal=20 Type value is the same (i.e. value 6) the NCC, RCC and NVC values depend = on the=20 specific signal being requested.

From the examples in the annex = we=20 have...

   A VC-4 signal is formed by applying the=20 following
   settings to a VC-4 Elementary=20 Signal.
      RCC =3D=20 0
      NCC =3D = 0
     =20 NVC =3D 0
      MT  =3D=20 1
      T   =3D = 0

   An=20 STS-3c SPE signal is formed by applying the following
   = settings=20 to an STS-3c SPE Elementary Signal.
      = RCC =3D 1=20 (standard contiguous concatenation)
      = NCC =3D=20 1
      NVC =3D = 0
     =20 MT  =3D 1
      T   =3D = 0

Your=20 question probably arises from the two notes and subsequent paragraph in = section=20 2.1 or RFC 3946. Here it says...

   Note 1: when = requesting a=20 SONET STS-Nc SPE with N=3D3*X, the
      = Elementary=20 Signal to use must always be an STS-3c_SPE signal=20 type
      and the value of NCC must always = be equal=20 to X.  This allows also
      = facilitating the=20 interworking between SONET and SDH.  = In
     =20 particular, it means that the contiguous concatenation of=20 three
      STS-1 SPEs can not be requested = because=20 according to this
      specification, this = type of=20 signal must be coded using the STS-3c
      = SPE=20 signal type.

   Note 2: when requesting a transparent=20 STS-N/STM-N signal
      limited to a single = contiguously concatenated = STS-Nc_SPE/VC-4-Nc,
     =20 the signal type must be STS-N/STM-N, RCC with flag 1 and NCC=20 set
      to 1.

   The NCC = value=20 must be consistent with the type of contiguous
   = concatenation=20 being requested in the RCC field.  In particular, = this
  =20 field is irrelevant if no contiguous concatenation is requested=20 (RCC
   =3D 0), in that case it must be set to zero when = sent, and=20 should be
   ignored when received.  A RCC value = different=20 from 0 must imply a
   number of contiguous components = greater than=20 1.

We believe that this final sentence should read "greater than = or equal=20 to 1," and that this interpretation resolves all of your issues and = makes the=20 text consistent with the examples.

> 2. Setting of NVC for = VCAT=20 connections
>
> It was also noted that the setting of NVC = may be=20 somewhat ambiguous for
> the case where diverse connections are = used=20 within a single VCAT group.
> Each individual RSVP session = controls a=20 single connection, but the
> connection is part of a larger VCAT = group and=20 carries VCAT encoding of the
> H4 byte. Clarification is requested = from=20 IETF CCAMP and ITU-T Q.14/15 as
> to the correct setting of NVC = for this=20 case (0 or 1?). It should be noted
> that this case may occur with = a VCAT=20 group with only a single initial
> member, and that the NVC may = provide an=20 indication that VCAT encoding of
> the H4 byte is in use for the=20 connection.

A VCn-Xv group split into X components requires each = of its=20 component to be signaled with the NVC value set to 1. This setting is = regardless=20 of how the components are established.

> 3. Length of the = Interface=20 Switching Capability TLV
>
> Although the Interface = Switching=20 Capability TLV defined by CCAMP for
> SONET/SDH connections was = not used=20 for the testing, it was noted that the
> text describing the = length of the=20 Interface Switching Capability TLV
> defined in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly
> = ambiguous=20 due to the use of padding bytes.
>
> RFC 3630 states that = "The TLV=20 is padded to four-octet alignment; padding
> is not included in = the length=20 field (so a three octet value would have a
> length of three, but = the=20 total size of the TLV would be eight octets)."
 
Yes. Section 2.3.2 of RFC3630 gives a = definitive=20 statement of the meaning of the length field and the use of padding, and = provides an example.
 
> Reading of the encoding in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
> specifies that the = length=20 of the TLV for TDM is 41 bytes plus 3 bytes of
> padding, and = should be=20 given in the length field as 41 bytes rather than
> 44. OIF = requests=20 verification of this interpretation from the experts in
> IETF = CCAMP=20 group.
 
Note that the Interface Switching Capability Descriptor defined in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link = TLV.=20 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=20
  LSP b/w 2  4 bytes=20
  LSP b/w 3  4 bytes=20
  LSP b/w 4  4 bytes=20
  LSP b/w 5  4 bytes=20
  LSP b/w 6  4 bytes=20
  LSP b/w 7  4=20 bytes
  min b/w    4 bytes
  indication 1=20 byte
           = ; =3D=3D
           &n= bsp;41=20 bytes
 
We presume that your question relates to whether the 3-byte field = shown as=20 "padding" in the TDM-specific figure on page 6 of=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an = explicit=20 field.
 
It is an implicit field, and should not be included in the length = of the=20 TLV.
 
Nevertheless, we take this = opportunity to remind=20 the OIF that implementations of GMPLS protocols should be conservative = in what=20 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=20 reason. It should parse the TLV according to the defined fields and skip = the=20 final three bytes. Thus, it should not affect a receiving implementation = if the=20 sending implementation has treated the "padding" field as implicit or = explicit.=20 In the event that a receiving implementation rejected such a TLV on = grounds of=20 the value contained in the length field being too large, the fault would = lie=20 with the receiving implementation not the sending = implementation.
 
> 4. Use of ADMIN_STATUS in an = initial PATH=20 message
>
> Some implementations sent an ADMIN_STATUS = object with=20 no flags set in the
> initial PATH message, i.e., when no status = change=20 was being requested.
> Although this did not serve any particular=20 function, it was believed that
> this could be accepted as = RFC3473, sect.=20 7.2 (page 18) states:
>
> "The absence of the object is = equivalent=20 to receiving an object containing
> values all set to zero = (0)."
>=20
> It was our interpretation based on this text that a node should = accept=20 an
> ADMIN_STATUS object with no flags set in the same way as if = the=20 object was
> missing. Comment on this interpretation is=20 welcome.
 
The effect of the meaning is as you = state, but=20 the intention of the meaning is reversed. That is, an implementation = should=20 accept the absence of the ADMIN_STATUS object in the same way as if the = object=20 was present with no flags set. That is, the default behavior is to = consider the=20 ADMIN_STATUS object as a standard part of the processing.
 
We note from your first paragraph = that you assume=20 that the ADMIN_STATUS object is used to change the status of the LSP. = This is a=20 misinterpretation - it is used to control the status of the LSP. Thus, = if there=20 is no change to the status of an LSP, refresh messages must continue to = carry=20 the ADMIN_STATUS object with the same bit setting.
 
In this way, it is not possible to = "drop" the=20 ADMIN_STATUS object without having the same meaning as transmitting the = object=20 with all bits cleared.
 
> 5. Handling of multiple received = ResvConf=20 Request objects
>
> When a connection desires a = confirmation that=20 the service (i.e.
> connection) requested is in place, a = RESV_CONF_REQ=20 object is included in
> the RESV message. As this object is = received by=20 the remote end of the
> reservation, it will send a RESV_CONF = message back=20 to the requester.
>
> However, it is unclear whether it is=20 necessary to send a RESV_CONF message
> when the RSVP connection = state is=20 refreshed by subsequent RESV. This
> becomes potentially = burdensome,=20 especially when the reservation is being
> rapidly refreshed. = Therefore we=20 ask: should the remote end send a
> RESV_CONF message for = subsequent RESV=20 messages that still include the
> RESV_CONF_REQ object? Or is it = required=20 that the requestor of the
> reservation remove the RESV_CONF_REQ = object to=20 prevent the generation of
> further RESV_CONF messages? Comment on = this=20 issue from IETF CCAMP is
> requested.
 
It is fundamental to = the implementation of=20 RSVP-TE that there is a good understanding of the distinction between a = trigger=20 message and a refresh message. This can be achieved by reading section = 1.1 of=20 RFC2961.
 
Following this understanding, you = will note that=20 a refresh message does not cause any processing to be performed at the = LSR that=20 receives it (in this case the ingress). You will also note that refresh=20 processing is not end-to-end as implied in your text, but is=20 hop-by-hop.
 
Thus, an downstream LSR that wishes = to trigger a=20 new ResvConf message must make a specific change to the content of the = Resv=20 message that it sends in order to cause a trigger message to be = propagated=20 through the network to the ingress LSR. Such processing is = implementation=20 specific.

> 6. Symmetry of Refresh Reduction usage
>
> = During=20 interop testing, we ran into a conflict caused by varying
>=20 interpretations of RFC2961, regarding the use of SRefresh messages and=20 the
> Refresh Reduction capabilities of the two ends of a given = link.=20 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=20 Reduction - including the
> SRefresh message. This would be true = even if=20 the other end of the link for
> that interface were NOT indicating = Refresh=20 Reduction Capability, since the
> RFC makes no statement about = symmetry in=20 this matter.
>
> Another interpretation is that both ends = of an=20 interface must indicate
> Refresh Reduction Capability before = either end=20 can use such messages, i.e,
> use of Refresh Reduction on a link = is=20 symmetric.
>
> Comment from CCAMP WG on the correct = interpretation=20 is requested.
 
We are confused by your question.
You correctly state that the use of the refresh-reduction-capable = bit=20 indicates the ability of an LSR to support the receipt of refresh = reduction=20 options and messages. To quote from section 2 of RFC2961...
           When = set,=20 indicates that this node is willing and capable=20 of
           = receiving all=20 the messages and objects described in=20 this
          =20 document.  This includes the Bundle message described=20 in
           = Section 3,=20 the MESSAGE_ID objects and Ack messages=20 described
          = in=20 Section 4, and the MESSAGE_ID LIST objects and=20 Srefresh
           = message=20 described in Section 5.  This bit is meaningful=20 only
           = between=20 RSVP neighbors.
This makes no statement about whether the LSR intends = to use=20 these options when communicating with another LSR.
 
However, you will note that some refresh reduction procedures = require that=20 a message is sent and response returned. In order to make use of the = response,=20 the receiver must be capable of receiving and processing the response. = Thus, it=20 would be usual for an LSR that is capable of sending refresh reduction = options=20 and messages to also set the refresh-reduction-capable bit.
 
In summary:
- An LSR must not send refresh reduction options or=20 messages 
  to an LSR that is not setting the refresh-reduction-capable =
  bit.
- An LSR may send refresh reduction options or messages =20
  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=20 known if a next hop supports the extension, standard Path and Resv = message based=20 refreshes MUST be used."
> 7. Sending of ACKs bundled with the RSVP HELLO
> =
> During=20 interop testing, it was observed that Message Acks were = piggybacked
> onto=20 RSVP Hello messages, when the receiving end was not using the = Hello
>=20 protocol. In this situation, the incoming Hello's were discarded and = the
>=20 Acks were lost.
>
> We believe that Message Acks should = only be=20 piggybacked onto mandatory
> messages, and not on Hello messages = because=20 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=20
   Bundle message.
Thus, Ack messages may be bundled with other messages. (Although = one might=20 consider this perverse since the Ack message is only introduced to = handle the=20 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=20 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=20 sub-message is processed in its own right, and the non-support/non-use = of Hello=20 messages should not impact the processing of other messages.
 
On the other hand, "piggybacked" implies the use of the Ack/Nack = objects=20 within a Hello message.
 
Section 4.1 of RFC2961 states that Ack/Nack objects may be included = in the=20 "standard" RSVP messages, and shows where they are placed. However, RFC = 3209=20 defines the Hello message as not including the Ack/Nack objects...
 
   <Hello Message> ::=3D <Common Header> [=20 <INTEGRITY>=20 ]
           &n= bsp;           &nb= sp;     =20 <HELLO>
 
Since RFC 3209 post-dates RFC 2961, this definition is definitive = and the=20 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=20 may be
   ignored by nodes which do not wish to participate = in=20 Hello message
   processing.
...it is not particularly important what the message format rules = are. An=20 implementation that chooses to place an Ack/Nack object in a Hello = message knows=20 that the object might be discarded unprocessed.
 
> 8. TSPEC format to be used for Ethernet connections
 
The CCAMP working group is currently discussing the use of GMPLS = for=20 control of Ethernet devices. We will respond to this point in a separate = email.

Best regards,
Adrian Farrel
Kireeti Kompella
------=_NextPart_000_08C6_01C59E7A.94425120-- From owner-ccamp@ops.ietf.org Thu Aug 11 11:40:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3FAv-0006go-1r for ccamp-archive@megatron.ietf.org; Thu, 11 Aug 2005 11:40: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 LAA09977 for ; Thu, 11 Aug 2005 11:40:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3FjA-0008SK-Mc for ccamp-archive@ietf.org; Thu, 11 Aug 2005 12:16:26 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3F3f-000DEP-6f for ccamp-data@psg.com; Thu, 11 Aug 2005 15:33:27 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3F3e-000DED-Jt for ccamp@ops.ietf.org; Thu, 11 Aug 2005 15:33:26 +0000 Received: from du-069-0319.access.clara.net ([217.158.145.65] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E3F3b-0001la-Eh for ccamp@ops.ietf.org; Thu, 11 Aug 2005 16:33:26 +0100 Message-ID: <093501c59e8a$626f8b80$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: ASON Routing evaluation ready for WG last call? Date: Thu, 11 Aug 2005 16:31:21 +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: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hi, draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt The DT said in Paris that this I-D is cooked apart from "some minor editing". I asked the room if anyone would object to a WG last call now, and Alex (as AD) suggested that more people should read the I-D before we decided whether it was ready for last call. This gives me the odd position of having a last call for a last call :-) This email gives notice that you need to read this I-D and make comments before 11th September 2005. Barring unresolved comments we will have a WG last call starting then. Thanks, Adrian From owner-ccamp@ops.ietf.org Thu Aug 11 11:42:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3FCW-0007Et-TC for ccamp-archive@megatron.ietf.org; Thu, 11 Aug 2005 11:42: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 LAA10043 for ; Thu, 11 Aug 2005 11:42:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Fko-0008VJ-5q for ccamp-archive@ietf.org; Thu, 11 Aug 2005 12:18:06 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3F3Z-000DE2-Vg for ccamp-data@psg.com; Thu, 11 Aug 2005 15:33:21 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3F3X-000DDf-N8 for ccamp@ops.ietf.org; Thu, 11 Aug 2005 15:33:20 +0000 Received: from du-069-0319.access.clara.net ([217.158.145.65] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E3F3N-0001la-FU for ccamp@ops.ietf.org; Thu, 11 Aug 2005 16:33:19 +0100 Message-ID: <093301c59e8a$59137510$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Updated minutes - more comments please Date: Thu, 11 Aug 2005 16:21:25 +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: 539f8b288ab42db633e5c7cf1c34fca1 Content-Transfer-Encoding: 7bit Thanks to Richard and Dimitri for filling some gaps. ====== IETF-63 Paris August 2005 CCAMP Working Group Minutes thanks to Deborah Brungard and Don Fedyk ------------------ 1) Admin Adrian reviewed slides of agenda ------------------ ------------------ 2) WG Status Adrian reviewed draft status and milestones ------------------ ------------------ 3) ITU and OIF liaison report - Lyndon Ong Reviewed slides - Q14 Plan to share g7713 before goes for consent - No signaling activities, routing they are waiting for our DT response, next meeting in Chicago - OIF activities - OIF communication to IETF with identified issues from demo ------------------ Adrian: Understand that there is no urgency for responding Will respond as quickly as possible, will post on mailing list. Lyndon: These are results of the demo so there is no dependence but they are important. Dimitri: Were these issues identified before or after demo? Lyndon: Some before, some after. Dimitri: Why not asked over the list for those before? Lyndon: Some of the issues were, like the encoding. The first issue was on an informal response. So we want a formal response. The other issues we made some implementation decisions so we want to verify the decisions. ------------------ ------------------ 4) Interdomain RSVP - Arthi Ayyangar Reviewed slides - Hope to get comments before do next revision (soon) then hope to go for last call ------------------ Dimitri: Do you plan to keep the examples in the document or as appendix? Arthi: Do you think it affects readability? Dimitri: Prefer as appendix Arthi: OK Adrian: Is this an example or is it normative? Arthi: The example only describes the overall working. ------------------ ------------------ 5) LSP stitching: Arthi Ayyangar Reviewed slides - Summarized discussion on list - First point - Are procedures required for both PSC and non-PSC LSPs? - Discussion on list indicated yes Adrian: Also from a control plane point of view it is better to have a consistent behavior - 2nd point - Should allow stitching while traversing region boundaries? Dimitri: I see no reason for this, why are we still discussing? Adrian: I said yes on the list because of the last bullet on the slide. Why disallow it? Kireeti: I think yes also, why disallow it? Dimitri: Why allow it? Adrian: If we take it out of scope now, we may have to change later, so why remove it now? Yet we don't want to do it speculatively. Igor: Question for kireeti: Can we stitch PSC1 with PSC2 LSP? And we said while we could do this with a label stack, but we shouldn't allow it as these LSPs were provisioned for a reason as two different types (PSC1 and PSC2). In the non-packet world this more clear. Use hierarchy and adaptation. Kireeti: Not so clear for me. PSC1 & PSC2 We understand but Non-PSC we don't understand. For non PSC, we don't know where it will go, e.g. wavelength switching. So why prevent it? Igor: It is not complex but it is pointless. Kireeti: You can always say no when you receive a request to stitch. Arthi and Igor: No, you can't say no Lou: What is the difference between stitching and hierarchical LSP. The LSP on top (inner label) uses all the bandwidth of the one below (outer label). Adrian: The difference is if you add a label for the passenger LSP. Arthi: It's not just label allocation it's resource allocation. I'll address this later. - Bidirectional LSPs and control of labels - Current proposal resolves this by not sending a Label. - 4 options: In Slides: Lou: Minor suggestion; use a different C-type. Call it Option 2 Prime. Arthi: You can, but it is still an issue. Adrian: You have to do special processing when you do stitching anyway. Arthi: You still have to implement the C-type. Kireeti: You don't have to allocate a special label. Adrian: Agree Point 4: Need to provide end-to-end bidirectional service. For example for mpls/gmpls migration. Need to stitch two unidirectional LSPs in the middle. Arthi: Or could do 2nd part of (4). This is not really any changes Just need stronger description on what we are doing Personally like a sending label that is ignored. Adrian: Who likes this 2nd part? - Send any label and have receiver ignore it # Some show of hands Adrian: Anyone prefer one of the other solutions? # (No one?) Adrian: Seems a preference for this 2nd option, will take to list Lou: Clear to make the change. Change the text to Must. Dimitri: Can you make clear on the stitching for bidirectionality Arthi: Should it be required for non PSC? Lou: Anyone that supports stitching MUST support the procedures if they support stitching. Arthi: But if you are not following this document. You could be doing data plane stitching and not control plane stitching. Lou: If it is outside the standard then it is out of scope. If you follow the document you MUST follow the procedures. ------------------ ------------------ 6) Per-Domain-Paths - JP Vasseur Would like to get feedback on last issue on slides. ------------------ Adrian: I think the use of IP reachability information is important. The WG must make a conscious decision. JP: This I-D is only describing reachability outside of domain Adrian: We should say so more clearly Dimitri: I sent feedback. We should cover this question. Not sure if part of this document. This is a problem in several documents. If we have IP reachability, but don't know switching capability, then it's not sure if we can make the connection. This an issue when have a mixture of switching capabilities. Igor: When we compute path, we consider TE resources, not IP reachability. Should not rely on knowing reachability. Once you have a mix of terminating points this is a real issue. Adrian: We need to have a global solution. Igor: You want to compute path consider the resources TE resource reachability of destination. Not to rely on the IP but have static information that you can reach the path. JP: Just want to rely on IP reachability to reach next domain, and then let next domain decide if it can satisfy the request. Igor: OK - maybe could do aggregation rules You can have a static TE entry. JP: But we don't have information on resources Janis ??: Agree that if we are separating data and control plane, this will not work Adrian: Specifying what information to use for path computation is not covered anywhere. It is part of the algorithm, but not part of the protocol. CSPF can use any information including IP reachability or the weather. Arthi: So how do we find next hop? How do you get to the next domain? Adrian: If we don't do this process inside the domain, why do we have to have a way to get out of the domain? JP: So we should remove next hop? Arthi: Does not make sense. How to do crankback? Kireeti: OK - we need to consider further ------------------ ------------------ 7) Addresses in GMPLS networks - Richard Rabbat Reviewed slides ------------------ Arthi: why you are proposing as a std track? Adrian: This decision was a result of a loose poll based on whether this advises, recommends or mandates. Arthi: Can we do again the poll Adrian: We can, who prefers: # BCP - some show of hands # Stds track - less show of hands Arthi: My concern is that it is good to have this document, but it is using items from other docs and making some changes Have to change the Musts and Shoulds. Adrian: If text is repeating the same must/should from another document then it should be deleted. If this is new must/should language then it should be std track Need to clarify definitions. If you are Restating with same values, its BCP. If you change values it is Standards updating an existing RFC or a new Standards track document. Arthi: Then this should be std track as it is already doing it Lou: It is bringing together many items - would suggest informational Could be informational. I did not vote because I was waiting for informational. Adrian: Who wants informational? # almost same show of hands as BCP Lou: If it's implementation then BCP, but if bringing together info, then informational The document is putting recommendations on implementing. Is it just for building and deploying? Or is it Defining a new field or procedure? Adrian: OK we should discuss more Dimitri: I thought the same - it is bringing together experience on using addresses, not saying how to do, and not covering future issues. So I have issue with 9.3 which is not based on experience Adrian: The WG needs to decide how want to do Kireeti: We will discuss with ADs and take to list Arthi: For example, for the FA it says a MUST for how to use, but it doesn't say what to do for static case, so doesn't cover all cases Richard: This is an oversight. we'll correct it in the next revision to say that we're talking about the dynamic case. Yakov: Slide #3. Why the decision on FA LSP, this is a change to the protocol. Richard: You don't know it is a FA LSP. How do you know that it is to be advertised back? John Drake: It is covered in RFC3477. Lou: That is unnumbered interfaces. Adrian: Numbered FA LSPs need a way to indicate to the egress that they will be used as FAs. Compare with unnumbered LSPs that have a special object. Arthi: What is the point of changing it to 0? Kireeti: Let's discuss on the list ------------------ ------------------ 8) GMPLS/ASON Lexicography - Igor Bryskin Reviewed slides ------------------ Igor: If anyone is interested in furthering ason-gmpls convergence, talk to Adrian or myself to help Richard: What is your objective? Igor: Have consensus in the group and expand the dictionary. Richard: Saw in one the drafts on ASON there is an appendix. With ASON terms. Should we integrate the ason-gmpls documents' reference terms into this document? Dimitri: No, that work was for CCAMP people to understand ASON. This is a different purpose Igor: Agree. This is for ITU people to understand GMPLS ------------------ ------------------ 9) ASON routing evaluation - Dimitri Papadimitriou Reviewed slides ------------------ Adrian: Who from DT is in the room? # Dimitri and Lyndon Adrian: Thanks for work. Does the DT think this is ready for last call? Lyndon: Yes. Just some minor editing Adrian: Anyone object to last call # None Alex: Doesn't WG need to read this first Adrian: Yes, need to read it for last call OK take to list for last call ------------------ ------------------ 10) ASON signaling - Dimitri Papadimitriou Reviewed slides ------------------ Dimitri: The community that wants to use this document needs it to be recognized as an RFC, it is important to finish Alex: Any technical issues on this or the last document that need to discuss now? Dimitri: Only this item on simultaneous call/connection signaling Alex: Please summarize the technical issues. Please focus the time in the meeting to raise and discuss open issues Lyndon: Will you liaison to SG15 before last call? Kireeti: Yes Steve Trowbridge: Should also include specific changes against g7713.2 Adrian: What is the intention? Steve: Should be for alignment, should not have two normative versions of ASON signaling Adrian: ITU already has versions .1, .2, .3 Steve: State how it differs from .2 version Adrian: OK. This is GMPLS. 7713.2 is not GMPLS. We can do a comparative analysis. Principal difference is call/connection piggybacking Lyndon: Is this UNI/ENNI/INNI? Dimitri: The document states clearly this if you read it Answer is all three Alex: Are the technical issues complete? It would be much better if we have the technical summary. Not just say this work is ready or work is stable. Adrian: We owe the WG status. Kireeti: Dimitri, can you start the liaison? Dimitri: OK ------------------ ------------------ 11) CCAMP Work Plan Kireeti reviewed the slide on options what to do - We have pretty much cleared the documents in our queue, and we are reviewing the charter to update ------------------ Alex: - I have 12 documents submitted to me, 10 docs in id list. - Documents are done when finished also IESG review, I don't expect to wait for this though before going on to new items. Alex reviewed slide on potential new work - Inter domain OK - Layer 2 switching: where is this? Kireeti: We will have a discussion on where to put it Alex continues: - L1VPN New WG - doesn't seem any objection, should prioritize and timeline - Are these Milestones or Work items? Kireeti: - Could do milestones, but defining work items is easier - For example, MPLS/GMPLS interworking is implicit in the charter but not specifically covered. Alex: Can identify high priority items now Adrian: - We already asked the working group and this is on the first slide. - There are six items shown on the slide Alex: Six items that need some work. Is that too much? Adrian: - Not all things are the same size. - Interoperability issues are already on the plate. - Layer 2 switching Moderate size thing. - MPLS/GMPLS migration moderate size. - Second slide shows recent new topics. Maybe take on new items. - Signaling Issues: - Routing issues - GMPLS OAM requirements. Alex: These items are also important Kireeti: Should look at pipelining work as we already started first slide. It all depends on how long it takes to do charter. We have been waiting now for more than a year Alex: Can prioritize and identify if can spin off work to a new, separate working group. Just like Layer 1 VPN that uses GMPLS. Take out other lumps and put in other WGs? Chairs should identify items. Adrian: We can discuss which could spin off, though we need to decide, and not delay, as many items are already being worked on. Bijan Jabbari: When I look at what is being implemented by vendors there is a mismatch with what this group is doing. Perhaps should look at short term. Alex: Yes my thoughts should look at 1 year to 2 years. Bijan: Not really clear what is being implemented Bijan: I work with Academia and industry, and the answer is not clear. You see implementations but you don't see deployments. Business reasons etc. New way of thinking that takes time. Alex: When go for standard track, do need implementation Kireeti: Also need deployments, and that takes time JP: Regarding the item on "input to PCE requirements". Not sure if need this input Adrian: Explain history is that CCAMP made a commitment to assist PCE Could agree to remove this commitment Alex: Yes we should discuss more in both groups. Don't want to make commitment to remove this before discussing it. If we have consensus maybe we don't need the document. JP: On advertisement of TE/GMPLS capabilities, we have implemented and deployed in 5 large service providers, so would like to expedite this Lou: Slide Back to Slide3: For the item on charter - missing is ASON. What do we do about alignment, and that we have two versions of RSVP? There is only one version of GMPLS, what do we need to do? What steps that we need to take as a WG? Alex: ASON is on our charter Lou: It's on charter - we have completed our documents. We can send to SG15, but what do we do from there to align GMPLS and ASON solutions? Adrian: Added it to slides Richard: On recent new topics - do we know what is in-charter currently? Alex: It is up to chairs: Adrian: If it is in the scope of the charter, we will do milestones There will be discussion on the list. Dimitri: Why is "deployment considerations" considered marginal? If you want feedback, how can this be classified as marginal? Please prioritize and please discuss. Adrian: This is from the community view gathered on the list last year Dimitri: Then how will we have deployment Kireeti: You can do canvassing to get people to discuss. We will take back to the list to do a poll again ------------------ ------------------ 12) GMPLS for Ethernet - Dimitri Papadimitriou Reviewed slides Define a set of scenarios: 4 Scenarios -Aggregation -Metro -Unified? Core -Transport Dimitri asked if interest to do this work ------------------ Don Fedyk: We still don't know what is actually meant by GMPLS Ethernet. The document does not go far enough today with enough detail. The document is too open ended and we don't know what exactly is being specified. I asked for more detailed specification. Dimitri: Ali Sajassi: Ethernet differs from other data planes as it's not point to point. Do you want to keep it as in the perspective of IEEE? Other comments: you want to replace existing Ethernet control plane with GMPLS: again how will you do multipoint? Shortest path may overlap with issues discussed in TRILL. How are you going to coordinate with other WGs? Loa: Not speaking for the DT as we didn't discuss it: I have experience running a medium/large scale Ethernet network as a point-to-point network (unified/core). It would be very applicable to add a gmpls control plane. Note that if we can't do it as a standard we (deployers) will do it ourselves. It is pretty straight forward. Ali: I can see for point to point, it's for multipoint that I see it will have issues Dimitri: OK. Can you input specifics? This said these questions are relevant but the scope (of the document) has been restricted to point-to-point. The issues on how we coordinate and potentially overlap with other working groups must also be addressed (implicitly: if we decide to move forward with this item.) Richard Spencer: Can you confirm that using GMPLS in enterprise is out of scope? Dimitri: As no one has expressed interest I would say it is out of scope Richard S: Will there be any changes to Ethernet control/data plane? What would be the potential difficulties? Have a discussion with the IEEE and see where they would be impacted. Dimitri: I can not say what will be the solution chosen, we already suggested we work with IEEE to assess impact Richard S: I see little value for aggregation. I don't see in metro why a provider would want to use this instead of VPLS Dimitri: I have replied to some of the issues you are currently raising on the list. If further clarification required we should discuss them on the list. Kireeti: We will not change the Ethernet data plane here. If we conclude it may need to be changed, we will liaise to IEEE and get their agreement. CCAMP is focused on core tunneling technologies, though we don't say how you will use them - metro or core - I would like us to continue not to be specific for access or core. If there is anything specifically different for access, then need to add to charter. Lyndon: There is a lot of interest in other groups (ITU, OIF, MEF). I think there is interest. Where people are uncertain is how. Need to look at more on supporting pt to pt or multipt. Don O'Conner: How does this differ from l2vpn? Dimitri: As explained in the introduction of the problem statement document it differs from the forwarding which is not based on packet header (as in MPLS) but based on the Layer-2 frame header. Kireeti: L2VPON charter is different. L2VPN sets up vpns. This work is on signaling and routing in Ethernet networks. Tom Nadeau: Is this in the scope of CCAMP today? Adrian: Yes this is in the scope as a core network. GMPLS handles packet transport networks. Maybe this is could be a new working group. Note, however, that changes to the data plane are not in scope for CCAMP and would require action by other SDOs, in this case IEEE. Tom: Seems similar to TRILL. Adrian: Yes. Need to determine if there is overlap. Perhaps this work should go there. Alternatively, perhaps this work goes in a new WG. Dimitri: Some of these items such as the difference with TRILL have been discussed on the mailing list. Loa: Trill is in campus networks. Alex: For structuring this work, we need to be very clear what data path modifications need to be done. Should communicate with IEEE liaison, preferably before BOF. TRILL working group is a specific example. Dimitri: What would be the way to contact the IEEE to do this? Is there a liaison with IEEE that we can make use of? Alex: We have an established liaison relationship with IEEE. Dimitri: OK, we will enter in contact with the liaison representative. Kireeti: First need to decide if we need a change in the data plane. Then talk to the IEEE. Adrian: Also need to tell IEEE what we plan to do, no matter how we do it. Smith: There are limits to the use of VLAN-ID. There are only 4K of them. Will you use this as the label? Adrian: We haven't decided anything about how forwarding will occur yet Dinesh Mohan: I haven't heard yet that there is planned a change to the data plane. Need to understand better. Should look at this as a new control plane using existing data plane. It would be nice to have the GMPLS Control plane but is there no intent to change the control plane? The basic assumption is that you have a different control plane then that should be the assumption. This is fine to explore, but the starting point is not to modify the data plane. Adrian: When we control SDH we did not mess with the data plane. We should not be modifying the transport technology. Monique Morrow: Echo what Alex said, any modification we need to talk to the IEEE. Dimitri: OK, but we are not talking in the context that there is a change to data plane. Ali: Trill and this are using ISIS. Trill plan to change the data plane. Kireeti: Please stop, take to list. Ali: Several vendors offer Ethernet switches that offer point to point using MPLS control plane supporting millions of connections. Yakov: How? Could you tell me whether they carry a label? Ali: Yes. They are MPLS switches Yakov: So it is a router, an LSR , that you can call an Ethernet switch and you are done? Adrian: That is indeed a suggestion. Don O'C: Ethernet is connectionless and now GMPLS is connection- oriented, so this is different. This is redefining Ethernet to make it connection oriented. Is that the intent? Is this making VLAN tags look like GMPLS labels? Adrian: Again, this has not been discussed Loa: From experience, we don't want to remove VLAN tags. Need something else. And the chairs said to the design team not to do that, yet 80% of CCAMP are already assuming this is what we want to do. Adrian: Design team job is done - Thanks. We need now for the WG to discuss. ------------------ Time is over. Other drafts that we didn't get to discuss, take to list. From HankFowler@yfbj.com Fri Aug 12 00:36:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3RH1-0005zc-Jx for ccamp-archive@megatron.ietf.org; Fri, 12 Aug 2005 00:36:05 -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 AAA17950 for ; Fri, 12 Aug 2005 00:35:52 -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 1E3RpK-00043E-8Q for ccamp-archive@ietf.org; Fri, 12 Aug 2005 01:11:32 -0400 Received: from cm222-166-136-121.hkcable.com.hk ([222.166.136.121]) by mx2.foretec.com with smtp (Exim 4.24) id 1E3RGi-0002oo-Ip for ccamp-archive@ietf.org; Fri, 12 Aug 2005 00:35:47 -0400 Received: from YeD@localhost by uiJ.int (8.11.6/8.11.6); Fri, 12 Aug 2005 00:27:57 -0200 Message-ID: From: "Lindsay Perle" Reply-To: "Lindsay Perle" To: ccamp-archive@ietf.org Subject: MS Office 2003 Pro $69.95 Macromedia Date: Thu, 11 Aug 2005 22:29:57 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: HankFowler@yfbj.com Content-Type: multipart/mixed; boundary="--71vVFPT7qNeUdO5G" X-Spam-Score: 1.3 (+) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 HIP ----71vVFPT7qNeUdO5G Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 2
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: SW45Pam
 

Sales Ra= nk: #1
System requirements  |  = Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Rev= iew:3D"5 Based on 1694 reviews. Wr= ite a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: wsGYJi8u
 =

Sales Rank: #2
System requirements = ; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 19828= 1 reviews. Write a review.

<= p>Microsoft Windows XP Professional or Longhorn Edition
Microsoft<= img border=3D0 src=3Dhttp://g-images.amazon.com/images/G/01/promotions/sti= cker/newest_version.gif width=3D82 height=3D14>

Choose:
 

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



Ava= ilability: Available for INSTANT download!
Coupon Code: 7UC= Pfefg
 

Sales Rank: #3
System requi= rements  |  Other Versions=
Date Coupon Expires: August 31st= , 2005
Average Customer Review:3D"5 Based on 18239 reviews. Write a revie= w.

Adobe Acrobat Professional V 7.0
= Adobe

Choose:
&nbs= p;

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: nkLVnq
 

Sales Rank: #4
System requirements  = |  Other Versions
Date Coupon Expires: August 31st, 2005
= Average Customer Review:3D"= Based on 1567 r= eviews. Write a review.

<= /font>

----71vVFPT7qNeUdO5G-- From owner-ccamp@ops.ietf.org Fri Aug 12 06:58:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3XEg-0000aS-5R for ccamp-archive@megatron.ietf.org; Fri, 12 Aug 2005 06:58: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 GAA15959 for ; Fri, 12 Aug 2005 06:57:58 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3XnA-0005M8-Gq for ccamp-archive@ietf.org; Fri, 12 Aug 2005 07:33:41 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3X4T-000Ivd-HO for ccamp-data@psg.com; Fri, 12 Aug 2005 10:47:29 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3X4S-000IvI-Ob; Fri, 12 Aug 2005 10:47:28 +0000 Received: from du-069-0304.access.clara.net ([217.158.145.50] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E3X4O-000PC9-7B; Fri, 12 Aug 2005 11:47:25 +0100 Message-ID: <0c8201c59f2b$981350e0$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "'Kireeti Kompella'" , , "Bill Fenner" , , "Lam, Hing-Kam \(Kam\)" Subject: Liaison to SG15 on RFC 4139 Date: Fri, 12 Aug 2005 11:46:46 +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: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit To: ITU-T Study Group 15 From: IETF CCAMP Working Group Subject: New Request for Comment Published For: Information The CCAMP Working Group of the IETF wishes to inform Study Group 15 of the ITU-T of the publication of a new Request for Comment. RFC 4139 "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)" is available at http://www.ietf.org/rfc/rfc4139.txt The Abstract of this RFC reads as follows. The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signaling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for the GMPLS signaling protocol to support the ASON functionality. The CCAMP Working Group would like to thank the members and Questions of Study Group 15 for the helpful input and review feedback that they provided while this document was being developed. The CCAMP Working Group continues to actively pursue protocol solutions for the ASON model and seeks to harmonise GMPLS and ASON. We will keep you informed of our future progress. Regards, Adrian Farrel and Kireeti Kompella CCAMP Working Group Co-chairs From owner-ccamp@ops.ietf.org Fri Aug 12 07:57:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3YAK-0003kp-O1 for ccamp-archive@megatron.ietf.org; Fri, 12 Aug 2005 07:57: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 HAA17638 for ; Fri, 12 Aug 2005 07:57:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Yil-0006kV-Av for ccamp-archive@ietf.org; Fri, 12 Aug 2005 08:33:16 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3Y53-000Nw9-M3 for ccamp-data@psg.com; Fri, 12 Aug 2005 11:52:09 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3Y51-000Nvq-Dh for ccamp@ops.ietf.org; Fri, 12 Aug 2005 11:52:07 +0000 Received: from du-069-0318.access.clara.net ([217.158.145.64] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E3Y4y-000Oc5-8u; Fri, 12 Aug 2005 12:52:06 +0100 Message-ID: <0cc301c59f34$a11aefa0$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lou Berger" , "Dimitri Papadimitriou" , "Reshad Rahman" , "Anca Zamfir" , "Junaid Israr" , "Arun Satyanarayana \(asatyana\)" References: <42E30C19.1010300@cisco.com> Subject: Short additional working group last call on draft-ietf-ccamp-rsvp-restart-ext-03.txt Date: Fri, 12 Aug 2005 12:29: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: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Hi, As mentioned by Arun in his email (below), draft-ietf-ccamp-rsvp-restart-ext-03.txt has been marked up after working group last call. At the same time, the authors made a minor functional change to the protocol extensions to handle a potential scaling issue. This email starts a short, additional working group last call on the I-D. Since the draft has already been through last call, I expect you to focus on the new material only. The last call will end on Sunday 21st August at 12 noon GMT. Thanks, Adrian ----- Original Message ----- From: "Arun Satyanarayana" To: ; "Adrian Farrel" ; "Kireeti Kompella" Cc: "Lou Berger" ; "Dimitri Papadimitriou" ; "Reshad Rahman" ; "Anca Zamfir" ; "Junaid Israr" ; "Arun Satyanarayana (asatyana)" Sent: Sunday, July 24, 2005 4:33 AM Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-03.txt > Hi all, > > Version -03 is the updated version resulting from last-call comments. > > A scalability concern was raised, where, the restarting node does not > support the mechanism in this I-D, but, one or more RSVP neighbors do. > This would result in unnecessary generation (and possible > retransmission) of RecoveryPath msgs by the neighbors, and, receive > processing of the RecoveryPath msg until the restarting node has to > decide to drop it. This may be a scalability issue when a large number > of LSPs are active on the restarting node. > > The solution is to indicate the capability to transmit and receive > RecoveryPath msgs with 2 new bits in the Capability object. > > Note: The above solution also addresses a similar concern raised > earlier, where, the restarting node support the extensions but one or > more of its neighbors do not. The restarting node would have to wait > until the end of the Recovery Period to revert to restart processing per > RFC3473. With an explicit advertisement of RecoveryPath capability, this > requirement no longer exists. From owner-ccamp@ops.ietf.org Fri Aug 12 11:50:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bo6-0007t8-Vv for ccamp-archive@megatron.ietf.org; Fri, 12 Aug 2005 11:50: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 LAA02230 for ; Fri, 12 Aug 2005 11:50:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3cMd-0005Uj-TZ for ccamp-archive@ietf.org; Fri, 12 Aug 2005 12:26:37 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3beD-000Gdp-47 for ccamp-data@psg.com; Fri, 12 Aug 2005 15:40:41 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3beC-000Gdb-8h for ccamp@ops.ietf.org; Fri, 12 Aug 2005 15:40:40 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 12 Aug 2005 08:40:40 -0700 X-IronPort-AV: i="3.96,103,1122879600"; d="scan'208"; a="654575973:sNHT28524520" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7CFeIp6018086; Fri, 12 Aug 2005 08:40:37 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 11:40:36 -0400 Received: from [161.44.70.216] ([161.44.70.216]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 11:40:36 -0400 Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: pce@ietf.org Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: PCE Requirement in CCAMP Date: Fri, 12 Aug 2005 11:41:06 -0400 To: ccamp@ops.ietf.org X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 12 Aug 2005 15:40:36.0715 (UTC) FILETIME=[2F280BB0:01C59F54] 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Dear WG, CCAMP proposed to work on GMPLS requirements for PCE as necessary. Considering the work which has been done by the PCE WG on requirements, it looks now more natural to move this work exclusively to the PCE WG. That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP, any requirements for PCE-based Inter-domain LSP computation should be discussed in the PCE WG *with* the review of the CCAMP WG. Similarly, non-packet networks may result in specific additional requirements for PCE. We propose that these requirements are also raised within the PCE working group and reviewed by CCAMP. Let us know if you have any opinion on or objection to these proposals. JP and Adrian (wearing PCE chair hat) From owner-ccamp@ops.ietf.org Fri Aug 12 12:20:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cGw-0000QR-79 for ccamp-archive@megatron.ietf.org; Fri, 12 Aug 2005 12:20: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 MAA04082 for ; Fri, 12 Aug 2005 12:20:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3cpT-0006P9-Bp for ccamp-archive@ietf.org; Fri, 12 Aug 2005 12:56:24 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3cC3-000JZc-NH for ccamp-data@psg.com; Fri, 12 Aug 2005 16:15:39 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3cC2-000JZN-V1; Fri, 12 Aug 2005 16:15:39 +0000 Message-ID: <42FCCB29.8060309@psg.com> Date: Fri, 12 Aug 2005 18:15:37 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: JP Vasseur CC: ccamp@ops.ietf.org, pce@ietf.org Subject: Re: PCE Requirement in CCAMP 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit hi jp, adrian it depends on the perspective, as such this document is meant to address the following item of the charter (last part) "- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models." therefore, it was my understanding that the PCE WG would be waiting for the need wrt signaling for detailing its applicability; you (and adrian) seems to say we will define the requirement for PCE-based inter-domain path computation and resulting signaling behaviour/mechanisms would then need to be adapted in CCAMP in brief, with your proposal PCE WG would be entering into a mode where the computational capabilities are going to drive LSP signaling itself, as an analogy RSVP-TE operations are decoupled from the routing topology; so here, the same relationship should be kept with respect to the computational scope/capabilities and behaviour of PCE(s) thanks, - dimitri. JP Vasseur wrote: > Dear WG, > > CCAMP proposed to work on GMPLS requirements for PCE as necessary. > > Considering the work which has been done by the PCE WG on requirements, it > looks now more natural to move this work exclusively to the PCE WG. > > That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP, > any requirements for PCE-based Inter-domain LSP computation should be > discussed in the PCE WG *with* the review of the CCAMP WG. > > Similarly, non-packet networks may result in specific additional > requirements for PCE. We propose that these requirements are also raised > within the PCE working group and reviewed by CCAMP. > > Let us know if you have any opinion on or objection to these proposals. > > JP and Adrian (wearing PCE chair hat) > > > . > From owner-ccamp@ops.ietf.org Fri Aug 12 14:12:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3e16-0004tm-Tq for ccamp-archive@megatron.ietf.org; Fri, 12 Aug 2005 14:12: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 OAA08693 for ; Fri, 12 Aug 2005 14:12:27 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3eZg-0000rX-2h for ccamp-archive@ietf.org; Fri, 12 Aug 2005 14:48:12 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3dvE-0002HU-V9 for ccamp-data@psg.com; Fri, 12 Aug 2005 18:06:24 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3dvD-0002H8-QT; Fri, 12 Aug 2005 18:06:24 +0000 Received: from du-069-0154.access.clara.net ([217.158.132.154] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E3dvA-000Bnf-90; Fri, 12 Aug 2005 19:06:22 +0100 Message-ID: <0d4c01c59f68$ea4b5d70$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , "JP Vasseur" Cc: , References: <42FCCB29.8060309@psg.com> Subject: Re: PCE Requirement in CCAMP Date: Fri, 12 Aug 2005 19:08:56 +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: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Hi Dimitri, > it depends on the perspective, as such this document is meant to address > the following item of the charter (last part) > > "- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > signaling (RSVP-TE) extensions required to support PCE-based path > computation models." No, it is not meant to address that part of the charter. That item remains unchanged by this discussion. JP's email is clearly specific to the documentation of requirements for PCE placed by the GMPLS protocols and non-packet networks under the control of GMPLS protocols. Our proposal is to develop all requirements for PCE within the PCE working group with review by the appropriate external working group. In practice, this only a small change since it is likely to be the same people involved in the work. It is, however, a formal change in CCAMP which previously had a commitment to work on these requirements. > therefore, it was my understanding that the PCE WG would be waiting for > the need wrt signaling for detailing its applicability; you (and adrian) > seems to say we will define the requirement for PCE-based inter-domain > path computation and resulting signaling behaviour/mechanisms would then > need to be adapted in CCAMP > > in brief, with your proposal PCE WG would be entering into a mode where > the computational capabilities are going to drive LSP signaling itself, > as an analogy RSVP-TE operations are decoupled from the routing > topology; so here, the same relationship should be kept with respect to > the computational scope/capabilities and behaviour of PCE(s) If you are objecting to the specific item on the PCE charter then now may be a little late, but let me explain the sort of thing that the charter item is intended to cover by giving a couple of examples. - PCE discovery may be achieved through the presence of information withing IGP advertisements. This would require changes to the IGPs and such changes MUST be reviewed by the appropriate WGs. - The use of a fully computed path that crosses multiple domains raises confidentiality issues. These issues can be solved by inserting new sub-objects into an RSVP-TE Explicit Route object (for example a cookie and PCE ID, or an encrypted hop). The normal way in which such small protocol changes are made (witness GMPLS additions to the IGPs) is either: a. An I-D is written and taken to the "owning" WG b. An I-D is written in the WG that needs the solutions and is reviewed in the "owning" WG. This process is usually refered to as "cooperation between WGs". The PCE charter proposes business as usual. Thanks, Adrian > > Dear WG, > > > > CCAMP proposed to work on GMPLS requirements for PCE as necessary. > > > > Considering the work which has been done by the PCE WG on requirements, it > > looks now more natural to move this work exclusively to the PCE WG. > > > > That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP, > > any requirements for PCE-based Inter-domain LSP computation should be > > discussed in the PCE WG *with* the review of the CCAMP WG. > > > > Similarly, non-packet networks may result in specific additional > > requirements for PCE. We propose that these requirements are also raised > > within the PCE working group and reviewed by CCAMP. > > > > Let us know if you have any opinion on or objection to these proposals. > > > > JP and Adrian (wearing PCE chair hat) > > > > > > . > > > > > From owner-ccamp@ops.ietf.org Fri Aug 12 15:05:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3eq9-0005z0-8Y for ccamp-archive@megatron.ietf.org; Fri, 12 Aug 2005 15:05:13 -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 PAA12161 for ; Fri, 12 Aug 2005 15:05:11 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3fOi-0002Yt-PL for ccamp-archive@ietf.org; Fri, 12 Aug 2005 15:40:57 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3eko-0006Ac-QV for ccamp-data@psg.com; Fri, 12 Aug 2005 18:59:42 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3ekn-0006AD-8K; Fri, 12 Aug 2005 18:59:42 +0000 Message-ID: <42FCF19B.2010007@psg.com> Date: Fri, 12 Aug 2005 20:59:39 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: dimitri.papadimitriou@alcatel.be, JP Vasseur , ccamp@ops.ietf.org, pce@ietf.org Subject: Re: PCE Requirement in CCAMP References: <42FCCB29.8060309@psg.com> <0d4c01c59f68$ea4b5d70$08849ed9@Puppy> In-Reply-To: <0d4c01c59f68$ea4b5d70$08849ed9@Puppy> 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit hi adrian i perfectly understand the need from the PCE perspective but that's not the real question (even if one might question under which charter item this work would be initiated - something not clear to me from your reply here below) the real issue is that with such proposal PCE WG would be entering into a mode where the computational capabilities are going to drive LSP signaling itself - please note here the difference with the discovery process through IGP extensions that is going to be put in place - but the impact of the global PCE architecture on the independence wrt path computation of the RSVP-TE protocol; hence, i always thought that the CCAMP WG would have initially provided "guidelines" to the PCE WG before such work would start in the PCE WG i hope you see that the issue is not about the "owning WG" or the "reviewing WG" or their cooperation but the need to know more about the acceptable level of integration/cooperation of the PCE architecture with the operations on signaling LSP before deciding from where the wind will come from hope this clarifies (at least a bit), - dimitri. Adrian Farrel wrote: > Hi Dimitri, > > >>it depends on the perspective, as such this document is meant to address >>the following item of the charter (last part) >> >>"- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, >>MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP >>signaling (RSVP-TE) extensions required to support PCE-based path >>computation models." > > > No, it is not meant to address that part of the charter. That item remains > unchanged by this discussion. > > JP's email is clearly specific to the documentation of requirements for > PCE placed by the GMPLS protocols and non-packet networks under the > control of GMPLS protocols. > > Our proposal is to develop all requirements for PCE within the PCE working > group with review by the appropriate external working group. > > In practice, this only a small change since it is likely to be the same > people involved in the work. It is, however, a formal change in CCAMP > which previously had a commitment to work on these requirements. > > >>therefore, it was my understanding that the PCE WG would be waiting for >>the need wrt signaling for detailing its applicability; you (and adrian) >>seems to say we will define the requirement for PCE-based inter-domain >>path computation and resulting signaling behaviour/mechanisms would then >>need to be adapted in CCAMP >> >>in brief, with your proposal PCE WG would be entering into a mode where >>the computational capabilities are going to drive LSP signaling itself, >>as an analogy RSVP-TE operations are decoupled from the routing >>topology; so here, the same relationship should be kept with respect to >>the computational scope/capabilities and behaviour of PCE(s) > > > If you are objecting to the specific item on the PCE charter then now may > be a little late, but let me explain the sort of thing that the charter > item is intended to cover by giving a couple of examples. > > - PCE discovery may be achieved through the presence of > information withing IGP advertisements. This would require changes > to the IGPs and such changes MUST be reviewed by the > appropriate WGs. > > - The use of a fully computed path that crosses multiple domains > raises confidentiality issues. These issues can be solved by > inserting new sub-objects into an RSVP-TE Explicit Route > object (for example a cookie and PCE ID, or an encrypted > hop). > > The normal way in which such small protocol changes are made (witness > GMPLS additions to the IGPs) is either: > a. An I-D is written and taken to the "owning" WG > b. An I-D is written in the WG that needs the solutions and > is reviewed in the "owning" WG. > This process is usually refered to as "cooperation between WGs". > The PCE charter proposes business as usual. > > Thanks, > Adrian > > > >>>Dear WG, >>> >>>CCAMP proposed to work on GMPLS requirements for PCE as necessary. >>> >>>Considering the work which has been done by the PCE WG on > > requirements, it > >>>looks now more natural to move this work exclusively to the PCE WG. >>> >>>That said, since Inter-domain (G)MPLS TE falls under the scope of > > CCAMP, > >>>any requirements for PCE-based Inter-domain LSP computation should be >>>discussed in the PCE WG *with* the review of the CCAMP WG. >>> >>>Similarly, non-packet networks may result in specific additional >>>requirements for PCE. We propose that these requirements are also > > raised > >>>within the PCE working group and reviewed by CCAMP. >>> >>>Let us know if you have any opinion on or objection to these > > proposals. > >>>JP and Adrian (wearing PCE chair hat) >>> >>> >>>. >>> >> >> >> > > > > . > From owner-ccamp@ops.ietf.org Sat Aug 13 10:44:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3xFE-0004TO-SE for ccamp-archive@megatron.ietf.org; Sat, 13 Aug 2005 10:44:20 -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 KAA25299 for ; Sat, 13 Aug 2005 10:44:19 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3xny-0008My-NC for ccamp-archive@ietf.org; Sat, 13 Aug 2005 11:20:15 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3x8D-000CDz-AE for ccamp-data@psg.com; Sat, 13 Aug 2005 14:37:05 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3x8A-000CDf-Rk; Sat, 13 Aug 2005 14:37:03 +0000 Received: from du-069-0107.access.clara.net ([217.158.132.107] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E3x81-000627-E1; Sat, 13 Aug 2005 15:37:01 +0100 Message-ID: <0dd501c5a014$d27d8a40$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: , "JP Vasseur" , , References: <42FCCB29.8060309@psg.com> <0d4c01c59f68$ea4b5d70$08849ed9@Puppy> <42FCF19B.2010007@psg.com> Subject: Re: PCE Requirement in CCAMP Date: Sat, 13 Aug 2005 15:34:52 +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: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: 7bit Hi Dimitri, GMPLS and non-packet requirements for PCE are likely to include the specification of protection types, switching types, encoding types, optical constraints, and so forth. While you could argue that CCAMP has best knowledge of these items, it does not seem to me to matter if the corresponding requirements I-D (that describes what constraints PCE must be able to receive and satisfy) is developed in the PCE working group. The question that JP's email asks is: "Is it OK with the CCAMP WG if that requirements I-D is developed in the PCE WG with review from the CCAMP WG?" If we can answer this question in isolation of your other point, this would be helpful. We can then move on to discuss you other point as follows... While I understand your concern (that the computational architecture should not force signaling behavior) I do not believe that it can be addressed by limiting the discussion to the CCAMP working group. It is clear that the PCE working group is responsible for the PCE architecture and should suggest applicability to specific environments including multi-domain MPLS-TE and GMPLS. The questions then arise: if the application of PCE to a specific environment requires additions to the MPLS-TE or GMPLS signaling protocols: 1. which working group should decide that the applicability of PCE in this environment is valid? 2. which working group should identify the requirement for these protocol extensions? 3. which working group should validate the requirements for these protocol extensions? 4. which working group should develop the protocol extensions? 5. which working group should review the protocol extensions? *My* answers to these questions are: 1 PCE and CCAMP 2 PCE 3 CCAMP 4 PCE 5 CCAMP My reasoning is: - the purpose of PCE is to do this work - CCAMP cannot (and should not) do everything - CCAMP must keep "supervision" of protocol extensions I would like to hear other people's opinion on both issues - that raised by JP and that raised by Dimitri. Thanks, Adrian ----- Original Message ----- From: "dimitri papadimitriou" To: "Adrian Farrel" Cc: ; "JP Vasseur" ; ; Sent: Friday, August 12, 2005 7:59 PM Subject: Re: PCE Requirement in CCAMP > hi adrian > > i perfectly understand the need from the PCE perspective but that's not > the real question (even if one might question under which charter item > this work would be initiated - something not clear to me from your reply > here below) > > the real issue is that with such proposal PCE WG would be entering into > a mode where the computational capabilities are going to drive LSP > signaling itself - please note here the difference with the discovery > process through IGP extensions that is going to be put in place - but > the impact of the global PCE architecture on the independence wrt path > computation of the RSVP-TE protocol; hence, i always thought that the > CCAMP WG would have initially provided "guidelines" to the PCE WG before > such work would start in the PCE WG > > i hope you see that the issue is not about the "owning WG" or the > "reviewing WG" or their cooperation but the need to know more about the > acceptable level of integration/cooperation of the PCE architecture with > the operations on signaling LSP before deciding from where the wind will > come from > > hope this clarifies (at least a bit), > - dimitri. > > Adrian Farrel wrote: > > > Hi Dimitri, > > > > > >>it depends on the perspective, as such this document is meant to address > >>the following item of the charter (last part) > >> > >>"- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > >>MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > >>signaling (RSVP-TE) extensions required to support PCE-based path > >>computation models." > > > > > > No, it is not meant to address that part of the charter. That item remains > > unchanged by this discussion. > > > > JP's email is clearly specific to the documentation of requirements for > > PCE placed by the GMPLS protocols and non-packet networks under the > > control of GMPLS protocols. > > > > Our proposal is to develop all requirements for PCE within the PCE working > > group with review by the appropriate external working group. > > > > In practice, this only a small change since it is likely to be the same > > people involved in the work. It is, however, a formal change in CCAMP > > which previously had a commitment to work on these requirements. > > > > > >>therefore, it was my understanding that the PCE WG would be waiting for > >>the need wrt signaling for detailing its applicability; you (and adrian) > >>seems to say we will define the requirement for PCE-based inter-domain > >>path computation and resulting signaling behaviour/mechanisms would then > >>need to be adapted in CCAMP > >> > >>in brief, with your proposal PCE WG would be entering into a mode where > >>the computational capabilities are going to drive LSP signaling itself, > >>as an analogy RSVP-TE operations are decoupled from the routing > >>topology; so here, the same relationship should be kept with respect to > >>the computational scope/capabilities and behaviour of PCE(s) > > > > > > If you are objecting to the specific item on the PCE charter then now may > > be a little late, but let me explain the sort of thing that the charter > > item is intended to cover by giving a couple of examples. > > > > - PCE discovery may be achieved through the presence of > > information withing IGP advertisements. This would require changes > > to the IGPs and such changes MUST be reviewed by the > > appropriate WGs. > > > > - The use of a fully computed path that crosses multiple domains > > raises confidentiality issues. These issues can be solved by > > inserting new sub-objects into an RSVP-TE Explicit Route > > object (for example a cookie and PCE ID, or an encrypted > > hop). > > > > The normal way in which such small protocol changes are made (witness > > GMPLS additions to the IGPs) is either: > > a. An I-D is written and taken to the "owning" WG > > b. An I-D is written in the WG that needs the solutions and > > is reviewed in the "owning" WG. > > This process is usually refered to as "cooperation between WGs". > > The PCE charter proposes business as usual. > > > > Thanks, > > Adrian > > > > > > > >>>Dear WG, > >>> > >>>CCAMP proposed to work on GMPLS requirements for PCE as necessary. > >>> > >>>Considering the work which has been done by the PCE WG on > > > > requirements, it > > > >>>looks now more natural to move this work exclusively to the PCE WG. > >>> > >>>That said, since Inter-domain (G)MPLS TE falls under the scope of > > > > CCAMP, > > > >>>any requirements for PCE-based Inter-domain LSP computation should be > >>>discussed in the PCE WG *with* the review of the CCAMP WG. > >>> > >>>Similarly, non-packet networks may result in specific additional > >>>requirements for PCE. We propose that these requirements are also > > > > raised > > > >>>within the PCE working group and reviewed by CCAMP. > >>> > >>>Let us know if you have any opinion on or objection to these > > > > proposals. > > > >>>JP and Adrian (wearing PCE chair hat) > >>> > >>> > >>>. > >>> > >> > >> > >> > > > > > > > > . > > > > > From owner-ccamp@ops.ietf.org Tue Aug 16 07:41:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4zod-0005sB-0Y for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 07:41: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 HAA04341 for ; Tue, 16 Aug 2005 07:41:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E50Nx-0006cF-2r for ccamp-archive@ietf.org; Tue, 16 Aug 2005 08:17:41 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E4zfG-0008ey-LE for ccamp-data@psg.com; Tue, 16 Aug 2005 11:31:30 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E4zfF-0008ec-13; Tue, 16 Aug 2005 11:31:29 +0000 Received: from du-069-0105.access.clara.net ([217.158.132.105] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E4zf5-000PHi-6c; Tue, 16 Aug 2005 12:31:27 +0100 Message-ID: <00db01c5a256$6624ebb0$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "'Kireeti Kompella'" Subject: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 12:28:11 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00CE_01C5A25D.F741F3C0" 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,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 This is a multi-part message in MIME format. ------=_NextPart_000_00CE_01C5A25D.F741F3C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CF_01C5A25D.F741F3C0" ------=_NextPart_001_00CF_01C5A25D.F741F3C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please find attached a file that contains: - a set of proposed *draft* milestones - a discussion of why there are so many milestones - a high-level explanation of the work items. Note that this looks like a lot of milestones, but please read the text = on this issue in the attached file. The bottom line is that this is a = product of micro management where I have tried to identify all of the = I-Ds that we might produce to cover the referenced work, and where I = have placed two (sometimes three) milestones for each I-D. This micro-management may be over the top, and represents a full = pendulum swing from the previous style of CCAMP milestones, but in the = light of the hiatus of the last 12 months, i think this may be = beneficial and might achieve rapid forwards movement. I would welcome your (constructive!) comments. Notes: - Why isn't my I-D also cited as input material? No insult intended. The current list is simply there to show the ADs that work is already in progress. All I-Ds will be used as input. =20 - Why isn't my pet topic included? Are you sure it is not there between the lines? This=20 list of milestones isn't completely proscriptive. =20 The objective is to have the WG agreed on the milestones that it wants = to commit to by the end of August. Thanks, Adrian ------=_NextPart_001_00CF_01C5A25D.F741F3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

Please find attached a = file that=20 contains:

- a set of proposed *draft* milestones
- a = discussion of why=20 there are so many milestones
- a high-level explanation of the work=20 items.

Note that this looks like a lot of milestones, but please = read the=20 text on this issue in the attached file. The bottom line is that this is = a=20 product of micro management where I have tried to identify all of the = I-Ds that=20 we might produce to cover the referenced work, and where I have placed = two=20 (sometimes three) milestones for each I-D.

This micro-management = may be=20 over the top, and represents a full pendulum swing from the previous = style of=20 CCAMP milestones, but in the light of the hiatus of the last 12 months, = i think=20 this may be beneficial and might achieve rapid forwards = movement.

I would=20 welcome your (constructive!) comments.

Notes:
- Why isn't my = I-D also=20 cited as input material?
  No insult intended. The current list = is=20 simply there to
  show the ADs that work is already in progress. = All=20 I-Ds
  will be used as input.      =
- Why=20 isn't my pet topic included?
  Are you sure it is not = there between=20 the lines? This
  list of milestones isn't = completely=20 proscriptive.
 
The objective is to have the WG = agreed on the=20 milestones that it wants to commit to by the end of August.
 
Thanks,
Adrian
------=_NextPart_001_00CF_01C5A25D.F741F3C0-- ------=_NextPart_000_00CE_01C5A25D.F741F3C0 Content-Type: text/plain; name="ccamp-milestones.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ccamp-milestones.txt" Content-Transfer-Encoding: quoted-printable CCAMP Working Group - Rechartering Effort Below you will find - a list of proposed milestones - an explanation of why this is a long list - overview of proposed drafts and work items In reviewing this we should look for: - topics that are irrelevant or unwanted by the WG - topics that have been left out but are wanted by the WG - topics that have been assigned the wrong priority or urgency - topics or collections or topics that are sufficiently large to potentially warrant their own working group. Proposed New milestones ----------------------- Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS = and OSPF Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh = membership Nov 05 Submit ASON Routing evaluation I-D for IESG review Nov 05 First version of WG I-D on path computation implmentation advice Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in = ISIS and OSPF Nov 05 First version WG I-D MPLS to GMPLS migration strategies Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS Nov 05 First version WG I-D Change of LSP ownership between management = and control planes Dec 05 First version of WG I-D for ASON Routing solutions Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG = review Dec 05 Submit Per-domain path computation signaling I-D for IESG review Dec 05 First version WG I-D Requirements for Multi-Layer and = Multi-Region Networks Dec 05 First version WG I-D for Evaluation of existing protocols for = MLN/MRN Dec 05 First version WG I-D for Protocol solutions for MLN/MRN Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG = review Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module Jan 06 First version WG Informational I-D for Analysis of inter-domain = issues for disjoint and protected paths Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF = for IESG review Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and = solutions Jan 06 First version WG I-D GMPLS OAM Requirements Jan 06 First version WG I-D Routing and signaling for complex optical = constraints Feb 06 Submit LSP Stitching I-D for IESG review Mar 06 First version of WG informational I-D Aligning GMPLS protocols = across the standards bodies Mar 06 Submit GMPLS routing and signaling interoperability advice I-D = for IESG review Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module Mar 06 First version of WG I-D for additional MIB module to cover = RSVP-TE signaling extensions Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for = IESG review Jun 06 Submit Informational I-D for Analysis of inter-domain issues for = disjoint and protected paths for IESG review Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review Jun 06 Submit Change of LSP ownership between management and control = planes I-D for IESG review Aug 06 Submit path computation implmentation advice I-D for IESG review Oct 06 Submit ASON Routing solutions I-D for IESG review Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D = for IESG review Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG = review Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for = IESG review Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Dec 06 Submit GMPLS OAM Requirements I-D for IESG review Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor = and IESG review Oct 07 Submit Routing and signaling for complex optical constraints I-D = for IESG review Oct 07 Recharter or close Working Group Why so many milestons? ---------------------- The number of milestones shown in this proposed list far exceeds anything I have ever seen in a working group charter. This is intentional and while it does indicate a heavy work-load it also indicates a higher level of micro-management than is usual within working groups. Thus two milestones are presented for each I-D (adoption as a WG I-D, and passing to the IESG post-WG-last-call). This can be compared with the "normal" charter milestones which include a single work-related item that may span several I-Ds and refers vaguely only to the "submission" of I-Ds. In other words, reviewers of this list should not panic because of its length, but should see this as beneficial. Explanation of I-Ds and work items ---------------------------------- The following text briefly introduces the work items that are represented by the milestones listed above. In this text an astrix (*) indicates a milestone to be set. The work is divided into several categories according to how core it is and how it should be prioritized. Existing drafts are referenced to indicate that work is already in progress - this is not intended to provide a complete list of existing drafts. Completing existing work = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ASON - ASON Routing evaluation - already have draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt * submit for IESG review - ASON Routing solutions * first version of WG draft * submit for IESG review - GMPLS signaling in support of Call Management - already have draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt * submit for IESG review - GMPLS/ASON lexicography - already have draft-ietf-ccamp-gmpls-ason-lexicography-03.txt * submit for IESG review - Aligning GMPLS protocols across the standards bodies - Information I-D not intended for publication as an RFC * first version of WG draft Interoperability reports and advice - signaling and routing - already have draft-ietf-ccamp-gmpls-addressing-01.txt * submit for IESG review - path computation * first version of WG draft - based on draft-otani-ccamp-gmpls-cspf-constraints-01.txt * submit for IESG review Additional MIB modules - OSPF-TE * first version of WG draft - based on draft-otani-ccamp-gmpls-ospf-mib-00.txt * submit for IESG review - ISIS-TE * first version of WG draft * submit for IESG review - Signaling - Need "living" MIB module under development to catch the minor protocol extensions that have been made * first version of WG draft * submit for IESG review Inter-domain - LSP Stitching - already have draft-ietf-ccamp-lsp-stitching-01.txt * submit for IESG review - RSVP-TE extensions for interdomain - already have draft-ietf-ccamp-inter-domain-rsvp-te-01.txt * submit for IESG review - Per-domain path computation signaling - already have draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt * submit for IESG review - Analysis of inter-domain issues for disjoint and protected paths - Informational I-D to close off the topic and devolve to PCE * first version of WG draft * submit for IESG review New items already started and within existing charter = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Advertising TE Node Capabilities - ISIS and OSPF in the same I-D * first version of WG draft - based on draft-vasseur-ccamp-te-node-cap-00.txt * review by IGP working groups * submit for IESG review Automatic discovery of MPLS-TE mesh membership - depends on TE Node capabilities I-D * first version of WG draft - based on draft-vasseur-ccamp-automesh-00.txt * submit for IESG review Multi-layer networks (also multi-region networks) - Requirements * first version of WG draft - based on draft-shiomoto-ccamp-gmpls-mrn-reqs-02.txt * submit for IESG review - Evaluation of existing protocols * first version of WG draft - based on draft-leroux-ccamp-gmpls-mrn-eval-01.txt * submit for IESG review - Solutions * first version of WG draft - based on draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt * submit for IESG review MPLS-GMPLS interworking requirements and solutions * first version of WG draft - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt * submit for IESG review MPLS to GMPLS migration strategies * Informational I-D first version of WG draft - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt - material from = draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt * submit Informational I-D for IESG review Minor items just starting but close to heart of WG = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= GMPLS OAM Requirements - Interesting and worthwhile * first version of WG draft - based on immature = draft-nadeau-ccamp-gmpls-oam-requirements-00.txt * submit for IESG review Minor items just starting and important becuase of inter-SDO = interactions = =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=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 GMPLS coordination of VCAT and LCAS - single requirements and solutions draft almost an applicablity = statement * first version of WG draft - based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt * submit for IESG review Change of LSP ownership between management and control planes - single requirements and solutions draft defines one bit and a = procedure * first version of WG draft - based on draft-caviglia-mp2cpcp2mp-02.txt * submit for IESG review More forward-looking =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Routing and signaling for complex optical constraints * first version of WG draft - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt * submit for IESG review ------=_NextPart_000_00CE_01C5A25D.F741F3C0-- From ReynaReagan@exarchs.net Tue Aug 16 08:55:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E50y7-0008WS-SM for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 08:55: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 IAA08367 for ; Tue, 16 Aug 2005 08:55:01 -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 1E51XL-00005b-Fx for ccamp-archive@ietf.org; Tue, 16 Aug 2005 09:31:35 -0400 Received: from [221.127.8.19] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1E50xp-0005JX-By for ccamp-archive@ietf.org; Tue, 16 Aug 2005 08:54:45 -0400 Received: from NTZE@localhost by s0O.int (8.11.6/8.11.6); Tue, 16 Aug 2005 12:00:28 -0200 Message-ID: From: "Vonda Cline" Reply-To: "Vonda Cline" To: ccamp-archive@ietf.org Subject: Huge $avings on ALL best-selling Office XP titles Date: Tue, 16 Aug 2005 19:04:28 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: ReynaReagan@exarchs.net Content-Type: multipart/mixed; boundary="--567472481348319" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Jo1 ----567472481348319 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 9
Opt-in Email Special Offer   = ;  unsubscribe me
= =
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: 2P4ghgagm
 

Sales = Rank: #1
System requirements  |  Other Versions
Date Coupon Expires:= August 31st, 2005
Average Customer R= eview:3D"5 Based on 198248 reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 <= /td>

<= img height=3D150 src=3Dhttp://images.amazon.com/images/P/B00081I6JI.01._PE= 7_SCMZZZZZZZ_.jpg width=3D144 align=3Dleft border=3D0 name=3Dprod_image>

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: QrTB1IBx
 =

Sales Rank: #2
System requirements = ; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 1624 = reviews. Write a review.

=

= Microsoft Windows XP Professional or Longhorn Edition<= br> Microsoft

Choose:=
 

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



Availabi= lity: Available for INSTANT download!
Coupon Code: 9kC46  

Sales Rank: #3
System requirements<= /a>  |  Other Versions
Date Coupon Expires: August 31st, 2005 Average Customer Review:3D"5 Based= on 1984 reviews. Write a review.

Adobe Acrobat Professional V 7.0
= Adobe

=
Choose:
 = ;

=

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: wkTf4WZp9
 = ;

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 11949= reviews. Write a review.

=

<= /form> ----567472481348319-- From owner-ccamp@ops.ietf.org Tue Aug 16 10:44:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E52gH-0003Ez-1V for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 10:44: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 KAA15815 for ; Tue, 16 Aug 2005 10:44:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E53Fc-00036N-Rl for ccamp-archive@ietf.org; Tue, 16 Aug 2005 11:21:17 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E52Wa-000MuS-Ae for ccamp-data@psg.com; Tue, 16 Aug 2005 14:34:44 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E52WY-000MuE-2x for ccamp@ops.ietf.org; Tue, 16 Aug 2005 14:34:43 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 16 Aug 2005 07:34:06 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,111,1122879600"; d="scan'208,217"; a="6123821:sNHT68083116378" 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 j7GEY1T8008380; Tue, 16 Aug 2005 10:34:03 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 10:34:02 -0400 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_01C5A26F.8BA4FA1B" Subject: RE: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 10:34:00 -0400 Message-ID: Thread-Topic: Moving forward with the CCAMP charter Thread-Index: AcWiVstE/f8Ki9VCQe+ORuiO8XQAdgAGLSXQ From: "Zafar Ali \(zali\)" To: "Adrian Farrel" , Cc: , "Kireeti Kompella" X-OriginalArrivalTime: 16 Aug 2005 14:34:02.0233 (UTC) FILETIME=[8BE97690:01C5A26F] 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_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: 33cc095b503da4365ce57c727e553cf1 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A26F.8BA4FA1B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian,=20 =20 Graceful shutdown, a method for explicitly notifying a set of nodes that either a Link or an entire node will remove itself from the network or the protocol is going to be disabled for a link or a node, had good response when kireeti polled for charter updates some times back. We have been waiting for a charter update to move with this ID (draft-ali-ccamp-mpls-graceful-shutdown-xx.txt). I think got missed in your list. can you please include this work item in the milestone list as well.=20 =20 Thanks =20 Regards... Zafar =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, August 16, 2005 7:28 AM To: ccamp@ops.ietf.org Cc: zinin@psg.com; 'Kireeti Kompella' Subject: Moving forward with the CCAMP charter =09 =09 Hi, =09 Please find attached a file that contains: =09 - a set of proposed *draft* milestones - a discussion of why there are so many milestones - a high-level explanation of the work items. =09 Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. =09 This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. =09 I would welcome your (constructive!) comments. =09 Notes: - Why isn't my I-D also cited as input material? No insult intended. The current list is simply there to show the ADs that work is already in progress. All I-Ds will be used as input. =20 - Why isn't my pet topic included? Are you sure it is not there between the lines? This=20 list of milestones isn't completely proscriptive. =20 The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. =20 Thanks, Adrian ------_=_NextPart_001_01C5A26F.8BA4FA1B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
 
Graceful shutdown, a = method for=20 explicitly notifying a set of nodes that either a Link or an entire node = will=20 remove itself from the network or the protocol is going to be disabled = for a=20 link or a node, had good response when kireeti polled for charter updates = some times=20 back. We have been waiting for a charter update to move with this ID=20 (draft-ali-ccamp-mpls-graceful-shutdown-xx.txt). I think got missed=20 in your list. can you please include this work item in=20 the milestone list as well. 
 
Thanks
 
Regards... Zafar=20  

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian=20 Farrel
Sent: Tuesday, August 16, 2005 7:28 AM
To:=20 ccamp@ops.ietf.org
Cc: zinin@psg.com; 'Kireeti=20 Kompella'
Subject: Moving forward with the CCAMP=20 charter

Hi,

Please find attached a = file that=20 contains:

- a set of proposed *draft* milestones
- a = discussion of=20 why there are so many milestones
- a high-level explanation of the = work=20 items.

Note that this looks like a lot of milestones, but = please read=20 the text on this issue in the attached file. The bottom line is that = this is a=20 product of micro management where I have tried to identify all of the = I-Ds=20 that we might produce to cover the referenced work, and where I have = placed=20 two (sometimes three) milestones for each I-D.

This = micro-management=20 may be over the top, and represents a full pendulum swing from the = previous=20 style of CCAMP milestones, but in the light of the hiatus of the last = 12=20 months, i think this may be beneficial and might achieve rapid = forwards=20 movement.

I would welcome your (constructive!)=20 comments.

Notes:
- Why isn't my I-D also cited as input=20 material?
  No insult intended. The current list is simply = there=20 to
  show the ADs that work is already in progress. All = I-Ds
 =20 will be used as input.     
- Why isn't = my pet=20 topic included?
  Are you sure it is not = there=20 between the lines? This
  list of milestones isn't = completely=20 proscriptive.
 
The objective is to have the WG = agreed on the=20 milestones that it wants to commit to by the end of = August.
 
Thanks,
Adrian
------_=_NextPart_001_01C5A26F.8BA4FA1B-- From owner-ccamp@ops.ietf.org Tue Aug 16 11:45:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E53ca-0005s5-F7 for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 11:45:00 -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 LAA19020 for ; Tue, 16 Aug 2005 11:44:57 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E54Bt-0004dr-Sq for ccamp-archive@ietf.org; Tue, 16 Aug 2005 12:21:33 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E53Uf-0001iY-BT for ccamp-data@psg.com; Tue, 16 Aug 2005 15:36:49 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E53Ue-0001iK-IV for ccamp@ops.ietf.org; Tue, 16 Aug 2005 15:36:48 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 16 Aug 2005 08:36:42 -0700 X-IronPort-AV: i="3.96,111,1122879600"; d="scan'208,217"; a="332676449:sNHT44096230" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7GFaO0P017130; Tue, 16 Aug 2005 08:36:40 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 11:36:23 -0400 Received: from [192.168.1.102] ([10.86.242.36]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 11:36:23 -0400 In-Reply-To: <00db01c5a256$6624ebb0$4f849ed9@Puppy> References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v733) X-Priority: 3 Content-Type: multipart/alternative; boundary=Apple-Mail-54--129477393 Message-Id: <6A0BF8B4-577A-4AFC-8132-B086AC914C64@cisco.com> Cc: , , "'Kireeti Kompella'" From: JP Vasseur Subject: Re: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 11:36:50 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 16 Aug 2005 15:36:23.0208 (UTC) FILETIME=[41B4F280:01C5A278] 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_30_40, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.5 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 --Apple-Mail-54--129477393 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, Looks like a detailed, ambitious constructive action plan. Two comments: (1) Analysis of inter-domain issues for disjoint and protected paths - Informational I-D to close off the topic and devolve to PCE * first version of WG draft * submit for IESG review Could you briefly elaborate on this item ? (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful- shutdown, you may want to add draft-leroux-ccamp-ctrl- saturation-01.txt ? thanks. JP. On Aug 16, 2005, at 7:28 AM, Adrian Farrel wrote: > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the > text on this issue in the attached file. The bottom line is that > this is a product of micro management where I have tried to > identify all of the I-Ds that we might produce to cover the > referenced work, and where I have placed two (sometimes three) > milestones for each I-D. > > This micro-management may be over the top, and represents a full > pendulum swing from the previous style of CCAMP milestones, but in > the light of the hiatus of the last 12 months, i think this may be > beneficial and might achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it > wants to commit to by the end of August. > > Thanks, > Adrian > --Apple-Mail-54--129477393 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Adrian,

Looks like a detailed, = ambitious constructive action plan.

Two = comments:=A0

(1)=A0Analysis of = inter-domain issues for disjoint and protected paths
=A0 =A0 =A0= - Informational I-D to close off the topic and devolve to = PCE
=A0 =A0 =A0 * first version of WG draft
=A0 =A0 = =A0 * submit for IESG review

Could you briefly elaborate = on this item ?

(2)=A0May be in the same = bucket as draft-ali-ccamp-mpls-graceful-shutdown, you may want to = add=A0draft-leroux-ccamp-ctrl-saturation-01.txt ?

thanks.

JP.

O= n Aug 16, 2005, at 7:28 AM, Adrian Farrel wrote:

=
Hi,

Please find attached a = file that contains:

- a set of proposed *draft* milestones
- a = discussion of why there are so many milestones
- a high-level = explanation of the work items.

Note that this looks like a lot of = milestones, but please read the text on this issue in the attached file. = The bottom line is that this is a product of micro management where I = have tried to identify all of the I-Ds that we might produce to cover = the referenced work, and where I have placed two (sometimes three) = milestones for each I-D.

This micro-management may be over the = top, and represents a full pendulum swing from the previous style of = CCAMP milestones, but in the light of the hiatus of the last 12 months, = i think this may be beneficial and might achieve rapid forwards = movement.

I would welcome your (constructive!) = comments.

Notes:
- Why isn't my I-D also cited as input = material?
=A0 No insult intended. The current list is simply there = to
=A0 show the ADs that work is already in progress. All I-Ds
=A0 = will be used as input.=A0=A0=A0=A0=A0
- Why isn't my pet topic = included?
=A0=A0Are = you sure it is not there between the lines? This
=
=A0 list of milestones isn't = completely proscriptive.
=A0
The = objective is to have the WG agreed on the milestones that it wants to = commit to by the end of August.
=A0
Thanks,
Adrian
<ccamp-milestones.txt>

= --Apple-Mail-54--129477393-- From owner-ccamp@ops.ietf.org Tue Aug 16 12:55:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54j7-000355-H5 for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 12:55: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 MAA23197 for ; Tue, 16 Aug 2005 12:55:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E55IS-0006jC-3X for ccamp-archive@ietf.org; Tue, 16 Aug 2005 13:32:23 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E54bt-0007AB-F8 for ccamp-data@psg.com; Tue, 16 Aug 2005 16:48:21 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E54br-00079o-80; Tue, 16 Aug 2005 16:48:20 +0000 Message-ID: <430218C9.3070903@psg.com> Date: Tue, 16 Aug 2005 18:48:09 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, zinin@psg.com, "'Kireeti Kompella'" Subject: Re: Moving forward with the CCAMP charter References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> In-Reply-To: <00db01c5a256$6624ebb0$4f849ed9@Puppy> 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: 8a4bcf8f67063cac573319207fe3db35 Content-Transfer-Encoding: 7bit hi adrian i would consider the saturarion document and probably cluster it with the set of items on "deployment/advices/BCPs/etc." there is an item on "OAM Requirements for GMPLS Networks" with a lifetime of around 18 months, while it is difficult to have a detailed view on them wouldn't be advisable to think upon starting an item mid of next year where details (could be info) would be put together several questions > - ASON Routing solutions > * first version of WG draft > * submit for IESG review -> does this mean you envision a single document for IS-IS and OSPF (note i hope these can be submitted to the IESG by 2Q'06 instead of October 2006) also cross-WG review period should be considered > Mar 06 First version of WG informational I-D Aligning GMPLS protocols across the standards bodies and > - Aligning GMPLS protocols across the standards bodies > - Information I-D not intended for publication as an RFC > * first version of WG draft -> what the first sub-bullet implies ? note that i do not see other specific milestone(s) for this document while the second sub-bullet refers to a WG I-D ? > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for IESG review -> do you have more details on this specific work item thanks for the hard work, - dimitri. Adrian Farrel wrote: > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. > > This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. > > Thanks, > Adrian > > > ------------------------------------------------------------------------ > > CCAMP Working Group - Rechartering Effort > > Below you will find > - a list of proposed milestones > - an explanation of why this is a long list > - overview of proposed drafts and work items > > In reviewing this we should look for: > - topics that are irrelevant or unwanted by the WG > - topics that have been left out but are wanted by the WG > - topics that have been assigned the wrong priority or urgency > - topics or collections or topics that are sufficiently large > to potentially warrant their own working group. > > Proposed New milestones > ----------------------- > > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh membership > Nov 05 Submit ASON Routing evaluation I-D for IESG review > Nov 05 First version of WG I-D on path computation implmentation advice > Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF > Nov 05 First version WG I-D MPLS to GMPLS migration strategies > Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS > Nov 05 First version WG I-D Change of LSP ownership between management and control planes > Dec 05 First version of WG I-D for ASON Routing solutions > Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review > Dec 05 Submit Per-domain path computation signaling I-D for IESG review > Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region Networks > Dec 05 First version WG I-D for Evaluation of existing protocols for MLN/MRN > Dec 05 First version WG I-D for Protocol solutions for MLN/MRN > Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG review > Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review > Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module > Jan 06 First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths > Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review > Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and solutions > Jan 06 First version WG I-D GMPLS OAM Requirements > Jan 06 First version WG I-D Routing and signaling for complex optical constraints > Feb 06 Submit LSP Stitching I-D for IESG review > Mar 06 First version of WG informational I-D Aligning GMPLS protocols across the standards bodies > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for IESG review > Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module > Mar 06 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions > Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review > Jun 06 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review > Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review > Jun 06 Submit Change of LSP ownership between management and control planes I-D for IESG review > Aug 06 Submit path computation implmentation advice I-D for IESG review > Oct 06 Submit ASON Routing solutions I-D for IESG review > Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review > Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG review > Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review > Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review > Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review > Dec 06 Submit GMPLS OAM Requirements I-D for IESG review > Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review > Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review > Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review > Oct 07 Submit Routing and signaling for complex optical constraints I-D for IESG review > Oct 07 Recharter or close Working Group > > > Why so many milestons? > ---------------------- > The number of milestones shown in this proposed list far exceeds > anything I have ever seen in a working group charter. This is > intentional and while it does indicate a heavy work-load it also > indicates a higher level of micro-management than is usual within > working groups. Thus two milestones are presented for each I-D > (adoption as a WG I-D, and passing to the IESG post-WG-last-call). > > This can be compared with the "normal" charter milestones which > include a single work-related item that may span several I-Ds and > refers vaguely only to the "submission" of I-Ds. > > In other words, reviewers of this list should not panic because > of its length, but should see this as beneficial. > > > Explanation of I-Ds and work items > ---------------------------------- > > The following text briefly introduces the work items that are > represented by the milestones listed above. In this text an > astrix (*) indicates a milestone to be set. > > The work is divided into several categories according to how > core it is and how it should be prioritized. Existing drafts > are referenced to indicate that work is already in progress - > this is not intended to provide a complete list of existing > drafts. > > Completing existing work > ======================== > > ASON > - ASON Routing evaluation > - already have draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt > * submit for IESG review > - ASON Routing solutions > * first version of WG draft > * submit for IESG review > - GMPLS signaling in support of Call Management > - already have draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt > * submit for IESG review > - GMPLS/ASON lexicography > - already have draft-ietf-ccamp-gmpls-ason-lexicography-03.txt > * submit for IESG review > - Aligning GMPLS protocols across the standards bodies > - Information I-D not intended for publication as an RFC > * first version of WG draft > > Interoperability reports and advice > - signaling and routing > - already have draft-ietf-ccamp-gmpls-addressing-01.txt > * submit for IESG review > - path computation > * first version of WG draft > - based on draft-otani-ccamp-gmpls-cspf-constraints-01.txt > * submit for IESG review > > Additional MIB modules > - OSPF-TE > * first version of WG draft > - based on draft-otani-ccamp-gmpls-ospf-mib-00.txt > * submit for IESG review > - ISIS-TE > * first version of WG draft > * submit for IESG review > - Signaling > - Need "living" MIB module under development to catch > the minor protocol extensions that have been made > * first version of WG draft > * submit for IESG review > > Inter-domain > - LSP Stitching > - already have draft-ietf-ccamp-lsp-stitching-01.txt > * submit for IESG review > - RSVP-TE extensions for interdomain > - already have draft-ietf-ccamp-inter-domain-rsvp-te-01.txt > * submit for IESG review > - Per-domain path computation signaling > - already have draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt > * submit for IESG review > - Analysis of inter-domain issues for disjoint and protected paths > - Informational I-D to close off the topic and devolve to PCE > * first version of WG draft > * submit for IESG review > > New items already started and within existing charter > ===================================================== > > Advertising TE Node Capabilities > - ISIS and OSPF in the same I-D > * first version of WG draft > - based on draft-vasseur-ccamp-te-node-cap-00.txt > * review by IGP working groups > * submit for IESG review > > Automatic discovery of MPLS-TE mesh membership > - depends on TE Node capabilities I-D > * first version of WG draft > - based on draft-vasseur-ccamp-automesh-00.txt > * submit for IESG review > > Multi-layer networks (also multi-region networks) > - Requirements > * first version of WG draft > - based on draft-shiomoto-ccamp-gmpls-mrn-reqs-02.txt > * submit for IESG review > - Evaluation of existing protocols > * first version of WG draft > - based on draft-leroux-ccamp-gmpls-mrn-eval-01.txt > * submit for IESG review > - Solutions > * first version of WG draft > - based on draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt > * submit for IESG review > > MPLS-GMPLS interworking requirements and solutions > * first version of WG draft > - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt > * submit for IESG review > > MPLS to GMPLS migration strategies > * Informational I-D first version of WG draft > - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt > - material from draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt > * submit Informational I-D for IESG review > > Minor items just starting but close to heart of WG > ================================================== > > GMPLS OAM Requirements > - Interesting and worthwhile > * first version of WG draft > - based on immature draft-nadeau-ccamp-gmpls-oam-requirements-00.txt > * submit for IESG review > > Minor items just starting and important becuase of inter-SDO interactions > ========================================================================= > > GMPLS coordination of VCAT and LCAS > - single requirements and solutions draft almost an applicablity statement > * first version of WG draft > - based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt > * submit for IESG review > > Change of LSP ownership between management and control planes > - single requirements and solutions draft defines one bit and a procedure > * first version of WG draft > - based on draft-caviglia-mp2cpcp2mp-02.txt > * submit for IESG review > > More forward-looking > ==================== > > Routing and signaling for complex optical constraints > * first version of WG draft > - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt > * submit for IESG review From owner-ccamp@ops.ietf.org Tue Aug 16 15:01:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56gT-0008SJ-5H for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:01:13 -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 PAA28835 for ; Tue, 16 Aug 2005 15:01:11 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E57Fq-0001Pa-Jp for ccamp-archive@ietf.org; Tue, 16 Aug 2005 15:37:47 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E56Zn-000HUb-4L for ccamp-data@psg.com; Tue, 16 Aug 2005 18:54:19 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E56Zl-000HUA-9x; Tue, 16 Aug 2005 18:54:17 +0000 Received: from du-069-0123.access.clara.net ([217.158.132.123] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E56Zj-0006zO-8a; Tue, 16 Aug 2005 19:54:16 +0100 Message-ID: <01d401c5a294$477581f0$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "JP Vasseur" Cc: , , "'Kireeti Kompella'" References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> <6A0BF8B4-577A-4AFC-8132-B086AC914C64@cisco.com> Subject: Re: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 19:53:53 +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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit > (1) Analysis of inter-domain issues for disjoint and protected paths > - Informational I-D to close off the topic and devolve to PCE > * first version of WG draft > * submit for IESG review > > Could you briefly elaborate on this item ? I think we have the need for an informational I-D that is a bit like the existing inter-domain framework I-D, but that examines the more complex question of the provisioning of disjoint and protection paths across domain boundaries. I am aware that there a lot of ideas out there and that there has been a lot of research. I think we need to capture an overview. It is my (personal - not WG chair) opinion that this I-D will point firmly at the PCE WG. But just as for single paths we discovered that there are some (limited) scenarios for single paths where signaling is suitable on its own, we may find some solutions for diverse and protected paths. > (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful- > shutdown, you may want to add draft-leroux-ccamp-ctrl- > saturation-01.txt ? Yes. I am inclined to add a work item for "control plane robustness". Adrian From owner-ccamp@ops.ietf.org Tue Aug 16 15:01:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56gg-0000EY-Mf for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:01: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 PAA28844 for ; Tue, 16 Aug 2005 15:01:24 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E57G5-0001Po-3x for ccamp-archive@ietf.org; Tue, 16 Aug 2005 15:38:01 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E56Zq-000HVB-IJ for ccamp-data@psg.com; Tue, 16 Aug 2005 18:54:22 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E56Zo-000HUl-Mj; Tue, 16 Aug 2005 18:54:20 +0000 Received: from du-069-0123.access.clara.net ([217.158.132.123] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E56Zl-0006zO-8z; Tue, 16 Aug 2005 19:54:20 +0100 Message-ID: <01d501c5a294$48b973a0$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Zafar Ali \(zali\)" , Cc: , "Kireeti Kompella" References: Subject: Re: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 19:54: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: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Hi Zafar, See my response to JP. Adrian ----- Original Message ----- From: "Zafar Ali (zali)" To: "Adrian Farrel" ; Cc: ; "Kireeti Kompella" Sent: Tuesday, August 16, 2005 3:34 PM Subject: RE: Moving forward with the CCAMP charter Hi Adrian, Graceful shutdown, a method for explicitly notifying a set of nodes that either a Link or an entire node will remove itself from the network or the protocol is going to be disabled for a link or a node, had good response when kireeti polled for charter updates some times back. We have been waiting for a charter update to move with this ID (draft-ali-ccamp-mpls-graceful-shutdown-xx.txt). I think got missed in your list. can you please include this work item in the milestone list as well. Thanks Regards... Zafar ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, August 16, 2005 7:28 AM To: ccamp@ops.ietf.org Cc: zinin@psg.com; 'Kireeti Kompella' Subject: Moving forward with the CCAMP charter Hi, Please find attached a file that contains: - a set of proposed *draft* milestones - a discussion of why there are so many milestones - a high-level explanation of the work items. Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. I would welcome your (constructive!) comments. Notes: - Why isn't my I-D also cited as input material? No insult intended. The current list is simply there to show the ADs that work is already in progress. All I-Ds will be used as input. - Why isn't my pet topic included? Are you sure it is not there between the lines? This list of milestones isn't completely proscriptive. The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Aug 16 15:12:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56r5-00020H-VL for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:12:12 -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 PAA29752 for ; Tue, 16 Aug 2005 15:12:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E57QU-0001dw-CP for ccamp-archive@ietf.org; Tue, 16 Aug 2005 15:48:46 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E56mT-000J5l-7V for ccamp-data@psg.com; Tue, 16 Aug 2005 19:07:25 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E56mS-000J5C-73; Tue, 16 Aug 2005 19:07:24 +0000 Received: from du-069-0123.access.clara.net ([217.158.132.123] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E56mP-0007tI-82; Tue, 16 Aug 2005 20:07:23 +0100 Message-ID: <01ed01c5a296$1bde3a30$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: , , "'Kireeti Kompella'" References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> <430218C9.3070903@psg.com> Subject: Re: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 20:08:43 +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: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit > i would consider the saturarion document and probably cluster it with > the set of items on "deployment/advices/BCPs/etc." Well, the control plane saturation I-D defines new protocol procedures and encodings so it needs to be standards track if we do it. Thus my response to JP. If you are raising a new category of work (and I know you commented on this in Paris) for deployment/advices/BCPs/etc. I would appreciate it if you could: - compare what you want with "Interoperability reports and advice" - suggest some I-D titles that you might - want to see - be willing to work on (note, these two categories do not have to overlapping) > there is an item on "OAM Requirements for GMPLS Networks" with a > lifetime of around 18 months, while it is difficult to have a detailed > view on them wouldn't be advisable to think upon starting an item mid of > next year where details (could be info) would be put together I think there is some detail missing from your suggestion. I think you are saying that we should plan to start developing solutions to meet the OAM requirements that we will document. This sounds very good, but I am unwilling to insert a milestone without knowing what we are going to work on or whether anyone has any intention of doing the work or developing the software. I would suggest that this is an item that we should monitor and know that the chairs are likely to look favorably on solutions work that meets the requirements. In the back of my mind, however, is the tunnel trace I-D which lies in a coffin with a stake through its heart. Not because there weren't requirements (we have an RFC documenting the requirements) and not because no-one wanted to write the I-D (we had several authors), but because no-one wanted to implement. > several questions > > > - ASON Routing solutions > > * first version of WG draft > > * submit for IESG review > > -> does this mean you envision a single document for IS-IS and OSPF > (note i hope these can be submitted to the IESG by 2Q'06 instead of > October 2006) also cross-WG review period should be considered Not clear that a BGP draft isn't needed too! These are generic milestones (I have already proposed too many milestones!). If the changes are tiny and use existing TLVs then a single I-D will probably do. Otherwise, one I-D per protocol. > > Mar 06 First version of WG informational I-D Aligning GMPLS protocols > across the standards bodies > > and > > > - Aligning GMPLS protocols across the standards bodies > > - Information I-D not intended for publication as an RFC > > * first version of WG draft > > -> what the first sub-bullet implies ? note that i do not see other > specific milestone(s) for this document while the second sub-bullet > refers to a WG I-D ? Yes. We need to drive closer alignment between the various uses of GMPLS protocols across the standard bodies. In order to colate our thoughts and direct discussions in and out of CCAMP we will need to document our ideas in an I-D. Because we wish to demonstrate CCAMP community cohesion behind our thoughts, this will need to be a WG I-D (hence the milestone and starred bullet). However, it is far from clear that the I-D will need to progress to RFC. After all, once we identify the actions that are needed, we will carry out the actions. We will then need to update the I-D for further actions etc. If, on the other hand, the I-D turns out to document longer-term or ongoing procedures (like the GMPLS change process) we will certainly need to progress the I-D. > > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D > for IESG review > > -> do you have more details on this specific work item Not completely sure. It seems to me that if we are doing stuff for signaling, we should also do it for routing. It is possible that this folds natrually into the existing signaling (addressing) I-D. Hence this milestone depends on the work item... Interoperability reports and advice - signaling and routing - already have draft-ietf-ccamp-gmpls-addressing-01.txt * submit for IESG review > thanks for the hard work, You're welcome. Thanks for the support. Adrian From owner-ccamp@ops.ietf.org Tue Aug 16 18:48:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ADv-0000GI-Tz for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 18:48:00 -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 SAA18015 for ; Tue, 16 Aug 2005 18:47:56 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5AnM-00018R-74 for ccamp-archive@ietf.org; Tue, 16 Aug 2005 19:24:36 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5A78-000AHN-Um for ccamp-data@psg.com; Tue, 16 Aug 2005 22:40:58 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5A77-000AFy-LC; Tue, 16 Aug 2005 22:40:57 +0000 Message-ID: <43026B6E.8070903@psg.com> Date: Wed, 17 Aug 2005 00:40:46 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org, zinin@psg.com, "'Kireeti Kompella'" Subject: Re: Moving forward with the CCAMP charter References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> <430218C9.3070903@psg.com> <01ed01c5a296$1bde3a30$4f849ed9@Puppy> In-Reply-To: <01ed01c5a296$1bde3a30$4f849ed9@Puppy> 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Adrian Farrel wrote: >>i would consider the saturarion document and probably cluster it with >>the set of items on "deployment/advices/BCPs/etc." > > Well, the control plane saturation I-D defines new protocol procedures and > encodings so it needs to be standards track if we do it. > > Thus my response to JP. i am fine with a category "control plane robustness" separated from the one mentioned here below note: however, i am not necessarily sure that the type outcome must be driver for classification e.g. the saturation document is an outcome of practicing RSVP-TE with mechanisms such as soft-provisioning > If you are raising a new category of work (and I know you commented on > this in Paris) for deployment/advices/BCPs/etc. I would appreciate it if > you could: > - compare what you want with "Interoperability reports and advice" > - suggest some I-D titles that you might > - want to see > - be willing to work on (note, these two categories do not have to > overlapping) yes, for the time being i think that two major topics are falling in this category: 1) TE link operation(s) and processing practices (which is at the end what makes GMPLS) is a typical topic that would require further development 2) inter-domain relationship(s)/exchanges and admission control policies >>there is an item on "OAM Requirements for GMPLS Networks" with a >>lifetime of around 18 months, while it is difficult to have a detailed >>view on them wouldn't be advisable to think upon starting an item mid of >>next year where details (could be info) would be put together > > I think there is some detail missing from your suggestion. I think you are > saying that we should plan to start developing solutions to meet the OAM > requirements that we will document. This sounds very good, but I am > unwilling to insert a milestone without knowing what we are going to work > on or whether anyone has any intention of doing the work or developing the > software. this is the reason why i did myself tried to position the requirement document (it is the same reasoning at the end) it is also clear that such a topic would benefit from more operational feedback on GMPLS network operation(s) > I would suggest that this is an item that we should monitor and know that > the chairs are likely to look favorably on solutions work that meets the > requirements. ok > In the back of my mind, however, is the tunnel trace I-D which lies in a > coffin with a stake through its heart. Not because there weren't > requirements (we have an RFC documenting the requirements) and not because > no-one wanted to write the I-D (we had several authors), but because > no-one wanted to implement. reason why it may be advisable to have a better view on the "toolset" that would be valuable for operating GMPLS networks (bottom-up) >>several questions >> >> > - ASON Routing solutions >> > * first version of WG draft >> > * submit for IESG review >> >>-> does this mean you envision a single document for IS-IS and OSPF >>(note i hope these can be submitted to the IESG by 2Q'06 instead of >>October 2006) also cross-WG review period should be considered > > Not clear that a BGP draft isn't needed too! a complete response to this question would deserve an I-D by itself ;-) > These are generic milestones (I have already proposed too many > milestones!). > If the changes are tiny and use existing TLVs then a single I-D will > probably do. > Otherwise, one I-D per protocol. ok >> > Mar 06 First version of WG informational I-D Aligning GMPLS protocols >>across the standards bodies >> >>and >> >> > - Aligning GMPLS protocols across the standards bodies >> > - Information I-D not intended for publication as an RFC >> > * first version of WG draft >> >>-> what the first sub-bullet implies ? note that i do not see other >>specific milestone(s) for this document while the second sub-bullet >>refers to a WG I-D ? > > Yes. We need to drive closer alignment between the various uses of GMPLS > protocols across the standard bodies. In order to colate our thoughts and > direct discussions in and out of CCAMP we will need to document our ideas > in an I-D. Because we wish to demonstrate CCAMP community cohesion behind > our thoughts, this will need to be a WG I-D (hence the milestone and > starred bullet). the objective is sensible and i also think valuable to have such common view been written down > However, it is far from clear that the I-D will need to progress to RFC. > After all, once we identify the actions that are needed, we will carry out > the actions. We will then need to update the I-D for further actions etc. > > If, on the other hand, the I-D turns out to document longer-term or > ongoing procedures (like the GMPLS change process) we will certainly need > to progress the I-D. so, this document is meant to be a "process" I-D; therefore, its progress is indeed dependent on action lines that are to be documented >> > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D >>for IESG review >> >>-> do you have more details on this specific work item > > Not completely sure. It seems to me that if we are doing stuff for > signaling, we should also do it for routing. It is possible that this > folds natrually into the existing signaling (addressing) I-D. Hence this > milestone depends on the work item... i see now to what you are referring to note: i would also suggest focusing the below reference i-d on addressing space setting and processing practices (as the name indicates) > Interoperability reports and advice > - signaling and routing > - already have draft-ietf-ccamp-gmpls-addressing-01.txt > * submit for IESG review > >>thanks for the hard work, > > > You're welcome. > Thanks for the support. > > Adrian > > > > . > From owner-ccamp@ops.ietf.org Tue Aug 16 19:39:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5B1f-0003hL-A5 for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 19:39: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 TAA21026 for ; Tue, 16 Aug 2005 19:39:19 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Bb5-0002SZ-6q for ccamp-archive@ietf.org; Tue, 16 Aug 2005 20:16:00 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5Avr-000Eca-7W for ccamp-data@psg.com; Tue, 16 Aug 2005 23:33:23 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5Avq-000EcN-IW for ccamp@ops.ietf.org; Tue, 16 Aug 2005 23:33:22 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 16 Aug 2005 19:32:50 -0400 X-IronPort-AV: i="3.96,114,1122868800"; d="scan'208"; a="66738785:sNHT32453664" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7GNWkQl025445; Tue, 16 Aug 2005 19:32:47 -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); Tue, 16 Aug 2005 19:32:46 -0400 Received: from [192.168.1.102] ([10.86.242.36]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 19:32:46 -0400 In-Reply-To: <01d401c5a294$477581f0$4f849ed9@Puppy> References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> <6A0BF8B4-577A-4AFC-8132-B086AC914C64@cisco.com> <01d401c5a294$477581f0$4f849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v733) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <690B6C56-60F8-4F1F-8349-F3931878A0CA@cisco.com> Cc: , , "'Kireeti Kompella'" Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 19:33:13 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 16 Aug 2005 23:32:46.0454 (UTC) FILETIME=[CEA62960:01C5A2BA] 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Hi Adrian, On Aug 16, 2005, at 2:53 PM, Adrian Farrel wrote: >> (1) Analysis of inter-domain issues for disjoint and protected paths >> - Informational I-D to close off the topic and devolve to PCE >> * first version of WG draft >> * submit for IESG review >> >> Could you briefly elaborate on this item ? >> > > I think we have the need for an informational I-D that is a bit > like the > existing inter-domain framework I-D, but that examines the more > complex > question of the provisioning of disjoint and protection paths across > domain boundaries. I am aware that there a lot of ideas out there > and that > there has been a lot of research. I think we need to capture an > overview. > ok fair enough ... I'll be happy to provide my input on the topic (as you can imagine ;-)) > It is my (personal - not WG chair) opinion that this I-D will point > firmly > at the PCE WG. But just as for single paths we discovered that > there are > some (limited) scenarios for single paths where signaling is > suitable on > its own, we may find some solutions for diverse and protected paths. > > >> (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful- >> shutdown, you may want to add draft-leroux-ccamp-ctrl- >> saturation-01.txt ? >> > > Yes. I am inclined to add a work item for "control plane robustness". > Thanks. JP. > Adrian > From owner-ccamp@ops.ietf.org Tue Aug 16 21:09:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5CQJ-00072X-Ri for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 21:09: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 VAA28152 for ; Tue, 16 Aug 2005 21:08:53 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Czd-0004uf-Lm for ccamp-archive@ietf.org; Tue, 16 Aug 2005 21:45:33 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5CKX-000Mso-Cx for ccamp-data@psg.com; Wed, 17 Aug 2005 01:02:57 +0000 Received: from [192.26.91.6] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5CKW-000MsZ-Nc for ccamp@ops.ietf.org; Wed, 17 Aug 2005 01:02:56 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id A6691EC8D7; Wed, 17 Aug 2005 10:02:52 +0900 (JST) Received: from platinum.onw.kddilabs.jp (platinum.onw.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id 46211EC8D4; Wed, 17 Aug 2005 10:02:52 +0900 (JST) Received: from [IPv6:2001:200:601:1e02:0:5efe:ac13:570e] (unknown [IPv6:2001:200:601:1e02:0:5efe:ac13:570e]) by platinum.onw.kddilabs.jp (Postfix) with ESMTP id D6300578103; Wed, 17 Aug 2005 09:56:16 +0900 (JST) Message-ID: <43028CCB.2090607@kddilabs.jp> Date: Wed, 17 Aug 2005 10:03:07 +0900 From: Tomohiro Otani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Adrian Farrel Cc: JP Vasseur , ccamp@ops.ietf.org, zinin@psg.com, "'Kireeti Kompella'" Subject: Re: Moving forward with the CCAMP charter References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> <6A0BF8B4-577A-4AFC-8132-B086AC914C64@cisco.com> <01d401c5a294$477581f0$4f849ed9@Puppy> <690B6C56-60F8-4F1F-8349-F3931878A0CA@cisco.com> In-Reply-To: <690B6C56-60F8-4F1F-8349-F3931878A0CA@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Hi Adrian, Being related with your text and JP's messages, I would ask you to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt. Is this related with a kind of baseline for (1) Analysis of inter-domain issues ? So far, there is a proposed draft of GMPLS inter-domain signaling as we discussed in Paris, but there is no draft of GMPLS inter-domain routing definition whether it is with TE extension or not. (your framework draft covers these points) Regards, tomo JP Vasseur wrote: >Hi Adrian, > >On Aug 16, 2005, at 2:53 PM, Adrian Farrel wrote: > >>> (1) Analysis of inter-domain issues for disjoint and protected paths >>> - Informational I-D to close off the topic and devolve to PCE >>> * first version of WG draft >>> * submit for IESG review >>> >>> Could you briefly elaborate on this item ? >>> >> >> I think we have the need for an informational I-D that is a bit >> like the >> existing inter-domain framework I-D, but that examines the more >> complex >> question of the provisioning of disjoint and protection paths across >> domain boundaries. I am aware that there a lot of ideas out there >> and that >> there has been a lot of research. I think we need to capture an >> overview. >> > >ok fair enough ... I'll be happy to provide my input on the topic (as >you can imagine ;-)) > >> It is my (personal - not WG chair) opinion that this I-D will point >> firmly >> at the PCE WG. But just as for single paths we discovered that >> there are >> some (limited) scenarios for single paths where signaling is >> suitable on >> its own, we may find some solutions for diverse and protected paths. >> >> >>> (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful- >>> shutdown, you may want to add draft-leroux-ccamp-ctrl- >>> saturation-01.txt ? >>> >> >> Yes. I am inclined to add a work item for "control plane robustness". >> > >Thanks. > >JP. > >> Adrian >> > > > > From owner-ccamp@ops.ietf.org Tue Aug 16 22:25:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Dcr-0005WV-Vj for ccamp-archive@megatron.ietf.org; Tue, 16 Aug 2005 22:25: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 WAA01352 for ; Tue, 16 Aug 2005 22:25:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5EBq-0006cB-Ri for ccamp-archive@ietf.org; Tue, 16 Aug 2005 23:02:36 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5DVd-0003bx-6M for ccamp-data@psg.com; Wed, 17 Aug 2005 02:18:29 +0000 Received: from [211.4.169.26] (helo=usjk1004.kddi.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5DVa-0003ba-Dl; Wed, 17 Aug 2005 02:18:26 +0000 Received: from usjk1005.kddi.com (usjk1005 [10.96.2.2]) by usjk1004.kddi.com with ESMTP id j7H2IMb01508; Wed, 17 Aug 2005 11:18:22 +0900 (JST) Received: from usjk1039 (localhost [127.0.0.1]) by usjk1005.kddi.com with SMTP id j7H2IMC02855; Wed, 17 Aug 2005 11:18:22 +0900 (JST) Received: from [127.0.0.1] ([133.128.75.220]) by usjk1010.kddi.com (InterMail vM.5.01.02.00 201-253-116-121-20001201) with ESMTP id <20050817021821.BYLX18180.usjk1010.kddi.com@[127.0.0.1]>; Wed, 17 Aug 2005 11:18:21 +0900 Date: Wed, 17 Aug 2005 11:18:18 +0900 From: Kenji Kumaki To: "Adrian Farrel" Subject: Re: Moving forward with the CCAMP charter Cc: , , "'Kireeti Kompella'" In-Reply-To: <00db01c5a256$6624ebb0$4f849ed9@Puppy> References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> Message-Id: <20050817104106.7E90.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-WAuditID: 0508171118210000200569 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: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Hi Adrian, I have some comments on new items. >MPLS-GMPLS interworking requirements and solutions > * first version of WG draft > - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt > * submit for IESG review draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt includes MPLS/GMPLS interworking requirements and soultions. So I think this draft should be put in the first version of WG draft. >MPLS to GMPLS migration strategies > * Informational I-D first version of WG draft > - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt > - material from draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt > * submit Informational I-D for IESG review Zafar's draft is merged into draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt. So I think you should replace Zafar's to mine. Thanks, Kenji On Tue, 16 Aug 2005 12:28:11 +0100 "Adrian Farrel" wrote: > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. > > This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. > > Thanks, > Adrian -- Kenji Kumaki From owner-ccamp@ops.ietf.org Wed Aug 17 03:21:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5IEc-00043l-Ap for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 03:21: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 DAA11786 for ; Wed, 17 Aug 2005 03:21:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Io4-0005Ya-6M for ccamp-archive@ietf.org; Wed, 17 Aug 2005 03:57:55 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5I77-00003k-AF for ccamp-data@psg.com; Wed, 17 Aug 2005 07:13:29 +0000 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5I76-00003X-CN for ccamp@ops.ietf.org; Wed, 17 Aug 2005 07:13:28 +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 j7H7DNlg032155 for ; Wed, 17 Aug 2005 08:13:24 +0100 (envelope-from Diego.Caviglia@marconi.com) Subject: Re: Moving forward with the CCAMP charter To: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 17 Aug 2005 09:13:28 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 17/08/2005 08:13:22 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi Adrian and all, I've a question about GMPLS interworking with inherent protection scheme. With inherent protection scheme I mean e.g. MS-SPRing in transport network. MS-SPring is widely deployed and IMHO interworking between that protection scheme and GMPLS should be foreseen. Unfortunately there are some constraints to be satisfied (timeslot interchange and squelching table) when an LSP is created on a MS-SPRing. And now the question is this kind of interworking something that should be covered in CCAMP (I know that there are some Study Point in ITU-T to cover this issues)? IMHO I think the answer is yes but I like to know the feeling of the other guys here. Regards Diego From owner-ccamp@ops.ietf.org Wed Aug 17 04:13:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5J3N-00069B-49 for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 04:13: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 EAA14322 for ; Wed, 17 Aug 2005 04:13:39 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Jcl-0007HN-KK for ccamp-archive@ietf.org; Wed, 17 Aug 2005 04:50:22 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5Iyi-00062t-4w for ccamp-data@psg.com; Wed, 17 Aug 2005 08:08:52 +0000 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5Iye-00062L-50 for ccamp@ops.ietf.org; Wed, 17 Aug 2005 08:08:48 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Wed, 17 Aug 2005 17:10:58 +0900 Thread-Topic: Moving forward with the CCAMP charter thread-index: AcWjAzLQlIm8Cix3SeGqvAwPJttkLQ== Reply-To: "CHO, JAI HYUNG" From: "CHO, JAI HYUNG" To: "Adrian Farrel" , Subject: RE: Moving forward with the CCAMP charter Date: Wed, 17 Aug 2005 17:10:58 +0900 Comment: GQ19@|@ZEk=E?,18?x, BcN1b MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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: 17 Aug 2005 08:10:58.0536 (UTC) FILETIME=[32F95E80:01C5A303] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.1 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: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Hi, Adrian Thank you for your milestone work. However, I can not find L2SC work in your document. Where does it belong to ? I believe there's some number of people supporting thie work and also we see clear industry need for this work. I think it would be good if we have L2SC milestone at least for framework and solution document. thanks Jaihyung Dr. Jaihyung Cho ETRI, Korea phone : 042) 860-5514 oversea: +82-42-860-5514 fax: +82-42-861-5550 -----?? ???----- From: "Adrian Farrel" From Date: 2005-08-16 ?? 8:28:11 To: "ccamp@ops.ietf.org" Cc: "zinin@psg.com" , "'Kireeti Kompella'" Subject: Moving forward with the CCAMP charter Hi, Please find attached a file that contains: - a set of proposed *draft* milestones - a discussion of why there are so many milestones - a high-level explanation of the work items. Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. I would welcome your (constructive!) comments. Notes: - Why isn't my I-D also cited as input material? No insult intended. The current list is simply there to show the ADs that work is already in progress. All I-Ds will be used as input. - Why isn't my pet topic included? Are you sure it is not there between the lines? This list of milestones isn't completely proscriptive. The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Aug 17 05:27:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5KCj-0003KD-44 for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 05:27: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 FAA16922 for ; Wed, 17 Aug 2005 05:27:22 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Km8-0000kF-TF for ccamp-archive@ietf.org; Wed, 17 Aug 2005 06:04:07 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5K6K-000Dob-II for ccamp-data@psg.com; Wed, 17 Aug 2005 09:20:48 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5K6A-000Dnp-R6; Wed, 17 Aug 2005 09:20:38 +0000 Received: from du-069-0012.access.clara.net ([217.158.132.12] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E5K68-0006LI-90; Wed, 17 Aug 2005 10:20:38 +0100 Message-ID: <02be01c5a30d$4c0add90$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Kenji Kumaki" Cc: , , "'Kireeti Kompella'" References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> <20050817104106.7E90.KE-KUMAKI@kddi.com> Subject: Re: Moving forward with the CCAMP charter Date: Wed, 17 Aug 2005 10:23: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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Hi Kenji, > I have some comments on new items. > > >MPLS-GMPLS interworking requirements and solutions > > * first version of WG draft > > - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt > > * submit for IESG review > > draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt includes MPLS/GMPLS > interworking requirements and soultions. > So I think this draft should be put in the first version of WG draft. As I said > > - Why isn't my I-D also cited as input material? > > No insult intended. The current list is simply there to > > show the ADs that work is already in progress. All I-Ds > > will be used as input. > >MPLS to GMPLS migration strategies > > * Informational I-D first version of WG draft > > - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt > > - material from draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt > > * submit Informational I-D for IESG review > > Zafar's draft is merged into draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt. > So I think you should replace Zafar's to mine. Noted. Cheers, Adrian From owner-ccamp@ops.ietf.org Wed Aug 17 05:27:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5KD2-0003RE-9z for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 05:27: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 FAA16937 for ; Wed, 17 Aug 2005 05:27:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5KmY-0000l3-9M for ccamp-archive@ietf.org; Wed, 17 Aug 2005 06:04:26 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5K6B-000Dnx-EE for ccamp-data@psg.com; Wed, 17 Aug 2005 09:20:39 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5K68-000Dna-5w for ccamp@ops.ietf.org; Wed, 17 Aug 2005 09:20:36 +0000 Received: from du-069-0012.access.clara.net ([217.158.132.12] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E5K65-0006LI-9U; Wed, 17 Aug 2005 10:20:35 +0100 Message-ID: <02bd01c5a30d$4a573a20$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "CHO, JAI HYUNG" , References: <6f1601c5a303$32da64d0$8310fe81@email1> Subject: L2SC [Was: Moving forward with the CCAMP charter] Date: Wed, 17 Aug 2005 10:20:04 +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: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Hi Jaihyung, The Ethernet GMPLS work has certainly not been forgotten! The work of the design team is very important and we need more people to read and digest draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt. it is particularly important that folk read this draft rather than relying on scare stories or email threads. Many of the common concerns and issues have been carefully answered by the DT, and many of the other are not actually raised in this draft. For the moment, the CCAMP list remains the correct place to discuss these issues, but it would seem that the work involved is both larger than the scope of the CCAMP charter and larger than can be easily swallowed by the existing working group (you will have noticed that there are plenty of other things to occupy the WG's time). For this reason (and see the CCAMP draft minutes) we are currently investigating whether there could be a better home for this work. The most obvious solution is to create a new WG, but this would obviously require careful scoping and also would need support from the community. More information on this as it becomes available. Thanks, Adrian ----- Original Message ----- From: "CHO, JAI HYUNG" To: "Adrian Farrel" ; Sent: Wednesday, August 17, 2005 9:10 AM Subject: RE: Moving forward with the CCAMP charter > > Hi, Adrian > > Thank you for your milestone work. > However, I can not find L2SC work in your document. > Where does it belong to ? > I believe there's some number of people supporting thie work > and also we see clear industry need for this work. > I think it would be good if we have L2SC milestone > at least for framework and solution document. > > thanks > > Jaihyung > > > Dr. Jaihyung Cho > ETRI, Korea > phone : 042) 860-5514 > oversea: +82-42-860-5514 > fax: +82-42-861-5550 > > > > > -----?? ???----- > From: "Adrian Farrel" > From Date: 2005-08-16 ?? 8:28:11 > To: "ccamp@ops.ietf.org" > Cc: "zinin@psg.com" , "'Kireeti Kompella'" > Subject: Moving forward with the CCAMP charter > > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. > > This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. > > Thanks, > Adrian > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 17 06:26:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5L7U-0006I4-9N for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 06:26: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 GAA19582 for ; Wed, 17 Aug 2005 06:26:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Lgz-0002LQ-Tx for ccamp-archive@ietf.org; Wed, 17 Aug 2005 07:02:47 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5L1p-000KJP-W3 for ccamp-data@psg.com; Wed, 17 Aug 2005 10:20:13 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5L1p-000KJ4-9b; Wed, 17 Aug 2005 10:20:13 +0000 Received: from du-069-0454.access.clara.net ([217.158.145.200] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E5L1l-000Ngn-7U; Wed, 17 Aug 2005 11:20:10 +0100 Message-ID: <02cc01c5a315$9da4a160$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tomohiro Otani" Cc: "JP Vasseur" , , , "'Kireeti Kompella'" References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> <6A0BF8B4-577A-4AFC-8132-B086AC914C64@cisco.com> <01d401c5a294$477581f0$4f849ed9@Puppy> <690B6C56-60F8-4F1F-8349-F3931878A0CA@cisco.com> <43028CCB.2090607@kddilabs.jp> Subject: Inter-AS GMPLS [Was: Moving forward with the CCAMP charter] Date: Wed, 17 Aug 2005 10:41: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 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: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Hi Tomo, > Being related with your text and JP's messages, I would ask you > to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt. > Is this related with a kind of baseline for (1) Analysis of inter-domain > issues ? > > So far, there is a proposed draft of GMPLS inter-domain signaling > as we discussed in Paris, but there is no draft of GMPLS inter-domain > routing definition whether it is with TE extension or not. > (your framework draft covers these points) Good point. It seems that your draft is discussing two things: 1. TE reachability information exchange 2. Exchange of aggregated TE information for a domain As you point out in section 4.2, the issue of scalability and policy needs to be carefully considered before we pursue this too much further. I think your work, especially the aggregation issues, meshes nicely with the recent draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt. Therefore, I propose the following changes to the draft I sent out before... 1. Delete Jan 06 First version WG I-D Routing and signaling for complex optical constraints Oct 07 Submit Routing and signaling for complex optical constraints I-D for IESG review 2. Insert Jan 06 First version WG I-D Routing and signaling for link viability constraints Oct 07 Submit Routing and signaling for link viability constraints I-D for IESG review 3. Delete More forward-looking ==================== Routing and signaling for complex constraints and inter-domain * first version of WG draft - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt * submit for IESG review 4. Add to Inter-domain section - Analysis and protocol changes for routing and signaling for link viability constraints * first version of WG draft - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt - material from draft-otani-ccamp-interas-gmpls-te-03.txt * submit for IESG review Cheers, Adrian From owner-ccamp@ops.ietf.org Wed Aug 17 06:26:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5L7r-0006PO-Is for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 06:26: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 GAA19610 for ; Wed, 17 Aug 2005 06:26:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5LhO-0002MF-8G for ccamp-archive@ietf.org; Wed, 17 Aug 2005 07:03:10 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5L1u-000KJv-MH for ccamp-data@psg.com; Wed, 17 Aug 2005 10:20:18 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5L1s-000KJc-VG for ccamp@ops.ietf.org; Wed, 17 Aug 2005 10:20:17 +0000 Received: from du-069-0454.access.clara.net ([217.158.145.200] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E5L1o-000Ngn-72; Wed, 17 Aug 2005 11:20:13 +0100 Message-ID: <02cd01c5a315$9f5389e0$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Diego Caviglia" References: Subject: MS-SPring [Was: Moving forward with the CCAMP charter] Date: Wed, 17 Aug 2005 10:44:03 +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: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Hi Diego, I can well believe that this is something that should/could be of interest to CCAMP. It would be premature, however, to put explicit milestones on our charter without first seeing some work on the subject and support from the community. At the very least we would need to scope the problem and understand whether there is any work to be done. If anyone wants to write a draft on this so that we can all understand the problem space, I am sure it would be welcomed. Cheers, Adrian ----- Original Message ----- From: "Diego Caviglia" To: Sent: Wednesday, August 17, 2005 8:13 AM Subject: Re: Moving forward with the CCAMP charter > Hi Adrian and all, > I've a question about GMPLS interworking with inherent > protection scheme. > > With inherent protection scheme I mean e.g. MS-SPRing in transport network. > > MS-SPring is widely deployed and IMHO interworking between that protection > scheme and GMPLS should be foreseen. > Unfortunately there are some constraints to be satisfied (timeslot > interchange and squelching table) when an LSP is created on a MS-SPRing. > > And now the question is this kind of interworking something that should be > covered in CCAMP (I know that there are some Study Point in ITU-T to cover > this issues)? > > IMHO I think the answer is yes but I like to know the feeling of the other > guys here. > > Regards > > Diego > > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 17 06:27:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5L9L-0006iE-EQ for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 06:27: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 GAA19667 for ; Wed, 17 Aug 2005 06:27:56 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Lir-0002PF-2p for ccamp-archive@ietf.org; Wed, 17 Aug 2005 07:04:42 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5L5j-000Kio-Ct for ccamp-data@psg.com; Wed, 17 Aug 2005 10:24:15 +0000 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5L5f-000KiP-DW for ccamp@ops.ietf.org; Wed, 17 Aug 2005 10:24:11 +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 j7HAO3HG026697; Wed, 17 Aug 2005 11:24:04 +0100 (envelope-from Diego.Caviglia@marconi.com) Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] To: "Adrian Farrel" Cc: " X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 17 Aug 2005 12:24:11 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 17/08/2005 11:24:03 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: 10ba05e7e8a9aa6adb025f426bef3a30 Adrian, actually I have a draft on this matter under my pillow ;-)) it is quite rought but can be interestion to start the discussion. I'll post it ASAP, anyway it there any interest from the community on this subject? Regards Diego "Adrian Farrel" on 17/08/2005 11.44.03 Please respond to "Adrian Farrel" To: , "Diego Caviglia" cc: Subject: MS-SPring [Was: Moving forward with the CCAMP charter] Hi Diego, I can well believe that this is something that should/could be of interest to CCAMP. It would be premature, however, to put explicit milestones on our charter without first seeing some work on the subject and support from the community. At the very least we would need to scope the problem and understand whether there is any work to be done. If anyone wants to write a draft on this so that we can all understand the problem space, I am sure it would be welcomed. Cheers, Adrian ----- Original Message ----- From: "Diego Caviglia" To: Sent: Wednesday, August 17, 2005 8:13 AM Subject: Re: Moving forward with the CCAMP charter > Hi Adrian and all, > I've a question about GMPLS interworking with inherent > protection scheme. > > With inherent protection scheme I mean e.g. MS-SPRing in transport network. > > MS-SPring is widely deployed and IMHO interworking between that protection > scheme and GMPLS should be foreseen. > Unfortunately there are some constraints to be satisfied (timeslot > interchange and squelching table) when an LSP is created on a MS-SPRing. > > And now the question is this kind of interworking something that should be > covered in CCAMP (I know that there are some Study Point in ITU-T to cover > this issues)? > > IMHO I think the answer is yes but I like to know the feeling of the other > guys here. > > Regards > > Diego > > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 17 07: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 1E5Lpi-0007Cv-3y for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 07: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 HAA21583 for ; Wed, 17 Aug 2005 07:11:43 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5MPF-0003Zn-3l for ccamp-archive@ietf.org; Wed, 17 Aug 2005 07:48:29 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5Ljo-000PTE-6e for ccamp-data@psg.com; Wed, 17 Aug 2005 11:05:40 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5Ljm-000PSo-Ao; Wed, 17 Aug 2005 11:05:38 +0000 Message-ID: <430319F6.3050302@psg.com> Date: Wed, 17 Aug 2005 13:05:26 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, Diego Caviglia Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] References: <02cd01c5a315$9f5389e0$4f849ed9@Puppy> In-Reply-To: <02cd01c5a315$9f5389e0$4f849ed9@Puppy> 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit hi adrian - the "ring" topic is part of a set that comes out on a periodic yearly basis where one sees some interest popping up and then slowing down (it used also to be a topic of discussion at the former IPO WG) however, the first question is "why ring topologies" ? and for which kind of switching technology ? thanks, - dimitri. Adrian Farrel wrote: > Hi Diego, > > I can well believe that this is something that should/could be of interest > to CCAMP. > > It would be premature, however, to put explicit milestones on our charter > without first seeing some work on the subject and support from the > community. > > At the very least we would need to scope the problem and understand > whether there is any work to be done. If anyone wants to write a draft on > this so that we can all understand the problem space, I am sure it would > be welcomed. > > Cheers, > Adrian > ----- Original Message ----- > From: "Diego Caviglia" > To: > Sent: Wednesday, August 17, 2005 8:13 AM > Subject: Re: Moving forward with the CCAMP charter > > > >>Hi Adrian and all, >> I've a question about GMPLS interworking with inherent >>protection scheme. >> >>With inherent protection scheme I mean e.g. MS-SPRing in transport > > network. > >>MS-SPring is widely deployed and IMHO interworking between that > > protection > >>scheme and GMPLS should be foreseen. >>Unfortunately there are some constraints to be satisfied (timeslot >>interchange and squelching table) when an LSP is created on a MS-SPRing. >> >>And now the question is this kind of interworking something that should > > be > >>covered in CCAMP (I know that there are some Study Point in ITU-T to > > cover > >>this issues)? >> >>IMHO I think the answer is yes but I like to know the feeling of the > > other > >>guys here. >> >>Regards >> >>Diego >> >> >> >> >> >> >> > > > > > . > From owner-ccamp@ops.ietf.org Wed Aug 17 07:16:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Ltu-0007no-V9 for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 07:16: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 HAA21865 for ; Wed, 17 Aug 2005 07:16:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5MTR-0003jT-OP for ccamp-archive@ietf.org; Wed, 17 Aug 2005 07:52:50 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5Lpk-0000KY-IM for ccamp-data@psg.com; Wed, 17 Aug 2005 11:11:48 +0000 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5Lpj-0000KC-HR; Wed, 17 Aug 2005 11:11:47 +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 j7HBBc41001352; Wed, 17 Aug 2005 12:11:38 +0100 (envelope-from Diego.Caviglia@marconi.com) Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: "Adrian Farrel , "ccamp" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 17 Aug 2005 13:11:44 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 17/08/2005 12:11:37 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: 22bbb45ef41b733eb2d03ee71ece8243 Hi Dimitri, of course you're right this is not the first in we discuss MS-SPRing in CCAMP, anyway given that we are discussing the new charter of the WG this could be a good moment to decide if interworking between MS-SPRing and GMPLS is something that we need to cover. I'll try to answer to your questions. >"why ring topologies" Because there is a plenty of ring topology in the transport world. >and for which kind of switching technology ? I was thinking about SDH. Regards Diego dimitri papadimitriou on 17/08/2005 13.05.26 Please respond to dpapadimitriou@psg.com; Please respond to dimitri.papadimitriou@alcatel.be To: Adrian Farrel cc: ccamp@ops.ietf.org, Diego Caviglia Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] hi adrian - the "ring" topic is part of a set that comes out on a periodic yearly basis where one sees some interest popping up and then slowing down (it used also to be a topic of discussion at the former IPO WG) however, the first question is "why ring topologies" ? and for which kind of switching technology ? thanks, - dimitri. Adrian Farrel wrote: > Hi Diego, > > I can well believe that this is something that should/could be of interest > to CCAMP. > > It would be premature, however, to put explicit milestones on our charter > without first seeing some work on the subject and support from the > community. > > At the very least we would need to scope the problem and understand > whether there is any work to be done. If anyone wants to write a draft on > this so that we can all understand the problem space, I am sure it would > be welcomed. > > Cheers, > Adrian > ----- Original Message ----- > From: "Diego Caviglia" > To: > Sent: Wednesday, August 17, 2005 8:13 AM > Subject: Re: Moving forward with the CCAMP charter > > > >>Hi Adrian and all, >> I've a question about GMPLS interworking with inherent >>protection scheme. >> >>With inherent protection scheme I mean e.g. MS-SPRing in transport > > network. > >>MS-SPring is widely deployed and IMHO interworking between that > > protection > >>scheme and GMPLS should be foreseen. >>Unfortunately there are some constraints to be satisfied (timeslot >>interchange and squelching table) when an LSP is created on a MS-SPRing. >> >>And now the question is this kind of interworking something that should > > be > >>covered in CCAMP (I know that there are some Study Point in ITU-T to > > cover > >>this issues)? >> >>IMHO I think the answer is yes but I like to know the feeling of the > > other > >>guys here. >> >>Regards >> >>Diego >> >> >> >> >> >> >> > > > > > . > From owner-ccamp@ops.ietf.org Wed Aug 17 07:41:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5MI9-00068f-FG for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 07:41:09 -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 HAA23055 for ; Wed, 17 Aug 2005 07:41:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Mrg-0004Yz-NR for ccamp-archive@ietf.org; Wed, 17 Aug 2005 08:17:53 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5M8T-0002Rv-Qn for ccamp-data@psg.com; Wed, 17 Aug 2005 11:31:09 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5M8R-0002RT-Em; Wed, 17 Aug 2005 11:31:07 +0000 Message-ID: <43031FEF.2080308@psg.com> Date: Wed, 17 Aug 2005 13:30:55 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Diego Caviglia CC: dimitri.papadimitriou@alcatel.be, "Adrian Farrel , ccamp Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit hi diego Diego Caviglia wrote: > Hi Dimitri, > of course you're right this is not the first in we discuss > MS-SPRing in CCAMP, anyway given that we are discussing the new charter of > the WG this could be a good moment to decide if interworking between > MS-SPRing and GMPLS is something that we need to cover. > > I'll try to answer to your questions. > >>"why ring topologies" > > Because there is a plenty of ring topology in the transport world. i know but i will clarify the question because the question is to be put in perspective "why (and where) ring topologies are suitable" ? >>and for which kind of switching technology ? > > I was thinking about SDH. and what does prevent a WG like CCAMP to restrict applicability to circuit ? reason for providing an answer to initial question > Regards > > Diego > > > > > > dimitri papadimitriou on 17/08/2005 13.05.26 > > Please respond to dpapadimitriou@psg.com; Please respond to > dimitri.papadimitriou@alcatel.be > > To: Adrian Farrel > cc: ccamp@ops.ietf.org, Diego Caviglia > > Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] > > hi adrian - > > the "ring" topic is part of a set that comes out on a periodic yearly > basis where one sees some interest popping up and then slowing down (it > used also to be a topic of discussion at the former IPO WG) > > however, the first question is "why ring topologies" ? and for which > kind of switching technology ? > > thanks, > - dimitri. > > Adrian Farrel wrote: > > >>Hi Diego, >> >>I can well believe that this is something that should/could be of > > interest > >>to CCAMP. >> >>It would be premature, however, to put explicit milestones on our charter >>without first seeing some work on the subject and support from the >>community. >> >>At the very least we would need to scope the problem and understand >>whether there is any work to be done. If anyone wants to write a draft on >>this so that we can all understand the problem space, I am sure it would >>be welcomed. >> >>Cheers, >>Adrian >>----- Original Message ----- >>From: "Diego Caviglia" >>To: >>Sent: Wednesday, August 17, 2005 8:13 AM >>Subject: Re: Moving forward with the CCAMP charter >> >> >> >> >>>Hi Adrian and all, >>> I've a question about GMPLS interworking with inherent >>>protection scheme. >>> >>>With inherent protection scheme I mean e.g. MS-SPRing in transport >> >>network. >> >> >>>MS-SPring is widely deployed and IMHO interworking between that >> >>protection >> >> >>>scheme and GMPLS should be foreseen. >>>Unfortunately there are some constraints to be satisfied (timeslot >>>interchange and squelching table) when an LSP is created on a MS-SPRing. >>> >>>And now the question is this kind of interworking something that should >> >>be >> >> >>>covered in CCAMP (I know that there are some Study Point in ITU-T to >> >>cover >> >> >>>this issues)? >>> >>>IMHO I think the answer is yes but I like to know the feeling of the >> >>other >> >> >>>guys here. >>> >>>Regards >>> >>>Diego >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >>. >> > > > > > > > > > > > > . > From owner-ccamp@ops.ietf.org Wed Aug 17 08:09:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Mjl-0004U0-58 for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 08:09: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 IAA24640 for ; Wed, 17 Aug 2005 08:09:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5NJE-0005Nq-Dz for ccamp-archive@ietf.org; Wed, 17 Aug 2005 08:46:25 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5Me6-0006Oa-VC for ccamp-data@psg.com; Wed, 17 Aug 2005 12:03:50 +0000 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5Me2-0006O9-T6 for ccamp@ops.ietf.org; Wed, 17 Aug 2005 12:03:47 +0000 Received: from i2km95-ukbr.domain1.systemhost.net ([193.113.197.29]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 13:03:42 +0100 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km95-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Aug 2005 13:03:42 +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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: MS-SPring [Was: Moving forward with the CCAMP charter] Date: Wed, 17 Aug 2005 13:03:41 +0100 Message-ID: Thread-Topic: MS-SPring [Was: Moving forward with the CCAMP charter] Thread-Index: AcWjH2vMWzPf62cUTzqgbYx2IvS5IAAAaeKA From: To: , , Cc: , X-OriginalArrivalTime: 17 Aug 2005 12:03:42.0503 (UTC) FILETIME=[B625A370:01C5A323] 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.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Dimitri, "why (and where) ring topologies are suitable" ? Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will = continue to be, widely deployed based on (dual) ring topologies in the = access/metro because they provide fast protection and reliability whilst = making efficient use of fibre. I do not think this can be disputed so I don't understand where you are = coming from with this question? Regards, Richard =20 From owner-ccamp@ops.ietf.org Wed Aug 17 08:53:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NPg-0005va-FY for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 08:53:03 -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 IAA27895 for ; Wed, 17 Aug 2005 08:52:59 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5NzD-0006nr-De for ccamp-archive@ietf.org; Wed, 17 Aug 2005 09:29:44 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5NGU-000Awr-H2 for ccamp-data@psg.com; Wed, 17 Aug 2005 12:43:30 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5NGT-000Awa-4m; Wed, 17 Aug 2005 12:43:29 +0000 Message-ID: <430330E5.2010204@psg.com> Date: Wed, 17 Aug 2005 14:43:17 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: richard.spencer@bt.com CC: dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com, adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit richard, > Dimitri, > > "why (and where) ring topologies are suitable" ? > > Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will > continue to be, widely deployed based on (dual) ring topologies in > the access/metro because they provide fast protection and reliability > whilst making efficient use of fibre. > > I do not think this can be disputed so I don't understand where you > are coming from with this question? while i do not see why this can't be discussed (e.g. there are dozens of studies available on this topic) and i can just point out that one can deliver fast (time efficient), resource efficient and reliable protection without using rings therefore, it would worth having some operational feedback and state what are the real drivers and rationales if such topic is getting started i.e. what is the real appealing rationale behind this mechanism note: these are just questions that i think where missing from most documents produced on this topic since so far and that are important to be addressed last point you are mentioning RPR so what would be the interaction with the IPORPR WG ? > Regards, Richard > > > > > . > From owner-ccamp@ops.ietf.org Wed Aug 17 09:00:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5NWx-0007Nx-V0 for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 09:00:32 -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 JAA28408 for ; Wed, 17 Aug 2005 09:00:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5O6U-000723-VK for ccamp-archive@ietf.org; Wed, 17 Aug 2005 09:37:16 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5NRz-000Cc4-5l for ccamp-data@psg.com; Wed, 17 Aug 2005 12:55:23 +0000 Received: from [128.87.251.112] (helo=smtpoutuk01.marconi.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5NRv-000CaW-Hc; Wed, 17 Aug 2005 12:55:20 +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 j7HCt2Di016171; Wed, 17 Aug 2005 13:55:03 +0100 (envelope-from Diego.Caviglia@marconi.com) Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: "richard.spencer" , "adrian" , "ccamp" X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 17 Aug 2005 14:55:09 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 17/08/2005 13:55:05 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: cd26b070c2577ac175cd3a6d878c6248 Hi Dimitri, given the high number of MS-SPRing protected transport network already deployed seems reasonable to me, from a Network Operator point of view, to use at the same time MS-SPRing protection with GMPLS restoration. Let's say the first failure is recovered via MS-SPRing in less than 50 ms while subsequent failures can be recovered via GMPLS restoration with lower performance. Basically that is the rationale behind my initial question. What is your view on that? Regards Diego dimitri papadimitriou on 17/08/2005 14.43.17 Please respond to dpapadimitriou@psg.com; Please respond to dimitri.papadimitriou@alcatel.be To: richard.spencer@bt.com cc: dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com, adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] richard, > Dimitri, > > "why (and where) ring topologies are suitable" ? > > Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will > continue to be, widely deployed based on (dual) ring topologies in > the access/metro because they provide fast protection and reliability > whilst making efficient use of fibre. > > I do not think this can be disputed so I don't understand where you > are coming from with this question? while i do not see why this can't be discussed (e.g. there are dozens of studies available on this topic) and i can just point out that one can deliver fast (time efficient), resource efficient and reliable protection without using rings therefore, it would worth having some operational feedback and state what are the real drivers and rationales if such topic is getting started i.e. what is the real appealing rationale behind this mechanism note: these are just questions that i think where missing from most documents produced on this topic since so far and that are important to be addressed last point you are mentioning RPR so what would be the interaction with the IPORPR WG ? > Regards, Richard > > > > > . > From owner-ccamp@ops.ietf.org Wed Aug 17 11:07:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PVY-0007SW-IK for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 11:07: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 LAA06334 for ; Wed, 17 Aug 2005 11:07:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Q57-0002FH-Mf for ccamp-archive@ietf.org; Wed, 17 Aug 2005 11:43:58 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5PQC-00033H-D1 for ccamp-data@psg.com; Wed, 17 Aug 2005 15:01:40 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5PQ8-00032c-0B; Wed, 17 Aug 2005 15:01:36 +0000 Message-ID: <43035143.30301@psg.com> Date: Wed, 17 Aug 2005 17:01:23 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Diego Caviglia CC: dimitri.papadimitriou@alcatel.be, "richard.spencer" , adrian , ccamp Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit diego Diego Caviglia wrote: > Hi Dimitri, > given the high number of MS-SPRing protected transport network > already deployed seems reasonable to me, from a Network Operator point of > view, to use at the same time MS-SPRing protection with GMPLS restoration. there are already two questions here 1. is there an operational need to control such rings using GMPLS (? for instance is it effective knowing that ring based protection is mainly data plane driven ?) and 2. how to position the ring protection wrt to the LSP recovery segment/end-to-end recovery > Let's say the first failure is recovered via MS-SPRing in less than 50 ms > while subsequent failures can be recovered via GMPLS restoration with lower > performance. is it because it is a "local" protection (i.e. wouldn't a segment recovery provide the same time efficiency) or because it is ring based > Basically that is the rationale behind my initial question. > > What is your view on that? my view is that a problem statement should cover such base questions - i am in agreement with adrian stand here - > Regards > > Diego > > > > dimitri papadimitriou on 17/08/2005 14.43.17 > > Please respond to dpapadimitriou@psg.com; Please respond to > dimitri.papadimitriou@alcatel.be > > To: richard.spencer@bt.com > cc: dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com, > adrian@olddog.co.uk, ccamp@ops.ietf.org > > Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] > > > > richard, > > >>Dimitri, >> >>"why (and where) ring topologies are suitable" ? >> >>Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will >>continue to be, widely deployed based on (dual) ring topologies in >>the access/metro because they provide fast protection and reliability >>whilst making efficient use of fibre. >> >>I do not think this can be disputed so I don't understand where you >>are coming from with this question? > > > while i do not see why this can't be discussed (e.g. there are dozens of > studies available on this topic) and i can just point out that one can > deliver fast (time efficient), resource efficient and reliable > protection without using rings > > therefore, it would worth having some operational feedback and state > what are the real drivers and rationales if such topic is getting > started i.e. what is the real appealing rationale behind this mechanism > > note: these are just questions that i think where missing from most > documents produced on this topic since so far and that are important to > be addressed > > last point you are mentioning RPR so what would be the interaction with > the IPORPR WG ? > > >>Regards, Richard >> >> >> >> >>. >> > > > > > > > > > > > > . > From owner-ccamp@ops.ietf.org Wed Aug 17 13:26:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5RgS-0003U2-II for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 13:26: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 NAA13388 for ; Wed, 17 Aug 2005 13:26:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5SFz-0006Ez-A8 for ccamp-archive@ietf.org; Wed, 17 Aug 2005 14:03:23 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5RUh-000Hkl-KE for ccamp-data@psg.com; Wed, 17 Aug 2005 17:14:27 +0000 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5RUd-000HkK-9P for ccamp@ops.ietf.org; Wed, 17 Aug 2005 17:14:23 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 17 Aug 2005 17:23:50 +0000 X-SBRS: None X-IronPort-AV: i="3.96,118,1122854400"; d="scan'208,217"; a="26486023:sNHT37899760" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 17 Aug 2005 12:13:02 -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_01C5A34E.EC43544D" Subject: RE: Responding to the OIF Date: Wed, 17 Aug 2005 12:11:05 -0500 Message-ID: Thread-Topic: Responding to the OIF Thread-Index: AcWecho8wbE0LxlVRcuVSb1RRGwsbgE2T2sg From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" , X-OriginalArrivalTime: 17 Aug 2005 17:13:02.0006 (UTC) FILETIME=[EC790D60:01C5A34E] 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_30_40, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a9d8f61f7718176ef97b85bbcc64331 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A34E.EC43544D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Regarding the first item, we should have only one TSPEC encoding for STS-3c SPE/VC-4 since the intent is to unify signaling for SONET and SDH. Furthermore, contiguous concatenation with one element doesn't make sense. Thus we should change example 8 to match example 1 (in the same way that example 9 matches example 3) and leave the text that indicates RCC != 0 implies NCC>1. Regards, Ben ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, August 11, 2005 7:43 AM To: ccamp@ops.ietf.org Subject: Responding to the OIF Hi, As Lyndon noted in Paris, the OIF has sent us a communication requesting some guidance on a bunch of questions. This is to start the business of constructing a reply. thanks to Dimitri for supplying some of this text. Please send comments and improvements. Adrian ====== 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. 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. We believe that this final sentence should read "greater than or equal to 1," and that this interpretation resolves all of your issues and makes the text consistent with the examples. > 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, an 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. > 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 is currently discussing the use of GMPLS for control of Ethernet devices. We will respond to this point in a separate email. Best regards, Adrian Farrel Kireeti Kompella ============================================================ 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_01C5A34E.EC43544D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Hi,
 
Regarding the first item, we should have only one TSPEC encoding for STS-3c SPE/VC-4 since the intent is to unify signaling for SONET and SDH. 
 
Furthermore, contiguous concatenation with one element doesn't make sense.
 
Thus we should change example 8 to match example 1 (in the same way that example 9 matches example 3) and leave the text that indicates RCC != 0 implies NCC>1.
 
Regards,
Ben

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
Sent: Thursday, August 11, 2005 7:43 AM
To: ccamp@ops.ietf.org
Subject: Responding to the OIF

Hi,

As Lyndon noted in Paris, the OIF has sent us a communication requesting some guidance on a bunch of questions.

This is to start the business of constructing a reply. thanks to Dimitri for supplying some of this text.

Please send comments and improvements.

Adrian

======

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.

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.

We believe that this final sentence should read "greater than or equal to 1," and that this interpretation resolves all of your issues and makes the text consistent with the examples.

> 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, an 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.

> 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...
 
   <Hello Message> ::= <Common Header> [ <INTEGRITY> ]
                              <HELLO>
 
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 is currently discussing the use of GMPLS for control of Ethernet devices. We will respond to this point in a separate email.

Best regards,
Adrian Farrel
Kireeti Kompella
============================================================
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_01C5A34E.EC43544D-- From owner-ccamp@ops.ietf.org Wed Aug 17 16:06:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5UB7-0004xs-7N for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 16:06: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 QAA24906 for ; Wed, 17 Aug 2005 16:06:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Ukc-00038s-Ek for ccamp-archive@ietf.org; Wed, 17 Aug 2005 16:43:13 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5U5c-0008Ql-ST for ccamp-data@psg.com; Wed, 17 Aug 2005 20:00:44 +0000 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5U5Y-0008QH-UX for ccamp@ops.ietf.org; Wed, 17 Aug 2005 20:00:41 +0000 Received: from [192.168.0.102] (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 j7HK0S5U092536; Wed, 17 Aug 2005 13:00:31 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4303975D.9060007@grotto-networking.com> Date: Wed, 17 Aug 2005 13:00:29 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Diego Caviglia CC: Adrian Farrel , " Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] 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: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Hi Diego, there is interest on my part on working with other protection schemes. In general I'm interested in the inter-operation and optimal selection of protection/restoration schemes at different layers. I'm busy this week but next week I expect to also get back to the VCAT draft and review the various notes and such from the other SDOs. Greg B. Diego Caviglia wrote: >Adrian, > actually I have a draft on this matter under my pillow ;-)) it is >quite rought but can be interestion to start the discussion. > >I'll post it ASAP, anyway it there any interest from the community on this >subject? > >Regards > >Diego > > > >"Adrian Farrel" on 17/08/2005 11.44.03 > >Please respond to "Adrian Farrel" > >To: , "Diego Caviglia" >cc: > >Subject: MS-SPring [Was: Moving forward with the CCAMP charter] > >Hi Diego, > >I can well believe that this is something that should/could be of interest >to CCAMP. > >It would be premature, however, to put explicit milestones on our charter >without first seeing some work on the subject and support from the >community. > >At the very least we would need to scope the problem and understand >whether there is any work to be done. If anyone wants to write a draft on >this so that we can all understand the problem space, I am sure it would >be welcomed. > >Cheers, >Adrian >----- Original Message ----- >From: "Diego Caviglia" >To: >Sent: Wednesday, August 17, 2005 8:13 AM >Subject: Re: Moving forward with the CCAMP charter > > > > >>Hi Adrian and all, >> I've a question about GMPLS interworking with inherent >>protection scheme. >> >>With inherent protection scheme I mean e.g. MS-SPRing in transport >> >> >network. > > >>MS-SPring is widely deployed and IMHO interworking between that >> >> >protection > > >>scheme and GMPLS should be foreseen. >>Unfortunately there are some constraints to be satisfied (timeslot >>interchange and squelching table) when an LSP is created on a MS-SPRing. >> >>And now the question is this kind of interworking something that should >> >> >be > > >>covered in CCAMP (I know that there are some Study Point in ITU-T to >> >> >cover > > >>this issues)? >> >>IMHO I think the answer is yes but I like to know the feeling of the >> >> >other > > >>guys here. >> >>Regards >> >>Diego >> >> >> >> >> >> >> >> >> > > > > > > > > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 17 21:28:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ZDE-0008Hl-Fe for ccamp-archive@megatron.ietf.org; Wed, 17 Aug 2005 21:28:56 -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 VAA17930 for ; Wed, 17 Aug 2005 21:28:54 -0400 (EDT) Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Zmq-0005ce-UB for ccamp-archive@ietf.org; Wed, 17 Aug 2005 22:05:47 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5Z5V-000DVX-8z for ccamp-data@psg.com; Thu, 18 Aug 2005 01:20:57 +0000 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5Z5T-000DUz-PE; Thu, 18 Aug 2005 01:20:56 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7I1Kjk1009624; Thu, 18 Aug 2005 10:20:45 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7I1Kjgb026800; Thu, 18 Aug 2005 10:20:45 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7I1Ki4n026795; Thu, 18 Aug 2005 10:20:44 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7I1Kivl002214; Thu, 18 Aug 2005 10:20:44 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7I1KhsA002209; Thu, 18 Aug 2005 10:20:43 +0900 (JST) Received: from dmailsv1.y.ecl.ntt.co.jp (dmailsv1.y.ecl.ntt.co.jp [129.60.53.14]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7I1KhGY001052; Thu, 18 Aug 2005 10:20:43 +0900 (JST) Received: from mailsv04.y.ecl.ntt.co.jp by dmailsv1.y.ecl.ntt.co.jp (8.13.4/dmailsv-1.4) with ESMTP id j7I1KgTp015550; Thu, 18 Aug 2005 10:20:42 +0900 (JST) Received: from localhost by mailsv04.y.ecl.ntt.co.jp (8.13.4/Lab-1.5) with ESMTP id j7I1KfOc009316; Thu, 18 Aug 2005 10:20:41 +0900 (JST) Message-Id: <5.1.1.9.2.20050818095638.0692ebe0@mailsv4.y.ecl.ntt.co.jp> X-Sender: wi002@mailsv4.y.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Thu, 18 Aug 2005 10:20:13 +0900 To: "Adrian Farrel" , From: Wataru Imajuku Subject: Re: Moving forward with the CCAMP charter Cc: , "'Kireeti Kompella'" In-Reply-To: <00db01c5a256$6624ebb0$4f849ed9@Puppy> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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=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: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Hi, Adrian Thank you for sending milestones. I noticed that the issue of coordination with lcas & vcat will be based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt I understand that LCAS/VCAT control draft will be done in single draft which have statements all of requirements, analysis, and solution. I believe that my draft includes some issues which have not addressed in bernsteins draft. For example, the issue of section 5 in my draft. This is important issue when LCAS&VCAT will be applied in MRN. I understand your proposal is my requirement draft draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt will be merged with draft-bernstein-ccamp-.... or simply discard ? Best Regards, Wataru >Hi, > >Please find attached a file that contains: > >- a set of proposed *draft* milestones >- a discussion of why there are so many milestones >- a high-level explanation of the work items. > >Note that this looks like a lot of milestones, but please read the text on >this issue in the attached file. The bottom line is that this is a product >of micro management where I have tried to identify all of the I-Ds that we >might produce to cover the referenced work, and where I have placed two >(sometimes three) milestones for each I-D. > >This micro-management may be over the top, and represents a full pendulum >swing from the previous style of CCAMP milestones, but in the light of the >hiatus of the last 12 months, i think this may be beneficial and might >achieve rapid forwards movement. > >I would welcome your (constructive!) comments. > >Notes: >- Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. >- Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > >The objective is to have the WG agreed on the milestones that it wants to >commit to by the end of August. > >Thanks, >Adrian --------------------------------- Wataru Imajuku Senior Research Engineer @NTT Network Innovation Labs. TEL +81-46-859-4315 FAX +81-46-859-5541 From owner-ccamp@ops.ietf.org Thu Aug 18 05:33:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5gmJ-0003fh-81 for ccamp-archive@megatron.ietf.org; Thu, 18 Aug 2005 05:33: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 FAA22182 for ; Thu, 18 Aug 2005 05:33:37 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5hLy-00024G-EV for ccamp-archive@ietf.org; Thu, 18 Aug 2005 06:10:34 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5gg1-000814-6V for ccamp-data@psg.com; Thu, 18 Aug 2005 09:27:09 +0000 Received: from [128.87.251.113] (helo=smtpoutuk02.marconi.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5gfx-0007zH-Qo; Thu, 18 Aug 2005 09:27:06 +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 j7I9QqM4010288; Thu, 18 Aug 2005 10:26:52 +0100 (envelope-from Diego.Caviglia@marconi.com) Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: "dimitri.papadimitriou" , "\"\"richard.spencer\" , "adrian , "ccamp X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Thu, 18 Aug 2005 11:26:58 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 18/08/2005 10:26:51 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: 2ed806e2f53ff1a061ad4f97e00345ac Dimitri, in line. Regards Diego dimitri papadimitriou on 17/08/2005 17.01.23 Please respond to dpapadimitriou@psg.com; Please respond to dimitri.papadimitriou@alcatel.be To: Diego Caviglia cc: dimitri.papadimitriou@alcatel.be, "richard.spencer" , adrian , ccamp Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] diego Diego Caviglia wrote: > Hi Dimitri, > given the high number of MS-SPRing protected transport network > already deployed seems reasonable to me, from a Network Operator point of > view, to use at the same time MS-SPRing protection with GMPLS restoration. there are already two questions here 1. is there an operational need to control such rings using GMPLS (? for instance is it effective knowing that ring based protection is mainly data plane driven ?) [dc] I prefer to hear something from the Operator here even if my experience tell me that the answer is yes. and 2. how to position the ring protection wrt to the LSP recovery segment/end-to-end recovery [dc] I'm sure I've got the point here sorry, what exatly do you mean with position? > Let's say the first failure is recovered via MS-SPRing in less than 50 ms > while subsequent failures can be recovered via GMPLS restoration with lower > performance. is it because it is a "local" protection (i.e. wouldn't a segment recovery provide the same time efficiency) or because it is ring based [dc] It is because is performed at the SDH layer, all the SDH protection scheme I know have the same performance (e.g. SNCP, MSP) > Basically that is the rationale behind my initial question. > > What is your view on that? my view is that a problem statement should cover such base questions - i am in agreement with adrian stand here - [dc] I'm trying to put togheter a requirement doc that briefly illustrates how MS-SPRing works and what are the information that it needs in order to work corretly. > Regards > > Diego > > > > dimitri papadimitriou on 17/08/2005 14.43.17 > > Please respond to dpapadimitriou@psg.com; Please respond to > dimitri.papadimitriou@alcatel.be > > To: richard.spencer@bt.com > cc: dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com, > adrian@olddog.co.uk, ccamp@ops.ietf.org > > Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] > > > > richard, > > >>Dimitri, >> >>"why (and where) ring topologies are suitable" ? >> >>Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will >>continue to be, widely deployed based on (dual) ring topologies in >>the access/metro because they provide fast protection and reliability >>whilst making efficient use of fibre. >> >>I do not think this can be disputed so I don't understand where you >>are coming from with this question? > > > while i do not see why this can't be discussed (e.g. there are dozens of > studies available on this topic) and i can just point out that one can > deliver fast (time efficient), resource efficient and reliable > protection without using rings > > therefore, it would worth having some operational feedback and state > what are the real drivers and rationales if such topic is getting > started i.e. what is the real appealing rationale behind this mechanism > > note: these are just questions that i think where missing from most > documents produced on this topic since so far and that are important to > be addressed > > last point you are mentioning RPR so what would be the interaction with > the IPORPR WG ? > > >>Regards, Richard >> >> >> >> >>. >> > > > > > > > > > > > > . > From owner-ccamp@ops.ietf.org Thu Aug 18 06:21:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5hWL-0006R7-Lq for ccamp-archive@megatron.ietf.org; Thu, 18 Aug 2005 06:21:13 -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 GAA24453 for ; Thu, 18 Aug 2005 06:21:11 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5i62-0003Rf-Oq for ccamp-archive@ietf.org; Thu, 18 Aug 2005 06:58:09 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5hSP-000DRw-Rs for ccamp-data@psg.com; Thu, 18 Aug 2005 10:17:09 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5hSL-000DPS-Vf; Thu, 18 Aug 2005 10:17:06 +0000 Message-ID: <43046013.6020003@psg.com> Date: Thu, 18 Aug 2005 12:16:51 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Diego Caviglia CC: dimitri.papadimitriou@alcatel.be, " , "adrian , "ccamp Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit diego >>given the high number of MS-SPRing protected transport network >>already deployed seems reasonable to me, from a Network Operator point of >>view, to use at the same time MS-SPRing protection with GMPLS >>restoration. > > there are already two questions here 1. is there an operational need to > control such rings using GMPLS (? for instance is it effective knowing > that ring based protection is mainly data plane driven ?) > [dc] I prefer to hear something from the Operator here even if my > experience tell me that the answer is yes. i don't have the full answer either - the question is to address such considerations and tradeoffs > and 2. how to position the ring protection wrt to the LSP recovery > segment/end-to-end > recovery > [dc] I'm sure I've got the point here sorry, what exatly do you mean with > position? some examples (not exhaustive): will it be seen as link protection for some links used by the end-to-end LSP or LSP segment protection of end-to-end LSP or both ? otoh would it be possible to assume SDH ring protection on top of nodes interconnected by recoverable Lambdas ? >>Let's say the first failure is recovered via MS-SPRing in less than 50 ms >>while subsequent failures can be recovered via GMPLS restoration with >>lower performance. > > is it because it is a "local" protection (i.e. wouldn't a segment > recovery provide the same time efficiency) or because it is ring based > [dc] It is because is performed at the SDH layer, all the SDH protection > scheme I know have the same performance (e.g. SNCP, MSP) so it is the former i.e. "local-(data-plane driven) protection" by the way if you plan to start such document a terminology section inserted w/i an informative appendix would help the IETF reader >>Basically that is the rationale behind my initial question. >> >>What is your view on that? > > my view is that a problem statement should cover such base questions - i > am in agreement with adrian stand here - > [dc] I'm trying to put togheter a requirement doc that briefly illustrates > how MS-SPRing works and what are the information that it needs in order to > work corretly. i don't think there is a need to step into the details of "how it works" in the first phase (an 1-page summary would be enough here, at the end good references are available) but "why/where it makes sense" and "what does it imply" the above discussion is a sample of considerations that such document should address as i wouldn't step in without having an overall picture of the landscape >>Regards >> >>Diego >> >> >> >>dimitri papadimitriou on 17/08/2005 14.43.17 >> >>Please respond to dpapadimitriou@psg.com; Please respond to >> dimitri.papadimitriou@alcatel.be >> >>To: richard.spencer@bt.com >>cc: dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com, >> adrian@olddog.co.uk, ccamp@ops.ietf.org >> >>Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] >> >> >> >>richard, >> >> >> >>>Dimitri, >>> >>>"why (and where) ring topologies are suitable" ? >>> >>>Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will >>>continue to be, widely deployed based on (dual) ring topologies in >>>the access/metro because they provide fast protection and reliability >>>whilst making efficient use of fibre. >>> >>>I do not think this can be disputed so I don't understand where you >>>are coming from with this question? >> >> >>while i do not see why this can't be discussed (e.g. there are dozens of >>studies available on this topic) and i can just point out that one can >>deliver fast (time efficient), resource efficient and reliable >>protection without using rings >> >>therefore, it would worth having some operational feedback and state >>what are the real drivers and rationales if such topic is getting >>started i.e. what is the real appealing rationale behind this mechanism >> >>note: these are just questions that i think where missing from most >>documents produced on this topic since so far and that are important to >>be addressed >> >>last point you are mentioning RPR so what would be the interaction with >>the IPORPR WG ? >> >> >> >>>Regards, Richard >>> >>> >>> >>> >>>. >>> >> >> >> >> >> >> >> >> >> >> >> >>. >> > > > > > > > > > > > . > From owner-ccamp@ops.ietf.org Thu Aug 18 07:29:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5iap-0004lo-2i for ccamp-archive@megatron.ietf.org; Thu, 18 Aug 2005 07:29: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 HAA27497 for ; Thu, 18 Aug 2005 07:29:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5jAY-0005Sv-Vl for ccamp-archive@ietf.org; Thu, 18 Aug 2005 08:06:51 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5iTT-000K2V-Pk for ccamp-data@psg.com; Thu, 18 Aug 2005 11:22:19 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5iTS-000K28-Um for ccamp@ops.ietf.org; Thu, 18 Aug 2005 11:22:19 +0000 Received: from du-069-0489.access.clara.net ([217.158.145.235] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E5iTN-000IiV-I4; Thu, 18 Aug 2005 12:22:16 +0100 Message-ID: <048301c5a3e7$74538290$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Wataru Imajuku" References: <5.1.1.9.2.20050818095638.0692ebe0@mailsv4.y.ecl.ntt.co.jp> Subject: Re: Moving forward with the CCAMP charter Date: Thu, 18 Aug 2005 10:42:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Hi Wataru, > I believe that my draft includes some issues which have not addressed in > bernsteins draft. > For example, the issue of section 5 in my draft. > This is important issue when LCAS&VCAT will be applied in MRN. > > I understand your proposal is my requirement draft > draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt > will be merged with draft-bernstein-ccamp-.... > or simply discard ? As I said in my original email... >>- Why isn't my I-D also cited as input material? >> No insult intended. The current list is simply there to >> show the ADs that work is already in progress. All I-Ds >> will be used as input. Nothing of value will be thrown away. All input to working group drafts is welcome whether it is supplied as comments on the email list or as a separate I-D. With regard to your section 5, I note that you consider the VCAT group analogous with a link bundle. I don't think this is correct because the members of a link bundle must be selected and used individually. A payload data stream cannot be distributed across multiple component links of the bundle... An LSP with a bandwidth requirement b and setup priority p fits in a bundled link if at least one component link has maximum LSP bandwidth >= b at priority p. However, the whole point of a VCAT group is to produce a single entity (pipe) with maximum LSP bandwidth greater than the capacity of any individual component. A VCAT group, therefore, is not a bundle. Following on from this, I think that the remainder of your section 5.1 will have some value, but needs to be corrected to properly reflect the meaning of a VCAT group. In general, I think your section 5 should generalize from the specific case of the FA to include any TE link that is based on a VCAT group. Section 5.2 seems to confuse "FA" with "FA LSP". Regards, Adrian From owner-ccamp@ops.ietf.org Thu Aug 18 09:50:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5kmr-0006ke-Ay for ccamp-archive@megatron.ietf.org; Thu, 18 Aug 2005 09:50: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 JAA05162 for ; Thu, 18 Aug 2005 09:50:27 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5lMV-0001AM-5L for ccamp-archive@ietf.org; Thu, 18 Aug 2005 10:27:26 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5kfF-0009Dq-QS for ccamp-data@psg.com; Thu, 18 Aug 2005 13:42:37 +0000 Received: from [139.63.192.207] (helo=ds07.tnoase.telecom.tno.nl) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5kfE-0009DT-2R for ccamp@ops.ietf.org; Thu, 18 Aug 2005 13:42:36 +0000 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: Requesting a LSC LSP across a PCS interface Date: Thu, 18 Aug 2005 15:42:31 +0200 Message-ID: <81FEC275650AE14EBD5245E624762B9701ACED61@ds07.tnoase.telecom.tno.nl> Thread-Topic: Requesting a LSC LSP across a PCS interface Thread-Index: AcWj+q668kf02/19QsCNVkffgXoI2g== From: To: 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.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Hi all, Consider the following situation: Domain A <=3D | =3D> Domain B <=3D | =3D> Domain = C | | [A1]--PSC--[A2]--PSC--[B1]--LSC--[B2]--LSC--[B4]--PSC--[C1] | | | | |---PSC--[B3]--PSC---| Suppose I want to setup an (PSC) LSP from [A1] to [C1]. In domain B there are two options, the PSC route, or the LSC route. Is there a way to request (or hint for) a LSC LSP in domain B for the A1-C1 LSP? For example because the quality of the PSC path is deemed insufficient from the point of view of domains A and C (e.g. A and C are vey high bw LAN enviroments, B a WAN environment). Thanks! cheers, Eduard From owner-ccamp@ops.ietf.org Thu Aug 18 16:20:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qs4-0007OM-Ty for ccamp-archive@megatron.ietf.org; Thu, 18 Aug 2005 16:20: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 QAA01531 for ; Thu, 18 Aug 2005 16:20:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5rRn-0005cp-Bz for ccamp-archive@ietf.org; Thu, 18 Aug 2005 16:57:17 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5qg6-0000Rj-MJ for ccamp-data@psg.com; Thu, 18 Aug 2005 20:07:54 +0000 Received: from [47.129.242.56] (helo=zcars04e.ca.nortel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5qg2-0000R1-GU for ccamp@ops.ietf.org; Thu, 18 Aug 2005 20:07:50 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7IK5tZ22544; Thu, 18 Aug 2005 16:05:55 -0400 (EDT) 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_01C5A430.48FA5368" Subject: RE: Responding to the OIF Date: Thu, 18 Aug 2005 16:06:13 -0400 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A1713F2@zcarhxm0.corp.nortel.com> Thread-Topic: Responding to the OIF Thread-Index: AcWec2jLWKQ51KG2TrmueCxhk3p2/wFvNy9Q From: "Evelyne Roch" To: "Adrian Farrel" , 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_30_40, HTML_MESSAGE,HTML_TEXT_AFTER_BODY,HTML_TEXT_AFTER_HTML autolearn=no version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 75ffc14afb41eeead069d201c6c1d81f This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A430.48FA5368 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Regarding the following points: =20 1. From the examples below, STS3c and VC4 have different RCC/NCC values. Clarifications on which values should be used for SONET/SDH interworking would be useful. 5. Is a change in the presence/absence of ResvConf considered a trigger message? My interpretation of the text below is that a refresh resv message containing a RESV_CONF object would not result in the generation of a RESV_CONF message, RESV_CONF messages only being sent on trigger resv message. Is that correct? =20 =20 Regards, Evelyne Roch=20 Control Plane Software=20 Nortel Networks=20 PO Box 3511 STN C Ottawa ON K1Y 4H7=20 * Phone: (613) 763-6492 (esn 393)=20 * e-mail [mailto:eroch@nortel.com]=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, August 11, 2005 8:43 AM To: ccamp@ops.ietf.org Subject: Responding to the OIF =09 =09 Hi, =09 As Lyndon noted in Paris, the OIF has sent us a communication requesting some guidance on a bunch of questions. =09 This is to start the business of constructing a reply. thanks to Dimitri for supplying some of this text. =09 Please send comments and improvements. =09 Adrian =09 =3D=3D=3D=3D=3D=3D =09 To: Jim Jones, OIF Technical Committee Chair From: Adrian Farrel and Kireeti Kompella,=20 WG Co-Chairs for IETF CCAMP Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors Subject: Response to your questions about GMPLS parameters. =09 Dear Jim, =09 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. =20 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 >=20 > 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. >=20 > 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). =09 This question about RFC 3946 was raised informally on the CCAMP mailing list at the start of March this year.=20 =09 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. =09 From the examples in the annex we have... =09 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 =09 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 =09 Your question probably arises from the two notes and subsequent paragraph in section 2.1 or RFC 3946. Here it says... =09 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. =09 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. =09 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. =09 We believe that this final sentence should read "greater than or equal to 1," and that this interpretation resolves all of your issues and makes the text consistent with the examples. =09 > 2. Setting of NVC for VCAT connections >=20 > 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. =09 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. =09 > 3. Length of the Interface Switching Capability TLV >=20 > 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. >=20 > 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)." =20 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. =20 > 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. =20 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. =20 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=20 LSP b/w 2 4 bytes=20 LSP b/w 3 4 bytes=20 LSP b/w 4 4 bytes=20 LSP b/w 5 4 bytes=20 LSP b/w 6 4 bytes=20 LSP b/w 7 4 bytes min b/w 4 bytes indication 1 byte =3D=3D 41 bytes =20 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. =20 It is an implicit field, and should not be included in the length of the TLV. =20 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. =20 > 4. Use of ADMIN_STATUS in an initial PATH message >=20 > 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: >=20 > "The absence of the object is equivalent to receiving an object containing > values all set to zero (0)." >=20 > 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. =20 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. =20 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. =20 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. =20 > 5. Handling of multiple received ResvConf Request objects >=20 > 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. >=20 > 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. =20 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. =20 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. =20 Thus, an 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. > 6. Symmetry of Refresh Reduction usage >=20 > 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. >=20 > 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. >=20 > Comment from CCAMP WG on the correct interpretation is requested. =20 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.=20 =20 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. =20 In summary: - An LSR must not send refresh reduction options or messages=20 to an LSR that is not setting the refresh-reduction-capable=20 bit. - An LSR may send refresh reduction options or messages =20 to an LSR that is setting the refresh-reduction-capable bit. - An LSR that wishes to successfully use responded refresh=20 reduction options or messages should set the refresh- reduction-capable bit. =20 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." =09 > 7. Sending of ACKs bundled with the RSVP HELLO >=20 > 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. >=20 > 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. =20 You use of the terms "bundled" and "piggybacked" are contradictory. =20 "Bundled" implies the use of the Bundle message. RFC 2961 states... A sub-message MAY be any message type except for another=20 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.) =20 Further, RFC 3209 states... A Hello message may be included as a sub-message within a bundle message. =20 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. =20 On the other hand, "piggybacked" implies the use of the Ack/Nack objects within a Hello message. =20 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... =20 ::=3D [ ] =20 Since RFC 3209 post-dates RFC 2961, this definition is definitive and the Ack/Nack objects should not be present on the Hello message. =20 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. =20 > 8. TSPEC format to be used for Ethernet connections =20 The CCAMP working group is currently discussing the use of GMPLS for control of Ethernet devices. We will respond to this point in a separate email. Best regards, Adrian Farrel Kireeti Kompella ------_=_NextPart_001_01C5A430.48FA5368 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
Regarding the following = points:
 
1. From the examples below, STS3c and VC4 have different = RCC/NCC=20 values. Clarifications on which values should be used for SONET/SDH = interworking would be useful.
5. Is=20 a change in the presence/absence of ResvConf considered a=20 trigger message?  My interpretation of the text below is that = a=20 refresh resv message containing a RESV_CONF object would not result in = the=20 generation of a RESV_CONF message, RESV_CONF messages only being = sent=20 on trigger resv message. Is that correct?
 
 
Regards,

Evelyne = Roch=20
Control Plane=20 Software
Nortel Networks
PO Box 3511 STN C Ottawa ON K1Y=20 4H7
( Phone: (613) 763-6492 = (esn=20 393)
, e-mail [mailto:eroch@nortel.com]=20

-----Original Message-----
From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Adrian Farrel
Sent: Thursday, August 11, 2005 8:43=20 AM
To: ccamp@ops.ietf.org
Subject: Responding to = the=20 OIF

Hi,

As Lyndon noted in = Paris, the OIF=20 has sent us a communication requesting some guidance on a bunch of=20 questions.

This is to start the business of constructing a = reply.=20 thanks to Dimitri for supplying some of this text.

Please send = comments=20 and improvements.

Adrian

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

To: = Jim Jones, OIF=20 Technical Committee Chair
From: Adrian Farrel and Kireeti Kompella, =
          WG = Co-Chairs for=20 IETF CCAMP
Copy: Alex Zinin and Bill Fenner, IETF Routing Area=20 Directors
Subject: Response to your questions about GMPLS=20 parameters.

Dear Jim,

Thanks for your correspondence = about the=20 questions with respect to GMPLS parameters that arose before and = during your=20 interoperability testing. CCAMP is pleased to receive such questions = and is=20 glad to have the opportunity to explain the intended operation of the = GMPLS=20 protocols.
 
Much of the material supplied below = can be=20 simply extracted from the relevant RFCs.


> 1. Use of the NCC and RCC fields for STS-3c/VC-4=20 connections
>
> During OIF testing it was noted that some = ambiguity exists in the
> specification of encoding of NCC, RCC = and NVC=20 for certain types of
> connections: NCC and RCC for an = STS-3c/VC-4=20 connection can be set to 0 or
> to 1 depending on which example = of RFC=20 3946 is followed.
>
> Clarification is requested from = IETF CCAMP=20 as to which setting is
> considered correct, or if both settings = should=20 be accepted (this procedure
> was used during testing at=20 Supercomm).

This question about RFC 3946 was raised informally = on the=20 CCAMP mailing list at the start of March this year.

Even when = the=20 signal Type value is the same (i.e. value 6) the NCC, RCC and NVC = values=20 depend on the specific signal being requested.

From the = examples in the=20 annex we have...

   A VC-4 signal is formed by = applying the=20 following
   settings to a VC-4 Elementary=20 Signal.
      RCC =3D=20 0
      NCC =3D = 0
     =20 NVC =3D 0
      MT  =3D=20 1
      T   =3D = 0

   An=20 STS-3c SPE signal is formed by applying the following
   = settings=20 to an STS-3c SPE Elementary Signal.
      = RCC =3D 1=20 (standard contiguous concatenation)
      = NCC =3D=20 1
      NVC =3D = 0
     =20 MT  =3D 1
      T   =3D = 0

Your=20 question probably arises from the two notes and subsequent paragraph = in=20 section 2.1 or RFC 3946. Here it says...

   Note 1: = when=20 requesting a SONET STS-Nc SPE with N=3D3*X,=20 the
      Elementary Signal to use must = always be=20 an STS-3c_SPE signal type
      and the = value of=20 NCC must always be equal to X.  This allows=20 also
      facilitating the interworking = between=20 SONET and SDH.  In
      particular, = it means=20 that the contiguous concatenation of = three
     =20 STS-1 SPEs can not be requested because according to=20 this
      specification, this type of = signal must=20 be coded using the STS-3c
      SPE signal = type.

   Note 2: when requesting a transparent = STS-N/STM-N=20 signal
      limited to a single = contiguously=20 concatenated STS-Nc_SPE/VC-4-Nc,
      the = signal=20 type must be STS-N/STM-N, RCC with flag 1 and NCC=20 set
      to 1.

   The = NCC value=20 must be consistent with the type of contiguous
   = concatenation=20 being requested in the RCC field.  In particular, = this
  =20 field is irrelevant if no contiguous concatenation is requested=20 (RCC
   =3D 0), in that case it must be set to zero when = sent, and=20 should be
   ignored when received.  A RCC value = different=20 from 0 must imply a
   number of contiguous components = greater=20 than 1.

We believe that this final sentence should read = "greater than=20 or equal to 1," and that this interpretation resolves all of your = issues and=20 makes the text consistent with the examples.

> 2. Setting of = NVC for=20 VCAT connections
>
> It was also noted that the setting = of NVC=20 may be somewhat ambiguous for
> the case where diverse = connections are=20 used within a single VCAT group.
> Each individual RSVP session = controls=20 a single connection, but the
> connection is part of a larger = VCAT group=20 and carries VCAT encoding of the
> H4 byte. Clarification is = requested=20 from IETF CCAMP and ITU-T Q.14/15 as
> to the correct setting of = NVC for=20 this case (0 or 1?). It should be noted
> that this case may = occur with=20 a VCAT group with only a single initial
> member, and that the = NVC may=20 provide an indication that VCAT encoding of
> the H4 byte is in = use for=20 the connection.

A VCn-Xv group split into X components requires = each of=20 its component to be signaled with the NVC value set to 1. This setting = is=20 regardless of how the components are established.

> 3. = Length of the=20 Interface Switching Capability TLV
>
> Although the = Interface=20 Switching Capability TLV defined by CCAMP for
> SONET/SDH = connections=20 was not used for the testing, it was noted that the
> text = describing=20 the length of the Interface Switching Capability TLV
> defined = in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly
>=20 ambiguous due to the use of padding bytes.
>
> RFC 3630 = states=20 that "The TLV is padded to four-octet alignment; padding
> is = not=20 included in the length field (so a three octet value would have = a
>=20 length of three, but the total size of the TLV would be eight=20 octets)."
 
Yes. Section 2.3.2 of RFC3630 gives = a=20 definitive statement of the meaning of the length field and the use of = padding, and provides an example.
 
> Reading of the encoding in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
> specifies that = the=20 length of the TLV for TDM is 41 bytes plus 3 bytes of
> padding, = and=20 should be given in the length field as 41 bytes rather than
> = 44. OIF=20 requests verification of this interpretation from the experts = in
> IETF=20 CCAMP group.
 
Note that the Interface Switching Capability Descriptor defined = in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link = TLV.=20 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=20
  LSP b/w 2  4 bytes=20
  LSP b/w 3  4 bytes=20
  LSP b/w 4  4 bytes=20
  LSP b/w 5  4 bytes=20
  LSP b/w 6  4 bytes=20
  LSP b/w 7  4=20 bytes
  min b/w    4 bytes
  indication 1=20 = byte
           = ; =3D=3D
=
           &n= bsp;41=20 bytes
 
We presume that your question relates to whether the 3-byte field = shown=20 as "padding" in the TDM-specific figure on page 6 of=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an = explicit=20 field.
 
It is an implicit field, and should not be included in the length = of the=20 TLV.
 
Nevertheless, we take this = opportunity to=20 remind the OIF that implementations of GMPLS protocols should be = conservative=20 in what they send and liberal in what they receive. Thus, an = implementation=20 that receives a TDM ISCD TLV with length 44 should not reject the TLV = for this=20 reason. It should parse the TLV according to the defined fields and = skip the=20 final three bytes. Thus, it should not affect a receiving = implementation if=20 the sending implementation has treated the "padding" field as implicit = or=20 explicit. In the event that a receiving implementation rejected such a = TLV on=20 grounds of the value contained in the length field being too large, = the fault=20 would lie with the receiving implementation not the sending=20 implementation.
 
> 4. Use of ADMIN_STATUS in an = initial PATH=20 message
>
> Some implementations sent an ADMIN_STATUS = object with=20 no flags set in the
> initial PATH message, i.e., when no status = change=20 was being requested.
> Although this did not serve any = particular=20 function, it was believed that
> this could be accepted as = RFC3473,=20 sect. 7.2 (page 18) states:
>
> "The absence of the = object is=20 equivalent to receiving an object containing
> values all set to = zero=20 (0)."
>
> It was our interpretation based on this text = that a=20 node should accept an
> ADMIN_STATUS object with no flags set in = the=20 same way as if the object was
> missing. Comment on this = interpretation=20 is welcome.
 
The effect of the meaning is as you = state, but=20 the intention of the meaning is reversed. That is, an implementation = should=20 accept the absence of the ADMIN_STATUS object in the same way as if = the object=20 was present with no flags set. That is, the default behavior is to = consider=20 the ADMIN_STATUS object as a standard part of the = processing.
 
We note from your first paragraph = that you=20 assume that the ADMIN_STATUS object is used to change the status of = the LSP.=20 This is a misinterpretation - it is used to control the status of the = LSP.=20 Thus, if there is no change to the status of an LSP, refresh messages = must=20 continue to carry the ADMIN_STATUS object with the same bit=20 setting.
 
In this way, it is not possible to = "drop" the=20 ADMIN_STATUS object without having the same meaning as transmitting = the object=20 with all bits cleared.
 
> 5. Handling of multiple = received ResvConf=20 Request objects
>
> When a connection desires a = confirmation that=20 the service (i.e.
> connection) requested is in place, a = RESV_CONF_REQ=20 object is included in
> the RESV message. As this object is = received by=20 the remote end of the
> reservation, it will send a RESV_CONF = message=20 back to the requester.
>
> However, it is unclear whether = it is=20 necessary to send a RESV_CONF message
> when the RSVP connection = state=20 is refreshed by subsequent RESV. This
> becomes potentially = burdensome,=20 especially when the reservation is being
> rapidly refreshed. = Therefore=20 we ask: should the remote end send a
> RESV_CONF message for = subsequent=20 RESV messages that still include the
> RESV_CONF_REQ object? Or = is it=20 required that the requestor of the
> reservation remove the=20 RESV_CONF_REQ object to prevent the generation of
> further = RESV_CONF=20 messages? Comment on this issue from IETF CCAMP is
>=20 requested.
 
It is fundamental to = the implementation of=20 RSVP-TE that there is a good understanding of the distinction between = a=20 trigger message and a refresh message. This can be achieved by reading = section=20 1.1 of RFC2961.
 
Following this understanding, you = will note=20 that a refresh message does not cause any processing to be performed = at the=20 LSR that receives it (in this case the ingress). You will also note = that=20 refresh processing is not end-to-end as implied in your text, but is=20 hop-by-hop.
 
Thus, an downstream LSR that wishes = to trigger=20 a new ResvConf message must make a specific change to the content of = the Resv=20 message that it sends in order to cause a trigger message to be = propagated=20 through the network to the ingress LSR. Such processing is = implementation=20 specific.

> 6. Symmetry of Refresh Reduction usage
>
> = During=20 interop testing, we ran into a conflict caused by varying
>=20 interpretations of RFC2961, regarding the use of SRefresh messages and = the
> Refresh Reduction capabilities of the two ends of a given = link.=20 One
> interpretation of RFC2961 indicates that setting the = Refresh=20 Reduction
> Capability flag in the RSVP header indicates that = that=20 interface shall be
> capable of receiving messages related to = Refresh=20 Reduction - including the
> SRefresh message. This would be true = even if=20 the other end of the link for
> that interface were NOT = indicating=20 Refresh Reduction Capability, since the
> RFC makes no statement = about=20 symmetry in this matter.
>
> Another interpretation is = that both=20 ends of an interface must indicate
> Refresh Reduction = Capability before=20 either end can use such messages, i.e,
> use of Refresh = Reduction on a=20 link is symmetric.
>
> Comment from CCAMP WG on the = correct=20 interpretation is requested.
 
We are confused by your question.
You correctly state that the use of the refresh-reduction-capable = bit=20 indicates the ability of an LSR to support the receipt of refresh = reduction=20 options and messages. To quote from section 2 of RFC2961...
           When = set,=20 indicates that this node is willing and capable=20 of
           = receiving=20 all the messages and objects described in=20 this
          =20 document.  This includes the Bundle message described=20 in
           = Section 3,=20 the MESSAGE_ID objects and Ack messages=20 = described
          = in=20 Section 4, and the MESSAGE_ID LIST objects and=20 = Srefresh
           = message described in Section 5.  This bit is meaningful=20 only
           = between=20 RSVP neighbors.
This makes no statement about whether the LSR = intends to=20 use these options when communicating with another LSR.
 
However, you will note that some refresh reduction procedures = require=20 that a message is sent and response returned. In order to make use of = the=20 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=20 refresh reduction options and messages to also set the=20 refresh-reduction-capable bit.
 
In summary:
- An LSR must not send refresh reduction options or=20 messages 
  to an LSR that is not setting the = refresh-reduction-capable
  bit.
- An LSR may send refresh reduction options or messages =20
  to an LSR that is setting the = refresh-reduction-capable=20 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=20 not known if a next hop supports the extension, standard Path and Resv = message=20 based refreshes MUST be used."
> 7. Sending of ACKs bundled with the RSVP HELLO
> =
>=20 During interop testing, it was observed that Message Acks were=20 piggybacked
> onto RSVP Hello messages, when the receiving end = was not=20 using the Hello
> protocol. In this situation, the incoming = Hello's were=20 discarded and the
> Acks were lost.
>
> We believe = that=20 Message Acks should only be piggybacked onto mandatory
> = messages, and=20 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=20 another
   Bundle message.
Thus, Ack messages may be bundled with other messages. (Although = one=20 might consider this perverse since the Ack message is only introduced = to=20 handle the case when the Ac/Nack objects have no other message on = which they=20 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=20 together.
The processing rules (RFC 29610 for Bundled messages are such = that each=20 sub-message is processed in its own right, and the non-support/non-use = of=20 Hello messages should not impact the processing of other = messages.
 
On the other hand, "piggybacked" implies the use of the Ack/Nack = objects=20 within a Hello message.
 
Section 4.1 of RFC2961 states that Ack/Nack objects may be = included in=20 the "standard" RSVP messages, and shows where they are placed. = However, RFC=20 3209 defines the Hello message as not including the Ack/Nack = objects...
 
   <Hello Message> ::=3D <Common Header> [=20 <INTEGRITY>=20 = ]
           &n= bsp;           &nb= sp;     =20 <HELLO>
 
Since RFC 3209 post-dates RFC 2961, this definition is definitive = and the=20 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=20 may be
   ignored by nodes which do not wish to = participate in=20 Hello message
   processing.
...it is not particularly important what the message format rules = are. An=20 implementation that chooses to place an Ack/Nack object in a Hello = message=20 knows that the object might be discarded unprocessed.
 
> 8. TSPEC format to be used for Ethernet connections
 
The CCAMP working group is currently discussing the use of GMPLS = for=20 control of Ethernet devices. We will respond to this point in a = separate=20 email.

Best regards,
Adrian Farrel
Kireeti Kompella
=00 ------_=_NextPart_001_01C5A430.48FA5368-- From owner-ccamp@ops.ietf.org Thu Aug 18 17:05:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5rZc-0000kO-3d for ccamp-archive@megatron.ietf.org; Thu, 18 Aug 2005 17:05: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 RAA03284 for ; Thu, 18 Aug 2005 17:05:13 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5s9O-0006hX-H7 for ccamp-archive@ietf.org; Thu, 18 Aug 2005 17:42:17 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5rTn-0004fB-0I for ccamp-data@psg.com; Thu, 18 Aug 2005 20:59:15 +0000 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5rTl-0004et-04 for ccamp@ops.ietf.org; Thu, 18 Aug 2005 20:59:13 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7IKx9NA001872; Fri, 19 Aug 2005 05:59:09 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7IKx87p006730; Fri, 19 Aug 2005 05:59:08 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7IKx8db006725; Fri, 19 Aug 2005 05:59:08 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7IKx7wD010624; Fri, 19 Aug 2005 05:59:07 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7IKx7xF010621; Fri, 19 Aug 2005 05:59:07 +0900 (JST) Received: from dmailsv1.y.ecl.ntt.co.jp (dmailsv1.y.ecl.ntt.co.jp [129.60.53.14]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7IKx7QI015828; Fri, 19 Aug 2005 05:59:07 +0900 (JST) Received: from mailsv04.y.ecl.ntt.co.jp by dmailsv1.y.ecl.ntt.co.jp (8.13.4/dmailsv-1.4) with ESMTP id j7IKx6HN019927; Fri, 19 Aug 2005 05:59:06 +0900 (JST) Received: from localhost by mailsv04.y.ecl.ntt.co.jp (8.13.4/Lab-1.5) with ESMTP id j7IKx6E4005246; Fri, 19 Aug 2005 05:59:06 +0900 (JST) Message-Id: <5.1.1.9.2.20050819055127.05675bc8@mailsv4.y.ecl.ntt.co.jp> X-Sender: wi002@mailsv4.y.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Fri, 19 Aug 2005 05:59:21 +0900 To: "Adrian Farrel" , From: Wataru Imajuku Subject: Re: Moving forward with the CCAMP charter In-Reply-To: <048301c5a3e7$74538290$4f849ed9@Puppy> References: <5.1.1.9.2.20050818095638.0692ebe0@mailsv4.y.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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=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: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Hi, Adrian Thank you for giving your time interim your hard work. >With regard to your section 5, I note that you consider the VCAT group >analogous with a link bundle. I don't think this is correct because the >members of a link bundle must be selected and used individually. A payload >data stream cannot be distributed across multiple component links of the >bundle... > An LSP with a bandwidth requirement b and > setup priority p fits in a bundled link if at least one component > link has maximum LSP bandwidth >= b at priority p. >However, the whole point of a VCAT group is to produce a single entity >(pipe) with maximum LSP bandwidth greater than the capacity of any >individual component. A VCAT group, therefore, is not a bundle. > >Following on from this, I think that the remainder of your section 5.1 >will have some value, but needs to be corrected to properly reflect the >meaning of a VCAT group. > >In general, I think your section 5 should generalize from the specific >case of the FA to include any TE link that is based on a VCAT group. > >Section 5.2 seems to confuse "FA" with "FA LSP". Regarding to VCAT, I agree to your comment. But, this draft also covers LAGR (link aggregation) which has some limitations to transmit data-flow exceeding the bandwidth of each comopnent LSP. This is one of reason why the description wirtten in Section 5 exists, although some terminologies are not proper as you noted. Thanks Wataru --------------------------------- Wataru Imajuku Senior Research Engineer @NTT Network Innovation Labs. TEL +81-46-859-4315 FAX +81-46-859-5541 From owner-ccamp@ops.ietf.org Thu Aug 18 17:49:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5sGd-0004Mc-Gz for ccamp-archive@megatron.ietf.org; Thu, 18 Aug 2005 17:49: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 RAA05411 for ; Thu, 18 Aug 2005 17:49:40 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5sqN-0007zA-NG for ccamp-archive@ietf.org; Thu, 18 Aug 2005 18:26:45 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5sAn-0008BH-EL for ccamp-data@psg.com; Thu, 18 Aug 2005 21:43:41 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5sAm-0008B4-Nq for ccamp@ops.ietf.org; Thu, 18 Aug 2005 21:43:40 +0000 Received: from du-069-0037.access.clara.net ([217.158.132.37] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E5sAl-0007sf-6z; Thu, 18 Aug 2005 22:43:40 +0100 Message-ID: <055c01c5a43e$43aa2980$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Evelyne Roch" , References: <29D15BBCA340DA4D8146D38B4924FC7A1713F2@zcarhxm0.corp.nortel.com> Subject: Re: Responding to the OIF Date: Thu, 18 Aug 2005 22:43: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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Hi Evelyne, > 1. From the examples below, STS3c and VC4 have different > RCC/NCC values. Clarifications on which values should be > used for SONET/SDH interworking would be useful. I have a couple of folks looking at this for me because I can't tell the difference between a timeslice and a cakeslice. Hopefully they will generate a response soon. > 5. Is a change in the presence/absence of ResvConf considered a > trigger message? Yes, it would be a trigger message (that is, it would not be treated as a simple refresh). But a "trigger message" does not necessarily cause any action. > My interpretation of the text below is that a refresh resv > message containing a RESV_CONF object would not > result in the generation of a RESV_CONF message, > RESV_CONF messages only being sent on trigger > resv message. Is that correct? Seems reasonable to me. That way the ResvConf confirms the receipt of the changed Resv. I guess I should have added a note that a ResvConf message is not necessarily reliably delivered. 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. Adrian From owner-ccamp@ops.ietf.org Thu Aug 18 18:23:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5sn6-000676-Lc for ccamp-archive@megatron.ietf.org; Thu, 18 Aug 2005 18:23: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 SAA08105 for ; Thu, 18 Aug 2005 18:23:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5tMu-0000Ui-Qv for ccamp-archive@ietf.org; Thu, 18 Aug 2005 19:00:17 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5siZ-000BJv-FS for ccamp-data@psg.com; Thu, 18 Aug 2005 22:18:35 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5siY-000BJf-9h; Thu, 18 Aug 2005 22:18:34 +0000 Message-ID: <4305092B.2000906@psg.com> Date: Fri, 19 Aug 2005 00:18:19 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: E.T.Metz@telecom.tno.nl CC: ccamp@ops.ietf.org Subject: Re: Requesting a LSC LSP across a PCS interface References: <81FEC275650AE14EBD5245E624762B9701ACED61@ds07.tnoase.telecom.tno.nl> In-Reply-To: <81FEC275650AE14EBD5245E624762B9701ACED61@ds07.tnoase.telecom.tno.nl> 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit hi, > Consider the following situation: > > Domain A <= | => Domain B <= | => Domain C > | | > [A1]--PSC--[A2]--PSC--[B1]--LSC--[B2]--LSC--[B4]--PSC--[C1] > | | | | > |---PSC--[B3]--PSC---| > > > Suppose I want to setup an (PSC) LSP from [A1] to [C1]. In domain B > there are two options, the PSC route, or the LSC route. Is there a way > to request (or hint for) a LSC LSP in domain B for the A1-C1 LSP? For > example because the quality of the PSC path is deemed insufficient from > the point of view of domains A and C (e.g. A and C are vey high bw LAN > enviroments, B a WAN environment). base on your diagram and assuming symmetric links both nodes B1 and B4 must have a PSC and LSC switching capability so here and as provided in the diagram i assume the boundary is on the node; however, if you mean [B1,B4] and [B2,B4] being [PSC,LSC] and [LSC,PSC] resp. then B1 and B4 are simple PSC nodes with LSC interfaces and then the boundary would be on the interface now, if all domains are in the same routing area - have strict path all along - B4 loose hop with explicit indication of incoming interface if all domains not in the same routing area - make use of constaint passing by including (or excluding) specific switching capability such as to indicate which resource type to select/preclude in order to reach the destination B4 (loose hop) hope this helps, - dimitri. > Thanks! > > cheers, > Eduard > > > > . > From owner-ccamp@ops.ietf.org Thu Aug 18 18:44:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5t7n-0003aW-1Y for ccamp-archive@megatron.ietf.org; Thu, 18 Aug 2005 18:44: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 SAA09182 for ; Thu, 18 Aug 2005 18:44:36 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5thb-00014b-Sv for ccamp-archive@ietf.org; Thu, 18 Aug 2005 19:21:41 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5t4N-000Ctc-Oh for ccamp-data@psg.com; Thu, 18 Aug 2005 22:41:07 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5t4K-000CtA-Vh; Thu, 18 Aug 2005 22:41:05 +0000 Message-ID: <43050E72.7060209@psg.com> Date: Fri, 19 Aug 2005 00:40:50 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: Evelyne Roch , ccamp@ops.ietf.org Subject: Re: Responding to the OIF References: <29D15BBCA340DA4D8146D38B4924FC7A1713F2@zcarhxm0.corp.nortel.com> <055c01c5a43e$43aa2980$4f849ed9@Puppy> In-Reply-To: <055c01c5a43e$43aa2980$4f849ed9@Puppy> 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Adrian Farrel wrote: > Hi Evelyne, > > >>1. From the examples below, STS3c and VC4 have different >> RCC/NCC values. Clarifications on which values should be >>used for SONET/SDH interworking would be useful. > > I have a couple of folks looking at this for me because I can't tell the > difference between a timeslice and a cakeslice. > > Hopefully they will generate a response soon. this may help - "A dedicated signal type is assigned to a SONET STS-3c SPE instead of coding it as a contiguous concatenation of three STS-1 SPEs. This is done in order to provide easy interworking between SONET and SDH signaling." also the RFC explains how the negotiation occurs (RCC/NCC selection is a local decision process depending on the supported capabilities) - not a big deal here, there are 4 cases possible: - symmetric fixed case either SDH or SONET on both sides, there is no interworking issue possible - symmetric configurable case (assumption taken by OIF) where selection is not impacting establishment, there is no interworking issue possible - asymmetric fixed-configurable case: the upstream node drives the selection by indicating the selected values, there is no interworking issue possible - asymmetric configurable-fixed case: an error is generated if the config supported by the fixed side is not selected by the upstream node but signaling just follows result of the selection - however, GMPLS signaling can not correct this in any case - >>5. Is a change in the presence/absence of ResvConf considered a >>trigger message? > > > Yes, it would be a trigger message (that is, it would not be treated as a > simple refresh). But a "trigger message" does not necessarily cause any > action. > > >>My interpretation of the text below is that a refresh resv >>message containing a RESV_CONF object would not >>result in the generation of a RESV_CONF message, >>RESV_CONF messages only being sent on trigger >>resv message. Is that correct? > > > Seems reasonable to me. > That way the ResvConf confirms the receipt of the changed Resv. > > I guess I should have added a note that a ResvConf message is not > necessarily reliably delivered. 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. > > Adrian > > > > . > From owner-ccamp@ops.ietf.org Thu Aug 18 19:14:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5taq-0007Z4-Uz for ccamp-archive@megatron.ietf.org; Thu, 18 Aug 2005 19:14: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 TAA13555 for ; Thu, 18 Aug 2005 19:14:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5uAY-0002uV-SK for ccamp-archive@ietf.org; Thu, 18 Aug 2005 19:51:43 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5tVW-000FTa-M4 for ccamp-data@psg.com; Thu, 18 Aug 2005 23:09:10 +0000 Received: from [63.118.39.27] (helo=mdmxm02.ciena.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5tVV-000FTK-UT for ccamp@ops.ietf.org; Thu, 18 Aug 2005 23:09:10 +0000 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: Moving forward with the CCAMP charter Date: Thu, 18 Aug 2005 19:08:55 -0400 Message-ID: <0901D1988E815341A0103206A834DA07613F9A@mdmxm02.ciena.com> Thread-Topic: Moving forward with the CCAMP charter Thread-Index: AcWilg75TdCjxl3eTNOrTkDcUO9BPQBsYjFg From: "Ong, Lyndon" To: "Adrian Farrel" , , Cc: , , "Kireeti Kompella" 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Hi Adrian, As with everyone else, I appreciate all of the work that you put in to create a very detailed workplan for the group. Some follow up questions and suggestions:=20 -- On the "aligning GMPLS across standards bodies" item: First of all, what standards bodies do you see included under this effort? =20 Also, are you intending this to be a unilateral document on ccamp's part? If it is, I'm not sure I see what it would say besides "use the RFCs or bring the requirements back to us", which is what this group has said in the past. If on the other hand you see this as the basis for joint discussion with other bodies, it might be a very helpful activity. -- On the ""routing and signaling for complex optical constraints" item: The ashwood draft seems to me to have two components, one being=20 requirements and considerations of routing across a purely photonic domain and the second being a particular solution (the matrix representation), to which there are alternatives such as the virtual link approach that Igor has identified. =20 I think these two should probably be separated, as the solution may be=20 more widely applied to any situation of advertising a virtualized=20 topology, such as in enhanced l1vpn. Cheers, Lyndon From owner-ccamp@ops.ietf.org Fri Aug 19 04:46:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E62We-0006ti-OP for ccamp-archive@megatron.ietf.org; Fri, 19 Aug 2005 04:46:56 -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 EAA20876 for ; Fri, 19 Aug 2005 04:46:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E636X-0001WQ-HP for ccamp-archive@ietf.org; Fri, 19 Aug 2005 05:24:04 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E62Qf-0008xW-Rl for ccamp-data@psg.com; Fri, 19 Aug 2005 08:40:45 +0000 Received: from [213.46.243.15] (helo=amsfep17-int.chello.nl) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E62Qb-0008x3-Ba for ccamp@ops.ietf.org; Fri, 19 Aug 2005 08:40:41 +0000 Received: from [192.168.1.3] (really [24.132.27.149]) by amsfep17-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050819084023.VNHC14362.amsfep17-int.chello.nl@[192.168.1.3]>; Fri, 19 Aug 2005 10:40:23 +0200 Message-ID: <43059AF0.3030006@chello.nl> Date: Fri, 19 Aug 2005 10:40:16 +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: ccamp CC: adrian Subject: Re: MS-SPring References: <43035143.30301@psg.com> In-Reply-To: <43035143.30301@psg.com> 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=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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Hallo Dimitri, You responded to Diego: > Diego Caviglia wrote: > >> Hi Dimitri, >> given the high number of MS-SPRing protected transport >> network >> already deployed seems reasonable to me, from a Network Operator point of >> view, to use at the same time MS-SPRing protection with GMPLS >> restoration. > > there are already two questions here 1. is there an operational need to > control such rings using GMPLS (? for instance is it effective knowing > that ring based protection is mainly data plane driven ?) and 2. how to > position the ring protection wrt to the LSP recovery segment/end-to-end > recovery The first step in MS-Spring is indeed dataplane driven (using APS) but that involves only nodes adjacent to the fault. The reconfiguration of the ring after this first switch is controlplane driven and concerns all nodes in the ring. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Fri Aug 19 05:37:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E63JB-0002Oy-NI for ccamp-archive@megatron.ietf.org; Fri, 19 Aug 2005 05:37: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 FAA22634 for ; Fri, 19 Aug 2005 05:37:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E63t1-0002w1-W5 for ccamp-archive@ietf.org; Fri, 19 Aug 2005 06:14:13 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E63Dj-000DmZ-Ki for ccamp-data@psg.com; Fri, 19 Aug 2005 09:31:27 +0000 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E63Di-000DmK-PL for ccamp@ops.ietf.org; Fri, 19 Aug 2005 09:31:26 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Fri, 19 Aug 2005 18:33:00 +0900 X-ReadCheckName: ccamp%40ops.ietf.org Thread-Topic: Moving forward with the CCAMP charter X-ReadCheckMessageID: thread-index: AcWkoP0mQI0llS9oRE2pPqaplaS5cg== Content-Transfer-Encoding: 7bit Reply-To: =?ks_c_5601-1987?B?sei/tcit?= From: =?ks_c_5601-1987?B?sei/tcit?= To: "Adrian Farrel" , Cc: , "'Kireeti Kompella'" Subject: RE: Moving forward with the CCAMP charter Date: Fri, 19 Aug 2005 18:32:59 +0900 Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBPQU2x4rz6xsAsILTjtOc=?= Message-ID: <99e101c5a4a0$fd2b4080$8310fe81@email1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_99DC_01C5A4EC.6D0E0680" 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: 19 Aug 2005 09:33:00.0115 (UTC) FILETIME=[FD4A3A30:01C5A4A0] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_00,HTML_30_40, 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.3 (+++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_99DC_01C5A4EC.6D0E0680 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ------=_NextPart_000_99DC_01C5A4EC.6D0E0680 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy Ij4NCjxESVY+SGksIDxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDA4MD5BZHJpYW4gYW5kIGNj YW1wZXJzIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDgw PkkgcHJvcG9zZSB0aGF0IHdlIGhhbmRsZSBjb250cm9sIHBsYW5lIHJlc2lsaWVuY2UgaW4gb3Vy IENDQU1QIGNoYXJ0ZXIuPC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMDgwPkkgdGhpbmsgdGhhdCB0aGUgQ0NBTVAgV0cgaXMgZm9jdXNzaW5nIG9u IHRoZSBkYXRhIGFuZCBjb250cm9sIHBsYW5lcyBmb3IgR01QTFMuPC9GT05UPjwvRElWPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwODA+VW50aWwgbm93IHdlIGhhdmUg aGFuZGxlZCB0aGUgZGF0YSBwbGFuZSBwYXJ0IGZvciByZXNpbGllbmNlLCBidXQgd2UgaGF2ZSBu byByZXN1bHRzIG9mIGNvbnRyb2wgcGxhbmUgcmVzaWxpZW5jZS48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDA4MD5JIGhhZCBwcmVzZW50ZWQgbXkgY29udHJp YnV0aW9uIGZvciByZXF1aXJlbWVudHMgb2YgY29udHJvbCBwbGFuZSByZXNpbGllbmNlIHRocm91 Z2ggZHJhZnQta2ltLWNjYW1wLWNwci1yZXF0cy0wMC50eHQgbGFzdCB5ZWFyLjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDgwPk9uIHRoZSBOb3ZlbWJlciBt ZWV0aW5nIHRoaXMgeWVhciwgSSB3aWxsIHByZXNlbnQgYW4gdXBkYXRlZCBkb2N1bWVudCBvZiBy ZXF1aXJlbWVudHMgZm9yIGNvbnRyb2wgcGxhbmUgcmVzaWxpZW5jZSAsIGFuZCBhIG5ldyBvciBl eHRlbmRlZCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGRvY3VtZW50IGZvciBjb250cm9sIHBsYW5l IHJlc2lsaWVuY2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwODA+T2YgY291cnNlLCBJIHRoaW5rIGl0J3MgcG9zc2libGUgdW5kZXIgdGhlIGNvbmRpdGlv biB0aGF0IHRoZSB0b3BpYyBvZiBjb250cm9sIHBsYW5lIHJlc2lsaWVuY2UgY291bGQgYmUgaGFu ZGxlZCBpbiB0aGUgQ0NBTVAgY2hhcnRlci48L0ZPTlQ+PC9ESVY+DQo8RElWPjxCUj4tLS0tLb/4 ursguN69w8H2LS0tLS08QlI+PEI+RnJvbTo8L0I+ICJBZHJpYW4gRmFycmVsIiAmbHQ7YWRyaWFu QG9sZGRvZy5jby51ayZndDs8QlI+PEI+RnJvbSBEYXRlOjwvQj4gMjAwNS0wOC0xNiC/wMjEIDg6 Mjg6MTE8QlI+PEI+VG86PC9CPiAiY2NhbXBAb3BzLmlldGYub3JnIiAmbHQ7Y2NhbXBAb3BzLmll dGYub3JnJmd0OzxCUj48Qj5DYzo8L0I+ICJ6aW5pbkBwc2cuY29tIiAmbHQ7emluaW5AcHNnLmNv bSZndDssICInS2lyZWV0aSBLb21wZWxsYSciICZsdDtraXJlZXRpQGp1bmlwZXIubmV0Jmd0OzxC Uj48Qj5TdWJqZWN0OjwvQj4gTW92aW5nIGZvcndhcmQgd2l0aCB0aGUgQ0NBTVAgY2hhcnRlcjxC Uj48QlI+PC9ESVY+PCEtLSBzdHlsZT48L3N0eWxlIC0tPg0KPERJViBiZ0NvbG9yPSIjZmZmZmZm IiBiYWNrZ3JvdW5kPSIiPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPkhpLDxCUj48 QlI+UGxlYXNlIGZpbmQgYXR0YWNoZWQgYSBmaWxlIHRoYXQgY29udGFpbnM6PEJSPjxCUj4tIGEg c2V0IG9mIHByb3Bvc2VkICpkcmFmdCogbWlsZXN0b25lczxCUj4tIGEgZGlzY3Vzc2lvbiBvZiB3 aHkgdGhlcmUgYXJlIHNvIG1hbnkgbWlsZXN0b25lczxCUj4tIGEgaGlnaC1sZXZlbCBleHBsYW5h dGlvbiBvZiB0aGUgd29yayBpdGVtcy48QlI+PEJSPk5vdGUgdGhhdCB0aGlzIGxvb2tzIGxpa2Ug YSBsb3Qgb2YgbWlsZXN0b25lcywgYnV0IHBsZWFzZSByZWFkIHRoZSB0ZXh0IG9uIHRoaXMgaXNz dWUgaW4gdGhlIGF0dGFjaGVkIGZpbGUuIFRoZSBib3R0b20gbGluZSBpcyB0aGF0IHRoaXMgaXMg YSBwcm9kdWN0IG9mIG1pY3JvIG1hbmFnZW1lbnQgd2hlcmUgSSBoYXZlIHRyaWVkIHRvIGlkZW50 aWZ5IGFsbCBvZiB0aGUgSS1EcyB0aGF0IHdlIG1pZ2h0IHByb2R1Y2UgdG8gY292ZXIgdGhlIHJl ZmVyZW5jZWQgd29yaywgYW5kIHdoZXJlIEkgaGF2ZSBwbGFjZWQgdHdvIChzb21ldGltZXMgdGhy ZWUpIG1pbGVzdG9uZXMgZm9yIGVhY2ggSS1ELjxCUj48QlI+VGhpcyBtaWNyby1tYW5hZ2VtZW50 IG1heSBiZSBvdmVyIHRoZSB0b3AsIGFuZCByZXByZXNlbnRzIGEgZnVsbCBwZW5kdWx1bSBzd2lu ZyBmcm9tIHRoZSBwcmV2aW91cyBzdHlsZSBvZiBDQ0FNUCBtaWxlc3RvbmVzLCBidXQgaW4gdGhl IGxpZ2h0IG9mIHRoZSBoaWF0dXMgb2YgdGhlIGxhc3QgMTIgbW9udGhzLCBpIHRoaW5rIHRoaXMg bWF5IGJlIGJlbmVmaWNpYWwgYW5kIG1pZ2h0IGFjaGlldmUgcmFwaWQgZm9yd2FyZHMgbW92ZW1l bnQuPEJSPjxCUj5JIHdvdWxkIHdlbGNvbWUgeW91ciAoY29uc3RydWN0aXZlISkgY29tbWVudHMu PEJSPjxCUj5Ob3Rlczo8QlI+LSBXaHkgaXNuJ3QgbXkgSS1EIGFsc28gY2l0ZWQgYXMgaW5wdXQg bWF0ZXJpYWw/PEJSPiZuYnNwOyBObyBpbnN1bHQgaW50ZW5kZWQuIFRoZSBjdXJyZW50IGxpc3Qg aXMgc2ltcGx5IHRoZXJlIHRvPEJSPiZuYnNwOyBzaG93IHRoZSBBRHMgdGhhdCB3b3JrIGlzIGFs cmVhZHkgaW4gcHJvZ3Jlc3MuIEFsbCBJLURzPEJSPiZuYnNwOyB3aWxsIGJlIHVzZWQgYXMgaW5w dXQuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj4tIFdoeSBpc24ndCBteSBwZXQg dG9waWMgaW5jbHVkZWQ/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6 ZT0yPiZuYnNwOyZuYnNwO0FyZSB5b3Ugc3VyZSBpdCBpcyBub3QgdGhlcmUgYmV0d2VlbiB0aGUg bGluZXM/IFRoaXMgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0y PiZuYnNwOyBsaXN0IG9mIG1pbGVzdG9uZXMgaXNuJ3QgY29tcGxldGVseSBwcm9zY3JpcHRpdmUu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPiZuYnNwOyA8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciBzaXplPTI+VGhlIG9iamVjdGl2ZSBp cyB0byBoYXZlIHRoZSBXRyBhZ3JlZWQgb24gdGhlIG1pbGVzdG9uZXMgdGhhdCBpdCB3YW50cyB0 byBjb21taXQgdG8gYnkgdGhlIGVuZCBvZiBBdWd1c3QuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUNvdXJpZXIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1Db3VyaWVyIHNpemU9Mj5UaGFua3MsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNv dXJpZXIgc2l6ZT0yPkFkcmlhbjwvRk9OVD48L0RJVj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJk aXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5r ci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1jY2FtcEBvcHMuaWV0Zi5vcmcmbmFtZT1j Y2FtcCU0MG9wcy5pZXRmLm9yZyZmcm9tZW1haWw9eWh3a2ltQGV0cmkucmUua3ImbWVzc2FnZWlk PSUzQ2FiOGIzMjQzLTQ5ZGEtNGM4Zi1iZGNhLTBlNGIwNWM5YTNlZEBldHJpLnJlLmtyJTNFIj4= ------=_NextPart_000_99DC_01C5A4EC.6D0E0680-- From owner-ccamp@ops.ietf.org Fri Aug 19 06:10:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E63pw-0002Cj-Sl for ccamp-archive@megatron.ietf.org; Fri, 19 Aug 2005 06:10: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 GAA24040 for ; Fri, 19 Aug 2005 06:10:53 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E64Pr-0003tk-Qz for ccamp-archive@ietf.org; Fri, 19 Aug 2005 06:48:05 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E63mB-000HJE-FJ for ccamp-data@psg.com; Fri, 19 Aug 2005 10:07:03 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E63mA-000HIo-PC; Fri, 19 Aug 2005 10:07:03 +0000 Message-ID: <4305AF37.2020500@psg.com> Date: Fri, 19 Aug 2005 12:06:47 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Huub van Helvoort CC: ccamp , adrian Subject: Re: MS-SPring References: <43035143.30301@psg.com> <43059AF0.3030006@chello.nl> In-Reply-To: <43059AF0.3030006@chello.nl> 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=-5.8 required=5.0 tests=ALL_TRUSTED,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: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit hi huub, Huub van Helvoort wrote: > Hallo Dimitri, > > You responded to Diego: > >> Diego Caviglia wrote: >> >>> Hi Dimitri, >>> given the high number of MS-SPRing protected transport >>> network >>> already deployed seems reasonable to me, from a Network Operator >>> point of >>> view, to use at the same time MS-SPRing protection with GMPLS >>> restoration. >> >> there are already two questions here 1. is there an operational need >> to control such rings using GMPLS (? for instance is it effective >> knowing that ring based protection is mainly data plane driven ?) and >> 2. how to position the ring protection wrt to the LSP recovery >> segment/end-to-end recovery > > The first step in MS-Spring is indeed dataplane driven (using APS) > but that involves only nodes adjacent to the fault. ok, btw, is there a reason to restrict to MS/line protection ring ? > The reconfiguration of the ring after this first switch is controlplane > driven and concerns all nodes in the ring. ok with this - like for other linear protection schemes the control plane would be involved in the provisioning also, what about the (informational) notification to maintain the control plane aware about the data plane status after failure detection and/or after the APS operation thanks, - dimitri. > Cheers, Huub. > From owner-ccamp@ops.ietf.org Fri Aug 19 06:10:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E63p5-0001uR-Qc for ccamp-archive@megatron.ietf.org; Fri, 19 Aug 2005 06:10: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 GAA24010 for ; Fri, 19 Aug 2005 06:10:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E64P1-0003sP-Go for ccamp-archive@ietf.org; Fri, 19 Aug 2005 06:47:11 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E63jl-000GzV-31 for ccamp-data@psg.com; Fri, 19 Aug 2005 10:04:33 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E63ji-000Gyx-Qn; Fri, 19 Aug 2005 10:04:31 +0000 Received: from du-069-0334.access.clara.net ([217.158.145.80] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1E63je-000K8V-Ig; Fri, 19 Aug 2005 11:04:29 +0100 Message-ID: <05c701c5a4a5$c17274f0$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: =?ks_c_5601-1987?B?sei/tcit?= , Cc: , "'Kireeti Kompella'" References: <99db01c5a4a0$fd265e80$8310fe81@email1> Subject: Control Plane Robustness [Was: Moving forward with the CCAMP charter] Date: Fri, 19 Aug 2005 11:05:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA24010 Hi, I think you are Young Hwa Kim. > I propose that we handle control plane resilience in our CCAMP > charter. Since two other drafts in the same sort of area have also been mentioned (draft-ali-ccamp-mpls-graceful-shutdown and draft-leroux-ccamp-ctrl-saturation) I think we are seeing some support fo= r a work item on control plane robustness. > I think that the CCAMP WG is focussing on the data and control > planes for GMPLS. > Until now we have handled the data plane part for resilience, but > we have no results of control plane resilience. > I had presented my contribution for requirements of control plane > resilience through draft-kim-ccamp-cpr-reqts-00.txt last year. > On the November meeting this year, I will present an updated > document of requirements for control plane resilience , and a > new or extended protocol specification document for control > plane resilience. I hope you will not wait for the November meeting. The intention of the meetings is to meet and discuss technical issues, not to act as a submission deadline for new versions of drafts. It is always helpful to publish drafts in good time and as soon as they are ready so that they ca= n be reviewed and discussed. I am surprised that you do not also mention draft-kim-ccamp-cc-protection-04.txt It would be helpful if the WG could look at your two drafts and comment. As yet there has not been wide support expressed for what you are suggesting, and I need to see a greater degree of consensus before I can bring this into the WG. Thus my feeling at the moment is that Control Plane Robustness should be an area that CCAMP looks at, but we should not set any specific milestones. Regards, Adrian > Of course, I think it's possible under the condition that the topic of control plane > resilience could be handled in the CCAMP charter. -----=A2=AF=A9=AA=A8=AC=A1=ED =A2=AC=A8=AD=A8=F6AAo----- From: "Adrian Farrel" From Date: 2005-08-16 =A2=AFAEA 8:28:11 To: "ccamp@ops.ietf.org" Cc: "zinin@psg.com" , "'Kireeti Kompella'" Subject: Moving forward with the CCAMP charter Hi, Please find attached a file that contains: - a set of proposed *draft* milestones - a discussion of why there are so many milestones - a high-level explanation of the work items. Note that this looks like a lot of milestones, but please read the text o= n this issue in the attached file. The bottom line is that this is a produc= t of micro management where I have tried to identify all of the I-Ds that w= e might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of th= e hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. I would welcome your (constructive!) comments. Notes: - Why isn't my I-D also cited as input material? No insult intended. The current list is simply there to show the ADs that work is already in progress. All I-Ds will be used as input. - Why isn't my pet topic included? Are you sure it is not there between the lines? This list of milestones isn't completely proscriptive. The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. Thanks, Adrian ----- Original Message -----=20 From: "=B1=E8=BF=B5=C8=AD" To: "Adrian Farrel" ; Cc: ; "'Kireeti Kompella'" Sent: Friday, August 19, 2005 10:32 AM Subject: RE: Moving forward with the CCAMP charter > From owner-ccamp@ops.ietf.org Fri Aug 19 07:18:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64sp-0001Wh-Rc for ccamp-archive@megatron.ietf.org; Fri, 19 Aug 2005 07:18:00 -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 HAA26779 for ; Fri, 19 Aug 2005 07:17:58 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E65SZ-0005iW-RN for ccamp-archive@ietf.org; Fri, 19 Aug 2005 07:55:05 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E64nt-000NYP-U5 for ccamp-data@psg.com; Fri, 19 Aug 2005 11:12:53 +0000 Received: from [192.51.44.35] (helo=fgwmail5.fujitsu.co.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E64nr-000NY3-W1 for ccamp@ops.ietf.org; Fri, 19 Aug 2005 11:12:52 +0000 Received: from m6.gw.fujitsu.co.jp ([10.0.50.76]) by fgwmail5.fujitsu.co.jp (Fujitsu Gateway) id j7JBCoWv008631 for ; Fri, 19 Aug 2005 20:12:50 +0900 (envelope-from nagata.akira@jp.fujitsu.com) Received: from s1.gw.fujitsu.co.jp by m6.gw.fujitsu.co.jp (8.12.10/Fujitsu Domain Master) id j7JBCn1G018155 for ; Fri, 19 Aug 2005 20:12:49 +0900 (envelope-from nagata.akira@jp.fujitsu.com) Received: from s1.gw.fujitsu.co.jp (s1 [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id BF505178146 for ; Fri, 19 Aug 2005 20:12:49 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.4]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 74B481780BB for ; Fri, 19 Aug 2005 20:12:49 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp by flabmail.flab.fujitsu.co.jp (8.9.3p2/3.7W-030703-Fujitsu Labs. Domain Mail Master (NAVGW)) id UAA18016; Fri, 19 Aug 2005 20:12:49 +0900 (JST) Received: from goofy.dream.flab.fujitsu.co.jp ([10.25.144.14]) by flabmail.flab.fujitsu.co.jp (NAVGW 2.5.2.9) with SMTP id M2005081920124829501 ; Fri, 19 Aug 2005 20:12:48 +0900 Received: from [10.25.144.221] (mark [10.25.144.221]) by goofy.dream.flab.fujitsu.co.jp (8.9.3+3.2W/3.7W) with ESMTP id UAA04417; Fri, 19 Aug 2005 20:12:51 +0900 Date: Fri, 19 Aug 2005 20:13:35 +0900 From: Akira NAGATA To: ccamp@ops.ietf.org Subject: Question on Administratively down bit Cc: Akira_NAGATA Message-Id: <20050819200548.46A5.NAGATA.AKIRA@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.20 [ja] 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Mr. Lou Berger and editors of RFC3471 and RFC3473, This is my first time to send e-mail to ccamp. Thanks in advance. I'd like to ask one question about the handling of Administratively down bit in GMPLS RSVP-TE's Admin_Status object. RFC3471 introduces "inhibiting alarm reporting" as an example application of local action to "down" state (that is, A-bit=1) in Section 8. But I can't find any other explicit descriptions about this procedure in RFC3471 or 3473. I understand that actions to be taken by each node receiving Admin_Status object shall be based on local policy. With regard to inhibition of alarm reporting, however, in order to achieve it through end-to-end, I believe that we had better take a unified action as a response to A-bit ("down" or "up"). Operator will expect this feature. (Here I mean alarm report is not reporting via RSVP messages as described in ID-alarm-spec, but one from NE to external system such as network management system.) Are there any considerations, drafts or RFCs to define it? Thanks, --- Akira NAGATA From owner-ccamp@ops.ietf.org Fri Aug 19 07:30:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E654Z-000488-5c for ccamp-archive@megatron.ietf.org; Fri, 19 Aug 2005 07:30: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 HAA27261 for ; Fri, 19 Aug 2005 07:30:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E65eU-00069z-HP for ccamp-archive@ietf.org; Fri, 19 Aug 2005 08:07:15 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6506-000OkP-0C for ccamp-data@psg.com; Fri, 19 Aug 2005 11:25:30 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6503-000Ok6-5D for ccamp@ops.ietf.org; Fri, 19 Aug 2005 11:25:27 +0000 Received: from du-069-0127.access.clara.net ([217.158.132.127] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E6501-000LyS-Dj; Fri, 19 Aug 2005 12:25:26 +0100 Message-ID: <061201c5a4b1$10d13580$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Wataru Imajuku" References: <5.1.1.9.2.20050818095638.0692ebe0@mailsv4.y.ecl.ntt.co.jp> <5.1.1.9.2.20050819055127.05675bc8@mailsv4.y.ecl.ntt.co.jp> Subject: Re: Moving forward with the CCAMP charter Date: Fri, 19 Aug 2005 12:20:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Hi, Thanks for your comments. Do you think it may be premature to apply 803.2ad techniques before we have done any work to control Ethernet networks with GMPLS? You are right that IEEE link aggregation is conceptually very close to bundling. I suggest that you need to separate TDM and Ethernet concepts in your I-D. Take the TDM issues to Diego, Richard, Greg et alia for inclusion in the VCAT/LCAS work. Take your LAGR issues to Dimitri and Loa for inclusion in the "GMPLS control of Ethernet switching" work that they are doing. Thanks, Adrian ----- Original Message ----- From: "Wataru Imajuku" To: "Adrian Farrel" ; Sent: Thursday, August 18, 2005 9:59 PM Subject: Re: Moving forward with the CCAMP charter > Hi, Adrian > > Thank you for giving your time interim your hard work. > > >With regard to your section 5, I note that you consider the VCAT group > >analogous with a link bundle. I don't think this is correct because the > >members of a link bundle must be selected and used individually. A payload > >data stream cannot be distributed across multiple component links of the > >bundle... > > An LSP with a bandwidth requirement b and > > setup priority p fits in a bundled link if at least one component > > link has maximum LSP bandwidth >= b at priority p. > >However, the whole point of a VCAT group is to produce a single entity > >(pipe) with maximum LSP bandwidth greater than the capacity of any > >individual component. A VCAT group, therefore, is not a bundle. > > > >Following on from this, I think that the remainder of your section 5.1 > >will have some value, but needs to be corrected to properly reflect the > >meaning of a VCAT group. > > > >In general, I think your section 5 should generalize from the specific > >case of the FA to include any TE link that is based on a VCAT group. > > > >Section 5.2 seems to confuse "FA" with "FA LSP". > > Regarding to VCAT, I agree to your comment. > But, this draft also covers LAGR (link aggregation) which has some limitations > to transmit data-flow exceeding the bandwidth of each comopnent LSP. > > This is one of reason why the description wirtten in Section 5 exists, although > some terminologies are not proper as you noted. > > Thanks > Wataru > > --------------------------------- > Wataru Imajuku > Senior Research Engineer > @NTT Network Innovation Labs. > TEL +81-46-859-4315 > FAX +81-46-859-5541 > > > From owner-ccamp@ops.ietf.org Fri Aug 19 07:30:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E654s-00048o-Oc for ccamp-archive@megatron.ietf.org; Fri, 19 Aug 2005 07:30: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 HAA27271 for ; Fri, 19 Aug 2005 07:30:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E65ep-0006A9-B4 for ccamp-archive@ietf.org; Fri, 19 Aug 2005 08:07:35 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6502-000Ojx-1R for ccamp-data@psg.com; Fri, 19 Aug 2005 11:25:26 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6501-000OjR-4C; Fri, 19 Aug 2005 11:25:25 +0000 Received: from du-069-0127.access.clara.net ([217.158.132.127] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E64zz-000LyS-D7; Fri, 19 Aug 2005 12:25:24 +0100 Message-ID: <061101c5a4b1$0f829570$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ong, Lyndon" Cc: , , "Kireeti Kompella" References: <0901D1988E815341A0103206A834DA07613F9A@mdmxm02.ciena.com> Subject: Re: Moving forward with the CCAMP charter Date: Fri, 19 Aug 2005 12:15: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: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Hi Lyndon, > As with everyone else, I appreciate all of the work that > you put in to create a very detailed workplan for the group. Thanks. > Some follow up questions and suggestions: > > -- On the "aligning GMPLS across standards bodies" item: > > First of all, what standards bodies do you see included under > this effort? Any and every that is or plans to use GMPLS or derive a variant of GMPLS. > Also, are you intending this to be a unilateral document on ccamp's > part? Yes. > If it is, I'm not sure I see what it would say besides "use the RFCs or > bring the requirements back to us", which is what this group has said in > the past. If on the other hand you see this as the basis for joint > discussion with other bodies, it might be a very helpful activity. First, I refuse to be hamstrung by history. Note that alignment requires that we start from where we are now (with non-interoperable variations of the protocols) and try to resolve the problem. Second, doing this work does not preclude discussing with other bodies. In fact, the draft is likely to lead specifically to discussions with other bodies. However, it is not pragmatic or wise to discuss with other bodies the actions which CCAMP thinks it should take. These are CCAMP actions. > -- On the ""routing and signaling for complex optical constraints" item: > > The ashwood draft seems to me to have two components, one being > requirements and considerations of routing across a purely photonic > domain and the second being a particular solution (the matrix > representation), to which there are alternatives such as the virtual link > approach that Igor has identified. > > I think these two should probably be separated, as the solution may be > more widely applied to any situation of advertising a virtualized > topology, such as in enhanced l1vpn. You'll notice that the work item is stated as "Analysis and protocol changes for routing and signaling for link viability constraints" whether this turns into one, two or a hundred I-Ds cannot possibly be determined at this point. I suspect that the issue of routing across a photonic domain as described in the Ashwood I-D is only a special case of a generic multi-domain TE issue. Hence this item appears under the Inter-Domain heading and is described much more generally. You are correct that some of this would feed into (overlap with) the L1VPN enhanced mode. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Aug 19 07:44:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E65IQ-00073y-D6 for ccamp-archive@megatron.ietf.org; Fri, 19 Aug 2005 07:44: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 HAA27805 for ; Fri, 19 Aug 2005 07:44:24 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E65sG-0006VS-RS for ccamp-archive@ietf.org; Fri, 19 Aug 2005 08:21:35 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E65E8-0000DP-1g for ccamp-data@psg.com; Fri, 19 Aug 2005 11:40:00 +0000 Received: from [139.63.192.207] (helo=ds07.tnoase.telecom.tno.nl) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E65E6-0000D8-EX for ccamp@ops.ietf.org; Fri, 19 Aug 2005 11:39:58 +0000 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: Requesting a LSC LSP across a PCS interface Date: Fri, 19 Aug 2005 13:39:54 +0200 Message-ID: <81FEC275650AE14EBD5245E624762B9701ACED66@ds07.tnoase.telecom.tno.nl> Thread-Topic: Requesting a LSC LSP across a PCS interface Thread-Index: AcWkQsg0/RO6ZiiGSbSHPuZYQSJDeQAboLbg From: To: , Cc: 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.3 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable =20 >=20 > hi, >=20 > > Consider the following situation: > >=20 > > Domain A <=3D | =3D> Domain B <=3D | =3D> = Domain C > > | | > > [A1]--PSC--[A2]--PSC--[B1]--LSC--[B2]--LSC--[B4]--PSC--[C1] > > | | | | > > |---PSC--[B3]--PSC---| > >=20 > >=20 > > Suppose I want to setup an (PSC) LSP from [A1] to [C1]. In domain B > > there are two options, the PSC route, or the LSC route. Is=20 > there a way > > to request (or hint for) a LSC LSP in domain B for the=20 > A1-C1 LSP? For > > example because the quality of the PSC path is deemed=20 > insufficient from > > the point of view of domains A and C (e.g. A and C are vey=20 > high bw LAN > > enviroments, B a WAN environment). >=20 > base on your diagram and assuming symmetric links both nodes=20 > B1 and B4=20 > must have a PSC and LSC switching capability so here and as=20 > provided in=20 > the diagram i assume the boundary is on the node; however, if=20 > you mean=20 > [B1,B4] and [B2,B4] being [PSC,LSC] and [LSC,PSC] resp. then=20 > B1 and B4=20 > are simple PSC nodes with LSC interfaces and then the=20 > boundary would be=20 > on the interface >=20 I envisioned the boundary on the node indeed. But on the interface could be an option as well. > now, if all domains are in the same routing area > - have strict path all along > - B4 loose hop with explicit indication of incoming interface >=20 Okay. > if all domains not in the same routing area > - make use of constaint passing by including (or excluding) specific=20 > switching capability such as to indicate which resource type to=20 > select/preclude in order to reach the destination B4 (loose hop) > So if I understand correctly, the LSP would be something like this: A1 to C1 via: A2 (strict), B1 (strict), B4 (loose, LSC), C1 (loose) =20 > hope this helps, Yes, thanks. Eduard > - dimitri. >=20 > > Thanks! > >=20 > > cheers, > > Eduard > >=20 > >=20 > >=20 > > . > >=20 >=20 From owner-ccamp@ops.ietf.org Sat Aug 20 05:57:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Q6c-00023D-FA for ccamp-archive@megatron.ietf.org; Sat, 20 Aug 2005 05:57: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 FAA13415 for ; Sat, 20 Aug 2005 05:57:36 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Qgf-0000DI-61 for ccamp-archive@ietf.org; Sat, 20 Aug 2005 06:34:59 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6PmG-0005se-4z for ccamp-data@psg.com; Sat, 20 Aug 2005 09:36:36 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6PmE-0005sI-Ht; Sat, 20 Aug 2005 09:36:35 +0000 Received: from du-069-0059.access.clara.net ([217.158.132.59] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E6Pm6-0009fo-Es; Sat, 20 Aug 2005 10:36:33 +0100 Message-ID: <001101c5a56b$025202e0$3b849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , Subject: Stability in the proposed CCAMP milestones Date: Sat, 20 Aug 2005 10:38:46 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01C5A573.57FD0930" 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: 4515df9441674711565101d9d5c4f63f This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5A573.57FD0930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Still entertaining more input at this stage. Fairly soon we will need to take this to the ADs for their opinions. Thanks, Adrian ------=_NextPart_000_000D_01C5A573.57FD0930 Content-Type: text/plain; name="ccamp-milestones.txt" Content-Disposition: attachment; filename="ccamp-milestones.txt" Content-Transfer-Encoding: quoted-printable CCAMP Working Group - Rechartering Effort Below you will find - a list of proposed milestones - an explanation of why this is a long list - overview of proposed drafts and work items In reviewing this we should look for: - topics that are irrelevant or unwanted by the WG - topics that have been left out but are wanted by the WG - topics that have been assigned the wrong priority or urgency - topics or collections or topics that are sufficiently large to potentially warrant their own working group. Proposed New milestones ----------------------- Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS = and OSPF Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh = membership Nov 05 Submit ASON Routing evaluation I-D for IESG review Nov 05 First version of WG I-D on path computation implmentation advice Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in = ISIS and OSPF Nov 05 First version WG I-D MPLS to GMPLS migration strategies Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS Nov 05 First version WG I-D Change of LSP ownership between management = and control planes Dec 05 First version of WG I-D for ASON Routing solutions Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG = review Dec 05 Submit Per-domain path computation signaling I-D for IESG review Dec 05 First version WG I-D Requirements for Multi-Layer and = Multi-Region Networks Dec 05 First version WG I-D for Evaluation of existing protocols for = MLN/MRN Dec 05 First version WG I-D for Protocol solutions for MLN/MRN Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG = review Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module Jan 06 First version WG Informational I-D for Analysis of inter-domain = issues for disjoint and protected paths Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF = for IESG review Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and = solutions Jan 06 First version WG I-D GMPLS OAM Requirements Jan 06 First version WG I-D Routing and signaling for link viability = constraints Feb 06 Submit LSP Stitching I-D for IESG review Mar 06 First version of WG informational I-D Aligning GMPLS protocols = across the standards bodies Mar 06 Submit GMPLS routing and signaling interoperability advice I-D = for IESG review Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module Mar 06 First version of WG I-D for additional MIB module to cover = RSVP-TE signaling extensions Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for = IESG review Jun 06 Submit Informational I-D for Analysis of inter-domain issues for = disjoint and protected paths for IESG review Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review Jun 06 Submit Change of LSP ownership between management and control = planes I-D for IESG review Aug 06 Submit path computation implmentation advice I-D for IESG review Oct 06 Submit ASON Routing solutions I-D for IESG review Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D = for IESG review Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG = review Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for = IESG review Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Dec 06 Submit GMPLS OAM Requirements I-D for IESG review Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor = and IESG review Oct 07 Submit Routing and signaling for link viability constraints I-D = for IESG review Oct 07 Recharter or close Working Group Why so many milestons? ---------------------- The number of milestones shown in this proposed list far exceeds anything I have ever seen in a working group charter. This is intentional and while it does indicate a heavy work-load it also indicates a higher level of micro-management than is usual within working groups. Thus two milestones are presented for each I-D (adoption as a WG I-D, and passing to the IESG post-WG-last-call). This can be compared with the "normal" charter milestones which include a single work-related item that may span several I-Ds and refers vaguely only to the "submission" of I-Ds. In other words, reviewers of this list should not panic because of its length, but should see this as beneficial. Explanation of I-Ds and work items ---------------------------------- The following text briefly introduces the work items that are represented by the milestones listed above. In this text an astrix (*) indicates a milestone to be set. The work is divided into several categories according to how core it is and how it should be prioritized. Existing drafts are referenced to indicate that work is already in progress - this is not intended to provide a complete list of existing drafts. Completing existing work = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ASON - ASON Routing evaluation - already have draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt * submit for IESG review - ASON Routing solutions * first version of WG draft * submit for IESG review - GMPLS signaling in support of Call Management - already have draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt * submit for IESG review - GMPLS/ASON lexicography - already have draft-ietf-ccamp-gmpls-ason-lexicography-03.txt * submit for IESG review - Aligning GMPLS protocols across the standards bodies - Information I-D not intended for publication as an RFC * first version of WG draft Interoperability reports and advice - signaling and routing - already have draft-ietf-ccamp-gmpls-addressing-01.txt * submit for IESG review - path computation * first version of WG draft - based on draft-otani-ccamp-gmpls-cspf-constraints-01.txt * submit for IESG review Additional MIB modules - OSPF-TE * first version of WG draft - based on draft-otani-ccamp-gmpls-ospf-mib-00.txt * submit for IESG review - ISIS-TE * first version of WG draft * submit for IESG review - Signaling - Need "living" MIB module under development to catch the minor protocol extensions that have been made * first version of WG draft * submit for IESG review Inter-domain - LSP Stitching - already have draft-ietf-ccamp-lsp-stitching-01.txt * submit for IESG review - RSVP-TE extensions for interdomain - already have draft-ietf-ccamp-inter-domain-rsvp-te-01.txt * submit for IESG review - Per-domain path computation signaling - already have draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt * submit for IESG review - Analysis of inter-domain issues for disjoint and protected paths - Informational I-D to close off the topic and devolve to PCE * first version of WG draft * submit for IESG review - Analysis and protocol changes for routing and signaling for link = viability constraints * first version of WG draft - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt - material from draft-otani-ccamp-interas-gmpls-te-03.txt * submit for IESG review New items already started and within existing charter = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Advertising TE Node Capabilities - ISIS and OSPF in the same I-D * first version of WG draft - based on draft-vasseur-ccamp-te-node-cap-00.txt * review by IGP working groups * submit for IESG review Automatic discovery of MPLS-TE mesh membership - depends on TE Node capabilities I-D * first version of WG draft - based on draft-vasseur-ccamp-automesh-00.txt * submit for IESG review Multi-layer networks (also multi-region networks) - Requirements * first version of WG draft - based on draft-shiomoto-ccamp-gmpls-mrn-reqs-02.txt * submit for IESG review - Evaluation of existing protocols * first version of WG draft - based on draft-leroux-ccamp-gmpls-mrn-eval-01.txt * submit for IESG review - Solutions * first version of WG draft - based on draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt * submit for IESG review MPLS-GMPLS interworking requirements and solutions * first version of WG draft - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt - material from = draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt * submit for IESG review MPLS to GMPLS migration strategies * Informational I-D first version of WG draft - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt - material from = draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt * submit Informational I-D for IESG review Minor items just starting but close to heart of WG = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= GMPLS OAM Requirements - Interesting and worthwhile * first version of WG draft - based on immature = draft-nadeau-ccamp-gmpls-oam-requirements-00.txt * submit for IESG review Minor items just starting and important becuase of inter-SDO = interactions = =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=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 GMPLS coordination of VCAT and LCAS - single requirements and solutions draft almost an applicablity = statement * first version of WG draft - based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt * submit for IESG review Change of LSP ownership between management and control planes - single requirements and solutions draft defines one bit and a = procedure * first version of WG draft - based on draft-caviglia-mp2cpcp2mp-02.txt * submit for IESG review Other work items with no specific milestones identified yet = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Control Plane Robustness - draft-ali-ccamp-mpls-graceful-shutdown-xx.txt Graceful shutdown. - draft-leroux-ccamp-ctrl-saturation-01.txt Control Plane = Saturation - draft-kim-ccamp-cpr-reqts-00.txt Control Plane = Resilience - draft-kim-ccamp-cc-protection-04.txt Control Channel = Protection ------=_NextPart_000_000D_01C5A573.57FD0930-- From owner-ccamp@ops.ietf.org Sat Aug 20 10:09:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6U1t-0003Ho-D1 for ccamp-archive@megatron.ietf.org; Sat, 20 Aug 2005 10:09:01 -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 KAA21939 for ; Sat, 20 Aug 2005 10:08:59 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6Uc2-0005P1-S9 for ccamp-archive@ietf.org; Sat, 20 Aug 2005 10:46:24 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6TjK-000B7a-4E for ccamp-data@psg.com; Sat, 20 Aug 2005 13:49:50 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6TjF-000B7A-Ud; Sat, 20 Aug 2005 13:49:46 +0000 Message-ID: <430734E8.4000202@psg.com> Date: Sat, 20 Aug 2005 15:49:28 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: =?UTF-8?B?6rmA7JiB7ZmU?= , ccamp@ops.ietf.org, zinin@psg.com, "'Kireeti Kompella'" Subject: Re: Control Plane Robustness [Was: Moving forward with the CCAMP charter] References: <99db01c5a4a0$fd265e80$8310fe81@email1> <05c701c5a4a5$c17274f0$4f849ed9@Puppy> In-Reply-To: <05c701c5a4a5$c17274f0$4f849ed9@Puppy> Content-Type: text/plain; charset=UTF-8; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,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: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA21939 adrian, Adrian Farrel wrote: [snip] > Thus my feeling at the moment is that Control Plane Robustness should b= e > an area that CCAMP looks at, but we should not set any specific > milestones. if you mean explicitly listed as part of the wg scope without explicit=20 milestone i would agree, also, a way to avoid having to modify the charter each time a specific=20 work item related to this area would need to be produced by the working=20 group thanks, - dimitri. >>Of course, I think it's possible under the condition that the topic of >>control plane resilience could be handled in the CCAMP charter. >=20 >=20 > -----=C2=A2=C2=AF=C2=A9=C2=AA=C2=A8=C2=AC=C2=A1=C3=AD =C2=A2=C2=AC=C2=A8= =C2=AD=C2=A8=C3=B6AAo----- > From: "Adrian Farrel" >>From Date: 2005-08-16 =C2=A2=C2=AFAEA 8:28:11 > To: "ccamp@ops.ietf.org" > Cc: "zinin@psg.com" , "'Kireeti Kompella'" > > Subject: Moving forward with the CCAMP charter >=20 >=20 > Hi, >=20 > Please find attached a file that contains: >=20 > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. >=20 > Note that this looks like a lot of milestones, but please read the text= on > this issue in the attached file. The bottom line is that this is a prod= uct > of micro management where I have tried to identify all of the I-Ds that= we > might produce to cover the referenced work, and where I have placed two > (sometimes three) milestones for each I-D. >=20 > This micro-management may be over the top, and represents a full pendul= um > swing from the previous style of CCAMP milestones, but in the light of = the > hiatus of the last 12 months, i think this may be beneficial and might > achieve rapid forwards movement. >=20 > I would welcome your (constructive!) comments. >=20 > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. >=20 > The objective is to have the WG agreed on the milestones that it wants = to > commit to by the end of August. >=20 > Thanks, > Adrian >=20 > ----- Original Message -----=20 > From: "=C2=B1=C3=A8=C2=BF=C2=B5=C3=88=C2=AD" > To: "Adrian Farrel" ; > Cc: ; "'Kireeti Kompella'" > Sent: Friday, August 19, 2005 10:32 AM > Subject: RE: Moving forward with the CCAMP charter >=20 >=20 >=20 >=20 >=20 >=20 > . >=20 From owner-ccamp@ops.ietf.org Sat Aug 20 10:56:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Um4-0002RV-4r for ccamp-archive@megatron.ietf.org; Sat, 20 Aug 2005 10:56: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 KAA24965 for ; Sat, 20 Aug 2005 10:56:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6VM7-0006a8-Se for ccamp-archive@ietf.org; Sat, 20 Aug 2005 11:34:07 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6UVg-000I7J-Fe for ccamp-data@psg.com; Sat, 20 Aug 2005 14:39:48 +0000 Received: from [213.46.243.21] (helo=amsfep14-int.chello.nl) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6UVe-000I6s-0j for ccamp@ops.ietf.org; Sat, 20 Aug 2005 14:39:46 +0000 Received: from [192.168.1.3] (really [24.132.27.149]) by amsfep14-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050820143929.JNMS28432.amsfep14-int.chello.nl@[192.168.1.3]>; Sat, 20 Aug 2005 16:39:29 +0200 Message-ID: <43074099.8090703@chello.nl> Date: Sat, 20 Aug 2005 16:39:21 +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: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be CC: ccamp Subject: Re: MS-SPring References: <43035143.30301@psg.com> <43059AF0.3030006@chello.nl> <4305AF37.2020500@psg.com> In-Reply-To: <4305AF37.2020500@psg.com> 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: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Hello Dimitri, You asked: > hi huub, > > Huub van Helvoort wrote: > >> Hallo Dimitri, >> >> You responded to Diego: >> >>> Diego Caviglia wrote: >>> >>>> Hi Dimitri, >>>> given the high number of MS-SPRing protected transport >>>> network >>>> already deployed seems reasonable to me, from a Network Operator >>>> point of >>>> view, to use at the same time MS-SPRing protection with GMPLS >>>> restoration. >>> >>> >>> there are already two questions here 1. is there an operational need >>> to control such rings using GMPLS (? for instance is it effective >>> knowing that ring based protection is mainly data plane driven ?) and >>> 2. how to position the ring protection wrt to the LSP recovery >>> segment/end-to-end recovery >> >> >> The first step in MS-Spring is indeed dataplane driven (using APS) >> but that involves only nodes adjacent to the fault. > > > ok, btw, is there a reason to restrict to MS/line protection ring ? If you refer to the APS protocol, this can be used in ring protection and linear protection, because it operates between source and sink of a trail or LSP. In its most simple form it provides 1:1 protection, and more general N:M protection >> The reconfiguration of the ring after this first switch is controlplane >> driven and concerns all nodes in the ring. > > ok with this - like for other linear protection schemes the control > plane would be involved in the provisioning > > also, what about the (informational) notification to maintain the > control plane aware about the data plane status after failure detection > and/or after the APS operation Maybe it is a good idea to include a description in the document Diego is preparing (in the book on functional modeling I need six pages to describe this protection mechanism). Have a nice weekend, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Sat Aug 20 14:06:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6Xjh-0002Px-H0 for ccamp-archive@megatron.ietf.org; Sat, 20 Aug 2005 14:06: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 OAA01466 for ; Sat, 20 Aug 2005 14:06:28 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6YJq-0002J8-Vt for ccamp-archive@ietf.org; Sat, 20 Aug 2005 14:43:54 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6XcV-000LYR-8M for ccamp-data@psg.com; Sat, 20 Aug 2005 17:59:03 +0000 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6XcT-000LY5-3W for ccamp@ops.ietf.org; Sat, 20 Aug 2005 17:59:01 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7KHwuv8004857; Sun, 21 Aug 2005 02:58:56 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7KHwuZ6017200; Sun, 21 Aug 2005 02:58:56 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7KHwtVg017197; Sun, 21 Aug 2005 02:58:55 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7KHwt24008526; Sun, 21 Aug 2005 02:58:55 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7KHwtQx008517; Sun, 21 Aug 2005 02:58:55 +0900 (JST) Received: from dmailsv1.y.ecl.ntt.co.jp (dmailsv1.y.ecl.ntt.co.jp [129.60.53.14]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7KHwss5023145; Sun, 21 Aug 2005 02:58:54 +0900 (JST) Received: from mailsv04.y.ecl.ntt.co.jp by dmailsv1.y.ecl.ntt.co.jp (8.13.4/dmailsv-1.4) with ESMTP id j7KHwrT0013607; Sun, 21 Aug 2005 02:58:53 +0900 (JST) Received: from localhost by mailsv04.y.ecl.ntt.co.jp (8.13.4/Lab-1.5) with ESMTP id j7KHwreb006018; Sun, 21 Aug 2005 02:58:53 +0900 (JST) Message-Id: <5.1.1.9.2.20050821025715.05839b28@mailsv4.y.ecl.ntt.co.jp> X-Sender: wi002@mailsv4.y.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Sun, 21 Aug 2005 02:59:12 +0900 To: "Adrian Farrel" , From: Wataru Imajuku Subject: Re: Moving forward with the CCAMP charter In-Reply-To: <061201c5a4b1$10d13580$4f849ed9@Puppy> References: <5.1.1.9.2.20050818095638.0692ebe0@mailsv4.y.ecl.ntt.co.jp> <5.1.1.9.2.20050819055127.05675bc8@mailsv4.y.ecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; 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=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: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Hi, Adrian Thanks. I'd like to do so. Best Regards Wataru >Hi, > >Thanks for your comments. > >Do you think it may be premature to apply 803.2ad techniques before we >have done any work to control Ethernet networks with GMPLS? > >You are right that IEEE link aggregation is conceptually very close to >bundling. > >I suggest that you need to separate TDM and Ethernet concepts in your I-D. >Take the TDM issues to Diego, Richard, Greg et alia for inclusion in the >VCAT/LCAS work. Take your LAGR issues to Dimitri and Loa for inclusion in >the "GMPLS control of Ethernet switching" work that they are doing. > >Thanks, >Adrian > >----- Original Message ----- >From: "Wataru Imajuku" >To: "Adrian Farrel" ; >Sent: Thursday, August 18, 2005 9:59 PM >Subject: Re: Moving forward with the CCAMP charter > > > > Hi, Adrian > > > > Thank you for giving your time interim your hard work. > > > > >With regard to your section 5, I note that you consider the VCAT group > > >analogous with a link bundle. I don't think this is correct because the > > >members of a link bundle must be selected and used individually. A >payload > > >data stream cannot be distributed across multiple component links of >the > > >bundle... > > > An LSP with a bandwidth requirement b and > > > setup priority p fits in a bundled link if at least one component > > > link has maximum LSP bandwidth >= b at priority p. > > >However, the whole point of a VCAT group is to produce a single entity > > >(pipe) with maximum LSP bandwidth greater than the capacity of any > > >individual component. A VCAT group, therefore, is not a bundle. > > > > > >Following on from this, I think that the remainder of your section 5.1 > > >will have some value, but needs to be corrected to properly reflect the > > >meaning of a VCAT group. > > > > > >In general, I think your section 5 should generalize from the specific > > >case of the FA to include any TE link that is based on a VCAT group. > > > > > >Section 5.2 seems to confuse "FA" with "FA LSP". > > > > Regarding to VCAT, I agree to your comment. > > But, this draft also covers LAGR (link aggregation) which has some >limitations > > to transmit data-flow exceeding the bandwidth of each comopnent LSP. > > > > This is one of reason why the description wirtten in Section 5 exists, >although > > some terminologies are not proper as you noted. > > --------------------------------- Wataru Imajuku Senior Research Engineer @NTT Network Innovation Labs. TEL +81-46-859-4315 FAX +81-46-859-5541 From owner-ccamp@ops.ietf.org Sun Aug 21 05:41:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6mKm-000305-B1 for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 05:41: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 FAA18076 for ; Sun, 21 Aug 2005 05:41:41 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6mv7-0001RF-0m for ccamp-archive@ietf.org; Sun, 21 Aug 2005 06:19:17 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6mAW-000FeP-Qk for ccamp-data@psg.com; Sun, 21 Aug 2005 09:31:08 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6mAV-000Fe6-Ok; Sun, 21 Aug 2005 09:31:08 +0000 Message-ID: <430849C8.5040608@psg.com> Date: Sun, 21 Aug 2005 11:30:48 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Huub van Helvoort CC: dimitri.papadimitriou@alcatel.be, ccamp Subject: Re: MS-SPring References: <43035143.30301@psg.com> <43059AF0.3030006@chello.nl> <4305AF37.2020500@psg.com> <43074099.8090703@chello.nl> In-Reply-To: <43074099.8090703@chello.nl> 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=-5.9 required=5.0 tests=ALL_TRUSTED,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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Huub, [snip] >> ok, btw, is there a reason to restrict to MS/line protection ring ? > > If you refer to the APS protocol, this can be used in ring > protection and linear protection, because it operates between > source and sink of a trail or LSP. > In its most simple form it provides 1:1 protection, and more > general N:M protection i was referring to the scope of the document - should it be restricted to MS/line shared protection ring or include other types (e.g. path protection ring) - note: in my view not >>> The reconfiguration of the ring after this first switch is controlplane >>> driven and concerns all nodes in the ring. >> >> ok with this - like for other linear protection schemes the control >> plane would be involved in the provisioning >> >> also, what about the (informational) notification to maintain the >> control plane aware about the data plane status after failure >> detection and/or after the APS operation > > Maybe it is a good idea to include a description in the document > Diego is preparing (in the book on functional modeling I need > six pages to describe this protection mechanism). imho, an overview should be enough to skim the ring protection scheme and the APS operation (no need to include full details that can be found elsewhere) > Have a nice weekend, Huub. > From owner-ccamp@ops.ietf.org Sun Aug 21 06:05:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6mhK-0006hI-Bp for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 06:05: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 GAA19936 for ; Sun, 21 Aug 2005 06:04:59 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6nHb-00028N-SG for ccamp-archive@ietf.org; Sun, 21 Aug 2005 06:42:35 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6mbw-000KV6-Ay for ccamp-data@psg.com; Sun, 21 Aug 2005 09:59:28 +0000 Received: from [213.46.243.25] (helo=amsfep16-int.chello.nl) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6mbs-000KUP-R2 for ccamp@ops.ietf.org; Sun, 21 Aug 2005 09:59:25 +0000 Received: from [192.168.1.3] (really [24.132.27.149]) by amsfep16-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050821095907.HVQI2060.amsfep16-int.chello.nl@[192.168.1.3]>; Sun, 21 Aug 2005 11:59:07 +0200 Message-ID: <43085065.3080504@chello.nl> Date: Sun, 21 Aug 2005 11:59:01 +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: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be CC: ccamp Subject: Re: MS-SPring References: <43035143.30301@psg.com> <43059AF0.3030006@chello.nl> <4305AF37.2020500@psg.com> <43074099.8090703@chello.nl> <430849C8.5040608@psg.com> In-Reply-To: <430849C8.5040608@psg.com> 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=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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Hi Dimitri, I agree with you on both points. - no restriction of the scope: linear + ring protection - the fundamentals in Diego's document with references to relevant (standard) documents and articles. Cheers, Huub. > Huub, > > [snip] > >>> ok, btw, is there a reason to restrict to MS/line protection ring ? >> >> >> If you refer to the APS protocol, this can be used in ring >> protection and linear protection, because it operates between >> source and sink of a trail or LSP. >> In its most simple form it provides 1:1 protection, and more >> general N:M protection > > > i was referring to the scope of the document - should it be restricted > to MS/line shared protection ring or include other types (e.g. path > protection ring) - note: in my view not > >>>> The reconfiguration of the ring after this first switch is controlplane >>>> driven and concerns all nodes in the ring. >>> >>> >>> ok with this - like for other linear protection schemes the control >>> plane would be involved in the provisioning >>> >>> also, what about the (informational) notification to maintain the >>> control plane aware about the data plane status after failure >>> detection and/or after the APS operation >> >> >> Maybe it is a good idea to include a description in the document >> Diego is preparing (in the book on functional modeling I need >> six pages to describe this protection mechanism). > > > imho, an overview should be enough to skim the ring protection scheme > and the APS operation (no need to include full details that can be found > elsewhere) > >> Have a nice weekend, Huub. >> > -- ================================================================ http://www.gironet.nl/home/idefiks/ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From JamarTemple@sentential.com Sun Aug 21 07:31:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6o37-0002t7-Jq for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 07:31: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 HAA22598 for ; Sun, 21 Aug 2005 07:31:36 -0400 (EDT) Received: from [221.127.147.96] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E6odP-00042B-Sx for ccamp-archive@ietf.org; Sun, 21 Aug 2005 08:09:11 -0400 Received: from aWl@localhost by jUc.int (8.11.6/8.11.6); Sun, 21 Aug 2005 14:24:36 +0500 Message-ID: From: "Jamie Jefferson" Reply-To: "Jamie Jefferson" To: ccamp-archive@ietf.org Subject: Windows XP Pro $49.95, Office 2003 $69.95 AutoCAD Date: Sun, 21 Aug 2005 05:21:36 -0400 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: JamarTemple@sentential.com Content-Type: multipart/mixed; boundary="--MqR9NVfg685zGGN" X-Spam-Score: 3.5 (+++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 9pv ----MqR9NVfg685zGGN Content-Type: text/html; Content-Transfer-Encoding: quoted-printable O
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

=
Choose:
 

You Save:



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

Sales Rank: #1
System requirements  |  Other Versions
Date= Coupon Expires: August 31st, 2005
Av= erage Customer Review:3D"5 Based on 11864 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: PY= PTF
 

Sales Rank: #2
<= /span>System requir= ements  |  Other Versions=
Date Coupon Expires: August 31st= , 2005
Average Customer Review:3D"5 Based on 152679 reviews. Write a rev= iew.

Microsoft Windows XP Professional or L= onghorn Edition
Microsoft<= br>

<= td vAlign=3Dtop noWrap>
Choose:
 

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



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

Sales Rank: #3
System requirements  |  Other Versions
Date Coupon= Expires: August 31st, 2005
Average C= ustomer Review:3D"5 Based on 14869 reviews. Write a review.

Adobe Acrobat = Professional V 7.0
Adobe

Choose:
 

=

List Price:<= /b>$499.00
Price:$69.99
You Save:$429.01 (85%)



= Availability: Available for INSTANT download!
Coupon Code:<= /b> TkgNu
 

Sales Rank: #4=
System = requirements  |  Other Ve= rsions
Date Coupon Expires: Augus= t 31st, 2005
Average Customer Review:= 3D"5 Based on 16865 reviews. Write = a review.

----MqR9NVfg685zGGN-- From owner-ccamp@ops.ietf.org Sun Aug 21 11:19:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6rbI-0006xT-AX for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 11:19:08 -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 LAA04815 for ; Sun, 21 Aug 2005 11:19:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6sBZ-0001Fj-3K for ccamp-archive@ietf.org; Sun, 21 Aug 2005 11:56:44 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6rRZ-000Jva-OU for ccamp-data@psg.com; Sun, 21 Aug 2005 15:09:05 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6rRZ-000JvK-1d for ccamp@ops.ietf.org; Sun, 21 Aug 2005 15:09:05 +0000 Received: from du-069-0078.access.clara.net ([217.158.132.78] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E6rRK-000O2N-7R; Sun, 21 Aug 2005 16:08:51 +0100 Message-ID: <00e301c5a662$9baba390$20849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" , "Dimitri Papadimitriou" , "Reshad Rahman" , "Anca Zamfir" , "Junaid Israr" , "Arun Satyanarayana \(asatyana\)" Cc: Subject: Nit in draft-ietf-ccamp-rsvp-restart-ext-03.txt Date: Sun, 21 Aug 2005 16:11:19 +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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Hi, Looks like the extra last call on this I-D completed without further comment. Unfortunately, scanning through the draft I found a nit. So you need to do a quick re-spin. I think this should take you less than an hour. Please let me know if you can't do it by the end of the week and I will do it myself. Thanks, Adrian === Section 2 Spurious text relating to cross-references The reader is assumed to be familiar with the terminology defined in xref target="RFC3209" /> and [RFC3473]. From owner-ccamp@ops.ietf.org Sun Aug 21 12:44:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6svk-00046G-OF for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 12:44: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 MAA07772 for ; Sun, 21 Aug 2005 12:44:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6tW3-00035n-Ah for ccamp-archive@ietf.org; Sun, 21 Aug 2005 13:21:57 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6spp-0008sm-5W for ccamp-data@psg.com; Sun, 21 Aug 2005 16:38:13 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6spn-0008sX-Hi for ccamp@ops.ietf.org; Sun, 21 Aug 2005 16:38:11 +0000 Received: from du-069-0025.access.clara.net ([217.158.132.25] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1E6spm-000P2N-6o for ccamp@ops.ietf.org; Sun, 21 Aug 2005 17:38:11 +0100 Message-ID: <012c01c5a66f$1672a540$20849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Not voting on the charter milestones Date: Sun, 21 Aug 2005 17:39: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 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Hi, Of course we don't vote, but Kireeti and I do need evidence of rough consensus. We have a had a good number of emails picking up on small points, but nothing of any substance said against the proposed milestones. We have some evidence of general support. Can you please speak up. Do you broadly support the proposed new CCAMP milestones? Thanks, Adrian From owner-ccamp@ops.ietf.org Sun Aug 21 12:47:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6szH-0004dw-Lz for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 12:47: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 MAA07851 for ; Sun, 21 Aug 2005 12:47:56 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6tZf-00039i-9R for ccamp-archive@ietf.org; Sun, 21 Aug 2005 13:25:36 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6sve-000A1x-1K for ccamp-data@psg.com; Sun, 21 Aug 2005 16:44:14 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6svd-000A1i-EK for ccamp@ops.ietf.org; Sun, 21 Aug 2005 16:44:13 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2005 09:44:12 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,129,1122879600"; d="scan'208"; a="6759336:sNHT21356712" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7LGiAQl018610; Sun, 21 Aug 2005 12:44:10 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 21 Aug 2005 12:44:08 -0400 Received: from [192.168.1.101] ([10.86.242.101]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 21 Aug 2005 12:44:09 -0400 In-Reply-To: <012c01c5a66f$1672a540$20849ed9@Puppy> References: <012c01c5a66f$1672a540$20849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v733) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6DFECA70-2C77-403A-90F2-0A958ABB4767@cisco.com> Cc: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: Not voting on the charter milestones Date: Sun, 21 Aug 2005 12:44:34 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 21 Aug 2005 16:44:09.0280 (UTC) FILETIME=[8D570C00:01C5A66F] 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit On Aug 21, 2005, at 12:39 PM, Adrian Farrel wrote: > Hi, > > Of course we don't vote, but Kireeti and I do need evidence of rough > consensus. We have a had a good number of emails picking up on small > points, but nothing of any substance said against the proposed > milestones. > We have some evidence of general support. > > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? > Yes, JP. > Thanks, > Adrian > From owner-ccamp@ops.ietf.org Sun Aug 21 13:22:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tX4-0001ks-PW for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 13:22: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 NAA08975 for ; Sun, 21 Aug 2005 13:22:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6u7K-0003sA-F3 for ccamp-archive@ietf.org; Sun, 21 Aug 2005 14:00:32 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6tRc-000G6O-Pl for ccamp-data@psg.com; Sun, 21 Aug 2005 17:17:16 +0000 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6tRZ-000G66-2w for ccamp@ops.ietf.org; Sun, 21 Aug 2005 17:17:13 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j7LHHBYg020947; Sun, 21 Aug 2005 10:17:11 -0700 (PDT) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j7LHHBm7020944; Sun, 21 Aug 2005 10:17:11 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.2/8.13.2) with ESMTP id j7LHHAgM005811; Sun, 21 Aug 2005 10:17:10 -0700 (PDT) Received: from [133.164.16.51] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id j7LHHAT26792; Sun, 21 Aug 2005 10:17:10 -0700 (PDT) Message-ID: <4308B716.1080505@us.fujitsu.com> Date: Sun, 21 Aug 2005 10:17:10 -0700 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Not voting on the charter milestones References: <012c01c5a66f$1672a540$20849ed9@Puppy> In-Reply-To: <012c01c5a66f$1672a540$20849ed9@Puppy> Content-Type: multipart/mixed; boundary="------------080106010802050204020304" 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: 0ddefe323dd869ab027dbfff7eff0465 This is a multi-part message in MIME format. --------------080106010802050204020304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit yes Adrian Farrel wrote: >Hi, > >Of course we don't vote, but Kireeti and I do need evidence of rough >consensus. We have a had a good number of emails picking up on small >points, but nothing of any substance said against the proposed milestones. >We have some evidence of general support. > >Can you please speak up. >Do you broadly support the proposed new CCAMP milestones? > >Thanks, >Adrian > > > > --------------080106010802050204020304 Content-Type: text/x-vcard; charset=utf-8; name="richard.vcf" Content-Disposition: attachment; filename="richard.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Richard Rabbat n:Rabbat;Richard org:Fujitsu Labs of America;IP Networking Research adr:MS 345;;1240 East Arques Ave;Sunnyvale;CA;94085;USA email;internet:richard@us.fujitsu.com title:Senior Project Manager tel;work:1-408-530-4537 tel;fax:1-408-530-4515 tel;cell:1-650-714-7618 x-mozilla-html:TRUE version:2.1 end:vcard --------------080106010802050204020304-- From owner-ccamp@ops.ietf.org Sun Aug 21 13:43:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6trO-0005JE-7c for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 13:43: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 NAA09635 for ; Sun, 21 Aug 2005 13:43:53 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6uRm-0004It-GU for ccamp-archive@ietf.org; Sun, 21 Aug 2005 14:21:31 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6tiy-000J14-4Y for ccamp-data@psg.com; Sun, 21 Aug 2005 17:35:12 +0000 Received: from [80.86.78.228] (helo=smtp.testbed.se) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6tit-000J0j-Vs for ccamp@ops.ietf.org; Sun, 21 Aug 2005 17:35:08 +0000 Received: from p54bfbfbe.dip.t-dialin.net ([84.191.191.190] helo=[10.0.0.22]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.43) id 1E6til-0007Hn-C5; Sun, 21 Aug 2005 19:35:06 +0200 Message-ID: <4308BB41.9090406@pi.se> Date: Sun, 21 Aug 2005 19:34:57 +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: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Not voting on the charter milestones References: <012c01c5a66f$1672a540$20849ed9@Puppy> In-Reply-To: <012c01c5a66f$1672a540$20849ed9@Puppy> 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: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit yes /Loa Adrian Farrel wrote: > Hi, > > Of course we don't vote, but Kireeti and I do need evidence of rough > consensus. We have a had a good number of emails picking up on small > points, but nothing of any substance said against the proposed milestones. > We have some evidence of general support. > > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? > > Thanks, > Adrian > > > -- 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 Sun Aug 21 16:00:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6vz7-000276-OX for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 16:00:01 -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 PAA16333 for ; Sun, 21 Aug 2005 15:59:59 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6wZV-0007Vy-5H for ccamp-archive@ietf.org; Sun, 21 Aug 2005 16:37:40 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6vrP-000Glx-4y for ccamp-data@psg.com; Sun, 21 Aug 2005 19:52:03 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6vrO-000Glf-BG; Sun, 21 Aug 2005 19:52:02 +0000 Message-ID: <4308DB4E.3010806@psg.com> Date: Sun, 21 Aug 2005 21:51:42 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Not voting on the charter milestones References: <012c01c5a66f$1672a540$20849ed9@Puppy> In-Reply-To: <012c01c5a66f$1672a540$20849ed9@Puppy> 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=-5.9 required=5.0 tests=ALL_TRUSTED,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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Adrian Farrel wrote: > Hi, > > Of course we don't vote, but Kireeti and I do need evidence of rough > consensus. We have a had a good number of emails picking up on small > points, but nothing of any substance said against the proposed milestones. > We have some evidence of general support. > > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? yes - -d. > Thanks, > Adrian > > > > . > From owner-ccamp@ops.ietf.org Sun Aug 21 16:56:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6wrV-0002dJ-4Z for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 16:56:13 -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 QAA18644 for ; Sun, 21 Aug 2005 16:56:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6xRu-0000LZ-SK for ccamp-archive@ietf.org; Sun, 21 Aug 2005 17:33:52 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6wkC-0000rl-1Z for ccamp-data@psg.com; Sun, 21 Aug 2005 20:48:40 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6wkA-0000rX-6X for ccamp@ops.ietf.org; Sun, 21 Aug 2005 20:48:38 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2005 13:48:38 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.96,129,1122879600"; d="scan'208"; a="6768633:sNHT20328636" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7LKmYQl016033; Sun, 21 Aug 2005 16:48:35 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 21 Aug 2005 16:48:31 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Not voting on the charter milestones Date: Sun, 21 Aug 2005 16:48:31 -0400 Message-ID: Thread-Topic: Not voting on the charter milestones Thread-Index: AcWmbud8OjthYAmWQImq+VkWpxd/FwAIiSrw From: "Zafar Ali \(zali\)" To: "Adrian Farrel" , X-OriginalArrivalTime: 21 Aug 2005 20:48:31.0752 (UTC) FILETIME=[B0DAB880:01C5A691] 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: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, August 21, 2005 12:39 PM > To: ccamp@ops.ietf.org > Subject: Not voting on the charter milestones >=20 > Hi, >=20 > Of course we don't vote, but Kireeti and I do need evidence=20 > of rough consensus. We have a had a good number of emails=20 > picking up on small points, but nothing of any substance said=20 > against the proposed milestones. > We have some evidence of general support. >=20 > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? Yes,=20 Thanks Regards... Zafar=20 >=20 > Thanks, > Adrian >=20 From owner-ccamp@ops.ietf.org Sun Aug 21 19:32:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6zIR-0002OG-8t for ccamp-archive@megatron.ietf.org; Sun, 21 Aug 2005 19:32: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 TAA25636 for ; Sun, 21 Aug 2005 19:32:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6zsm-0003zp-0W for ccamp-archive@ietf.org; Sun, 21 Aug 2005 20:09:51 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6zBj-0002us-W6 for ccamp-data@psg.com; Sun, 21 Aug 2005 23:25:15 +0000 Received: from [192.26.91.6] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6zBj-0002uf-1t for ccamp@ops.ietf.org; Sun, 21 Aug 2005 23:25:15 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 14CC7EC93F; Mon, 22 Aug 2005 08:25:11 +0900 (JST) Received: from platinum.onw.kddilabs.jp (platinum.onw.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id 9F320EC91D; Mon, 22 Aug 2005 08:25:10 +0900 (JST) Received: from [IPv6:2001:200:601:1e02:0:5efe:ac13:570d] (unknown [IPv6:2001:200:601:1e02:0:5efe:ac13:570d]) by platinum.onw.kddilabs.jp (Postfix) with ESMTP id 87AFE578103; Mon, 22 Aug 2005 08:18:18 +0900 (JST) Message-ID: <43090D56.8080100@kddilabs.jp> Date: Mon, 22 Aug 2005 08:25:10 +0900 From: Tomohiro Otani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Adrian Farrel Cc: JP Vasseur , ccamp@ops.ietf.org, zinin@psg.com, "'Kireeti Kompella'" Subject: Re: Inter-AS GMPLS [Was: Moving forward with the CCAMP charter] References: <00db01c5a256$6624ebb0$4f849ed9@Puppy> <6A0BF8B4-577A-4AFC-8132-B086AC914C64@cisco.com> <01d401c5a294$477581f0$4f849ed9@Puppy> <690B6C56-60F8-4F1F-8349-F3931878A0CA@cisco.com> <43028CCB.2090607@kddilabs.jp> <02cc01c5a315$9da4a160$4f849ed9@Puppy> In-Reply-To: <02cc01c5a315$9da4a160$4f849ed9@Puppy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new 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 Content-Transfer-Encoding: 7bit Hi Adrian, Thank you for your e-mail message clarifying my comments. I agree with your proposed milestone. One point is that as you mentioned, our draft covers; 1. TE reachability information exchange 2. Exchange of aggregated TE information for a domain In addition to these, in our draft, I also assume that GMPLS inter-domain routing is required to exchange reachability information. The draft should be short enough to clarify whether we rely on the same (existing) protocol mechanism as IP/MPLS. Regards, tomo Adrian Farrel wrote: >Hi Tomo, > >> Being related with your text and JP's messages, I would ask you >> to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt. >> Is this related with a kind of baseline for (1) Analysis of inter-domain >> issues ? >> >> So far, there is a proposed draft of GMPLS inter-domain signaling >> as we discussed in Paris, but there is no draft of GMPLS inter-domain >> routing definition whether it is with TE extension or not. >> (your framework draft covers these points) > >Good point. > >It seems that your draft is discussing two things: >1. TE reachability information exchange >2. Exchange of aggregated TE information for a domain > >As you point out in section 4.2, the issue of scalability and policy needs >to be carefully considered before we pursue this too much further. > >I think your work, especially the aggregation issues, meshes nicely with >the recent draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt. Therefore, I >propose the following changes to the draft I sent out before... > >1. Delete > Jan 06 First version WG I-D Routing and signaling for complex optical >constraints > Oct 07 Submit Routing and signaling for complex optical constraints I-D >for IESG review >2. Insert > Jan 06 First version WG I-D Routing and signaling for link viability >constraints > Oct 07 Submit Routing and signaling for link viability constraints I-D >for IESG review >3. Delete > More forward-looking > ==================== > Routing and signaling for complex constraints and inter-domain > * first version of WG draft > - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt > * submit for IESG review >4. Add to Inter-domain section > - Analysis and protocol changes for routing and signaling for link >viability constraints > * first version of WG draft > - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt > - material from draft-otani-ccamp-interas-gmpls-te-03.txt > * submit for IESG review > >Cheers, >Adrian > > > > > > > > From owner-ccamp@ops.ietf.org Mon Aug 22 04:17:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E77Uj-0008O6-9j for ccamp-archive@megatron.ietf.org; Mon, 22 Aug 2005 04:17: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 EAA00037 for ; Mon, 22 Aug 2005 04:17:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7856-0008Qo-SZ for ccamp-archive@ietf.org; Mon, 22 Aug 2005 04:55:10 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E77Gd-000PcF-5V for ccamp-data@psg.com; Mon, 22 Aug 2005 08:02:51 +0000 Received: from [217.6.95.240] (helo=tcmail33.telekom.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E77Gb-000PbX-0X for ccamp@ops.ietf.org; Mon, 22 Aug 2005 08:02:49 +0000 Received: from S4DE8PSAANV.t-systems.com by tcmail31.dmz.telekom.de with ESMTP; Mon, 22 Aug 2005 10:00:43 +0200 Received: by S4DE8PSAANV.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Aug 2005 10:00:41 +0200 Message-Id: From: Michael.Dueser@t-systems.com To: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: AW: Not voting on the charter milestones Date: Mon, 22 Aug 2005 10:00:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable I support the list of CCAMP milestones. Michael=20 -----Urspr=FCngliche Nachricht----- Von: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] Im = Auftrag von Adrian Farrel Gesendet: Sonntag, 21. August 2005 18:39 An: ccamp@ops.ietf.org Betreff: Not voting on the charter milestones Hi, Of course we don't vote, but Kireeti and I do need evidence of rough = consensus. We have a had a good number of emails picking up on small = points, but nothing of any substance said against the proposed = milestones. We have some evidence of general support. Can you please speak up. Do you broadly support the proposed new CCAMP milestones? Thanks, Adrian From owner-ccamp@ops.ietf.org Mon Aug 22 04:31:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E77i6-0001zh-AC for ccamp-archive@megatron.ietf.org; Mon, 22 Aug 2005 04:31: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 EAA00674 for ; Mon, 22 Aug 2005 04:31:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E78Id-0000Oz-0t for ccamp-archive@ietf.org; Mon, 22 Aug 2005 05:08:59 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E77dZ-0003zE-I7 for ccamp-data@psg.com; Mon, 22 Aug 2005 08:26:33 +0000 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E77dX-0003yl-44 for ccamp@ops.ietf.org; Mon, 22 Aug 2005 08:26:31 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 10:26:29 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Not voting on the charter milestones Date: Mon, 22 Aug 2005 10:26:42 +0200 Message-ID: Thread-Topic: Not voting on the charter milestones Thread-Index: AcWmbzUyLYWoln7dQ6yju4/6iFZnkgAg/OSw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , X-OriginalArrivalTime: 22 Aug 2005 08:26:29.0327 (UTC) FILETIME=[31D58DF0:01C5A6F3] 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Hi Adrian, all The proposed milestones sound good to me Regards JL=20 > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel > Envoy=E9 : dimanche 21 ao=FBt 2005 18:39 > =C0 : ccamp@ops.ietf.org > Objet : Not voting on the charter milestones >=20 > Hi, >=20 > Of course we don't vote, but Kireeti and I do need evidence=20 > of rough consensus. We have a had a good number of emails=20 > picking up on small points, but nothing of any substance said=20 > against the proposed milestones. > We have some evidence of general support. >=20 > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? >=20 > Thanks, > Adrian >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Mon Aug 22 07:55:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Atm-0000Dc-Ce for ccamp-archive@megatron.ietf.org; Mon, 22 Aug 2005 07:55:30 -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 HAA08502 for ; Mon, 22 Aug 2005 07:55:29 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7BUK-000618-8I for ccamp-archive@ietf.org; Mon, 22 Aug 2005 08:33:17 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7AmK-000EKi-MM for ccamp-data@psg.com; Mon, 22 Aug 2005 11:47:48 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7AmJ-000EKU-3r for ccamp@ops.ietf.org; Mon, 22 Aug 2005 11:47:47 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 22 Aug 2005 07:47:47 -0400 X-IronPort-AV: i="3.96,130,1122868800"; d="scan'208"; a="67358892:sNHT27975956" Received: from [10.83.15.58] (rtp-tnadeau-vpn9.cisco.com [10.83.15.58]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with SMTP id j7MBlHQn018038; Mon, 22 Aug 2005 07:47:42 -0400 (EDT) In-Reply-To: <012c01c5a66f$1672a540$20849ed9@Puppy> References: <012c01c5a66f$1672a540$20849ed9@Puppy> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A98A581-3CDF-4A63-8967-3F480C4E65CC@cisco.com> Cc: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: Not voting on the charter milestones Date: Mon, 22 Aug 2005 07:47:41 -0400 To: "Adrian Farrel" X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.0 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: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit They look okay to me. --Tom > Hi, > > Of course we don't vote, but Kireeti and I do need evidence of rough > consensus. We have a had a good number of emails picking up on small > points, but nothing of any substance said against the proposed > milestones. > We have some evidence of general support. > > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? > > Thanks, > Adrian > From owner-ccamp@ops.ietf.org Mon Aug 22 08:10:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7B88-0003gn-Vz for ccamp-archive@megatron.ietf.org; Mon, 22 Aug 2005 08:10: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 IAA09799 for ; Mon, 22 Aug 2005 08:10:19 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Bie-0006bI-Jj for ccamp-archive@ietf.org; Mon, 22 Aug 2005 08:48:08 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7B1U-000HST-IW for ccamp-data@psg.com; Mon, 22 Aug 2005 12:03:28 +0000 Received: from [216.82.242.99] (helo=mail131.messagelabs.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E7B1Q-000HRy-Gr for ccamp@ops.ietf.org; Mon, 22 Aug 2005 12:03:24 +0000 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-12.tower-131.messagelabs.com!1124712166!8076142!14 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 16319 invoked from network); 22 Aug 2005 12:03:23 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-12.tower-131.messagelabs.com with SMTP; 22 Aug 2005 12:03:23 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B00E70983; Mon, 22 Aug 2005 08:03:23 -0400 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: Not voting on the charter milestones Date: Mon, 22 Aug 2005 07:03:22 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9238@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Not voting on the charter milestones Thread-Index: AcWmbt71a7K6t/X4Th2dtw6VLK2jPQAol0cQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" 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: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Hi Adrian, > Do you broadly support the proposed new CCAMP milestones? Looks good, I like the detail.=20 Thanks, Jerry From owner-ccamp@ops.ietf.org Mon Aug 22 08:35:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7BW9-0000I2-Rb for ccamp-archive@megatron.ietf.org; Mon, 22 Aug 2005 08:35:09 -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 IAA12529 for ; Mon, 22 Aug 2005 08:35:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7C6g-0007eN-2q for ccamp-archive@ietf.org; Mon, 22 Aug 2005 09:12:57 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7BOk-000Lpq-SH for ccamp-data@psg.com; Mon, 22 Aug 2005 12:27:30 +0000 Received: from [128.87.251.113] (helo=smtpoutuk02.marconi.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7BOi-000Lpc-B2 for ccamp@ops.ietf.org; Mon, 22 Aug 2005 12:27:28 +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 j7MCRK6e023251 for ; Mon, 22 Aug 2005 13:27:21 +0100 (envelope-from Diego.Caviglia@marconi.com) Subject: Re: Not voting on the charter milestones To: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Mon, 22 Aug 2005 14:27:46 +0200 X-MIMETrack: Serialize by Router on CVDGWY01/S/EXT/MC1(5012HF354 | August 26, 2003) at 22/08/2005 13:27:24 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: e1e48a527f609d1be2bc8d8a70eb76cb Yes Regards Diego "Adrian Farrel" @ops.ietf.org on 21/08/2005 18.39.08 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: cc: Subject: Not voting on the charter milestones Hi, Of course we don't vote, but Kireeti and I do need evidence of rough consensus. We have a had a good number of emails picking up on small points, but nothing of any substance said against the proposed milestones. We have some evidence of general support. Can you please speak up. Do you broadly support the proposed new CCAMP milestones? Thanks, Adrian From owner-ccamp@ops.ietf.org Mon Aug 22 13:18:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Fvr-0004tA-Nw for ccamp-archive@megatron.ietf.org; Mon, 22 Aug 2005 13:18:00 -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 NAA29240 for ; Mon, 22 Aug 2005 13:17:56 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7GWS-000825-8Z for ccamp-archive@ietf.org; Mon, 22 Aug 2005 13:55:49 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7FnA-000Mgi-In for ccamp-data@psg.com; Mon, 22 Aug 2005 17:09:00 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7Fn7-000MgC-QW for ccamp@ops.ietf.org; Mon, 22 Aug 2005 17:08:57 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Aug 2005 10:08:34 -0700 X-IronPort-AV: i="3.96,131,1122879600"; d="scan'208"; a="334502720:sNHT1538445816" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7MH7qQq002253; Mon, 22 Aug 2005 10:08:25 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 10:08:29 -0700 Received: from [10.21.81.194] ([10.21.81.194]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 10:08:28 -0700 Message-ID: <430A0685.4060401@cisco.com> Date: Mon, 22 Aug 2005 10:08:21 -0700 From: Arun Satyanarayana Organization: Cisco Systems User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: Lou Berger , Dimitri Papadimitriou , Reshad Rahman , Anca Zamfir , Junaid Israr , ccamp@ops.ietf.org, "Arun Satyanarayana (asatyana)" Subject: Re: Nit in draft-ietf-ccamp-rsvp-restart-ext-03.txt References: <00e301c5a662$9baba390$20849ed9@Puppy> In-Reply-To: <00e301c5a662$9baba390$20849ed9@Puppy> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Aug 2005 17:08:28.0726 (UTC) FILETIME=[1DA69560:01C5A73C] 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: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Hi Adrian, Thanks for catching the typo. There was also another minor comment during last call (addressed to Lou privately, I believe). We'll re-spin by the end of the week. Thanks, Arun ============================================================== Adrian Farrel wrote: > Hi, > > Looks like the extra last call on this I-D completed without further > comment. > > Unfortunately, scanning through the draft I found a nit. > So you need to do a quick re-spin. I think this should take you less than > an hour. Please let me know if you can't do it by the end of the week and > I will do it myself. > > Thanks, > Adrian > === > Section 2 > Spurious text relating to cross-references > The reader is assumed to be familiar with the terminology defined in > xref target="RFC3209" /> and [RFC3473]. From owner-ccamp@ops.ietf.org Tue Aug 23 06:31:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7W3p-0000uj-AB for ccamp-archive@megatron.ietf.org; Tue, 23 Aug 2005 06:31: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 GAA25036 for ; Tue, 23 Aug 2005 06:31:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7W3o-0007jc-QH for ccamp-archive@ietf.org; Tue, 23 Aug 2005 06:31:23 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7Vuv-0001Ju-KR for ccamp-data@psg.com; Tue, 23 Aug 2005 10:22:05 +0000 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7Vut-0001Jg-TJ for ccamp@ops.ietf.org; Tue, 23 Aug 2005 10:22:04 +0000 Received: from [192.168.0.102] (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 j7NALtRJ017366; Tue, 23 Aug 2005 03:21:58 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <430AF8C4.6050804@grotto-networking.com> Date: Tue, 23 Aug 2005 03:21:56 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Not voting on the charter milestones References: <012c01c5a66f$1672a540$20849ed9@Puppy> In-Reply-To: <012c01c5a66f$1672a540$20849ed9@Puppy> 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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Yes. Greg B. Adrian Farrel wrote: >Hi, > >Of course we don't vote, but Kireeti and I do need evidence of rough >consensus. We have a had a good number of emails picking up on small >points, but nothing of any substance said against the proposed milestones. >We have some evidence of general support. > >Can you please speak up. >Do you broadly support the proposed new CCAMP milestones? > >Thanks, >Adrian > > > > > From owner-ccamp@ops.ietf.org Tue Aug 23 15:41:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7eeF-0002Ff-8U for ccamp-archive@megatron.ietf.org; Tue, 23 Aug 2005 15:41: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 PAA26431 for ; Tue, 23 Aug 2005 15:41:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7eeK-0007si-Rr for ccamp-archive@ietf.org; Tue, 23 Aug 2005 15:41:38 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7eWq-000I16-Ik for ccamp-data@psg.com; Tue, 23 Aug 2005 19:33:48 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7eWo-000I0S-MT for ccamp@ops.ietf.org; Tue, 23 Aug 2005 19:33:46 +0000 Received: from du-069-0390.access.clara.net ([217.158.145.136] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E7eWm-000KKl-Fz for ccamp@ops.ietf.org; Tue, 23 Aug 2005 20:33:45 +0100 Message-ID: <03a601c5a819$f3448550$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: ASON Routing evaluation ready for WG last call? Date: Tue, 23 Aug 2005 20:34:38 +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: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Just a reminder. Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, August 11, 2005 4:31 PM Subject: ASON Routing evaluation ready for WG last call? > Hi, > > draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt > > The DT said in Paris that this I-D is cooked apart from "some minor > editing". > > I asked the room if anyone would object to a WG last call now, and Alex > (as AD) suggested that more people should read the I-D before we decided > whether it was ready for last call. > > This gives me the odd position of having a last call for a last call :-) > > This email gives notice that you need to read this I-D and make comments > before 11th September 2005. > > Barring unresolved comments we will have a WG last call starting then. > > Thanks, > Adrian > > > > From owner-ccamp@ops.ietf.org Tue Aug 23 15:43:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7egC-0002mk-LO for ccamp-archive@megatron.ietf.org; Tue, 23 Aug 2005 15:43:28 -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 PAA26562 for ; Tue, 23 Aug 2005 15:43:26 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7egI-0007vX-99 for ccamp-archive@ietf.org; Tue, 23 Aug 2005 15:43:39 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7ebk-000INA-2x for ccamp-data@psg.com; Tue, 23 Aug 2005 19:38:52 +0000 Received: from [216.82.254.83] (helo=mail126.messagelabs.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E7ebi-000IMe-2p for ccamp@ops.ietf.org; Tue, 23 Aug 2005 19:38:50 +0000 X-VirusChecked: Checked X-Env-Sender: dbrungard@att.com X-Msg-Ref: server-13.tower-126.messagelabs.com!1124825904!6310143!11 X-StarScan-Version: 5.4.15; banners=-,-,- X-Originating-IP: [192.128.133.132] Received: (qmail 25273 invoked from network); 23 Aug 2005 19:38:48 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (192.128.133.132) by server-13.tower-126.messagelabs.com with SMTP; 23 Aug 2005 19:38:48 -0000 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh3i.attrh.att.com (7.2.052) id 42E3BC2B00FA6E14; Tue, 23 Aug 2005 15:38:48 -0400 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: Not voting on the charter milestones Date: Tue, 23 Aug 2005 14:38:47 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0A54A77C@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Not voting on the charter milestones Thread-Index: AcWmbt6g16FomRzfTzOiffPJjVl96QBq07nw From: "Brungard, Deborah A, ALABS" To: "Adrian Farrel" , 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Yes- Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Sunday, August 21, 2005 12:39 PM To: ccamp@ops.ietf.org Subject: Not voting on the charter milestones Hi, Of course we don't vote, but Kireeti and I do need evidence of rough consensus. We have a had a good number of emails picking up on small points, but nothing of any substance said against the proposed milestones. We have some evidence of general support. Can you please speak up. Do you broadly support the proposed new CCAMP milestones? Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Aug 24 01:19:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7nfF-0000qG-MW for ccamp-archive@megatron.ietf.org; Wed, 24 Aug 2005 01:19: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 BAA01334 for ; Wed, 24 Aug 2005 01:19:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7nfT-0001qs-9M for ccamp-archive@ietf.org; Wed, 24 Aug 2005 01:19:21 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7nYR-00078K-O1 for ccamp-data@psg.com; Wed, 24 Aug 2005 05:12:03 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7nYQ-00077y-Ag; Wed, 24 Aug 2005 05:12:02 +0000 Message-ID: <430C0187.2030307@psg.com> Date: Wed, 24 Aug 2005 07:11:35 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arun Satyanarayana CC: Adrian Farrel , Lou Berger , Dimitri Papadimitriou , Reshad Rahman , Anca Zamfir , Junaid Israr , ccamp@ops.ietf.org Subject: Re: Nit in draft-ietf-ccamp-rsvp-restart-ext-03.txt References: <00e301c5a662$9baba390$20849ed9@Puppy> <430A0685.4060401@cisco.com> In-Reply-To: <430A0685.4060401@cisco.com> 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=-5.9 required=5.0 tests=ALL_TRUSTED,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: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit hi arun, would it be possible to have a small record of the changes to post on the mailing list - thanks, - dimitri. Arun Satyanarayana wrote: > Hi Adrian, > > Thanks for catching the typo. > > There was also another minor comment during last call (addressed to Lou > privately, I believe). We'll re-spin by the end of the week. > > Thanks, > Arun > ============================================================== > Adrian Farrel wrote: > >> Hi, >> >> Looks like the extra last call on this I-D completed without further >> comment. >> >> Unfortunately, scanning through the draft I found a nit. >> So you need to do a quick re-spin. I think this should take you less than >> an hour. Please let me know if you can't do it by the end of the week and >> I will do it myself. >> >> Thanks, >> Adrian >> === >> Section 2 >> Spurious text relating to cross-references >> The reader is assumed to be familiar with the terminology defined in >> xref target="RFC3209" /> and [RFC3473]. > > > > . > From owner-ccamp@ops.ietf.org Wed Aug 24 02:32:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ood-00062z-VQ for ccamp-archive@megatron.ietf.org; Wed, 24 Aug 2005 02:32: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 CAA01671 for ; Wed, 24 Aug 2005 02:32:48 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7oop-0003sC-GP for ccamp-archive@ietf.org; Wed, 24 Aug 2005 02:33:05 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7oi2-000Bsp-1K for ccamp-data@psg.com; Wed, 24 Aug 2005 06:26:02 +0000 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7ohy-000BsV-IZ for ccamp@ops.ietf.org; Wed, 24 Aug 2005 06:25:59 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7O6PuRV017360 for ; Wed, 24 Aug 2005 15:25:56 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7O6PuCp023339 for ; Wed, 24 Aug 2005 15:25:56 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7O6PtBD023334 for ; Wed, 24 Aug 2005 15:25:56 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7O6Ptcq016631 for ; Wed, 24 Aug 2005 15:25:55 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7O6PtNI016626 for ; Wed, 24 Aug 2005 15:25:55 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7O6Pt6M003758 for ; Wed, 24 Aug 2005 15:25:55 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7O6Psw3026788 for ; Wed, 24 Aug 2005 15:25:54 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb0.m.ecl.ntt.co.jp [129.60.5.140]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j7O6PsHT026783 for ; Wed, 24 Aug 2005 15:25:54 +0900 (JST) Received: from INOUE-LETS-CFW2.lab.ntt.co.jp by imb.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id PAA29132 for ; Wed, 24 Aug 2005 15:25:53 +0900 (JST) Message-Id: <6.0.0.20.2.20050824152348.05480d08@imb.m.ecl.ntt.co.jp> X-Sender: ii004@imb.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 24 Aug 2005 15:25:29 +0900 To: From: "inoue.ichiro@lab.ntt.co.jp" Subject: RE: Not voting on the charter milestones Mime-Version: 1.0 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.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: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Hi, Yes, I support. Ichiro Inoue -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Sunday, August 21, 2005 12:39 PM To: ccamp@ops.ietf.org Subject: Not voting on the charter milestones Hi, Of course we don't vote, but Kireeti and I do need evidence of rough consensus. We have a had a good number of emails picking up on small points, but nothing of any substance said against the proposed milestones. We have some evidence of general support. Can you please speak up. Do you broadly support the proposed new CCAMP milestones? Thanks, Adrian From owner-ccamp@ops.ietf.org Wed Aug 24 03:18:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7pWe-0001cq-0v for ccamp-archive@megatron.ietf.org; Wed, 24 Aug 2005 03:18:20 -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 DAA04063 for ; Wed, 24 Aug 2005 03:18:18 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7pWu-0005Fx-3J for ccamp-archive@ietf.org; Wed, 24 Aug 2005 03:18:37 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7pQc-000FFd-1H for ccamp-data@psg.com; Wed, 24 Aug 2005 07:12:06 +0000 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7pQX-000FF8-7X for ccamp@ops.ietf.org; Wed, 24 Aug 2005 07:12:01 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Wed, 24 Aug 2005 16:13:33 +0900 X-ReadCheckName: ccamp%40ops.ietf.org Thread-Topic: Not voting on the charter milestones X-ReadCheckMessageID: <2d2ead76-6b1c-4aca-96de-c71bf898ad3a@etri.re.kr> thread-index: AcWoe1Z9+tofRS/4THmCwlpAVSe9/Q== Content-Transfer-Encoding: 7bit Reply-To: =?ks_c_5601-1987?B?sei/tcit?= From: =?ks_c_5601-1987?B?sei/tcit?= To: "Adrian Farrel" , Subject: RE: Not voting on the charter milestones Date: Wed, 24 Aug 2005 16:13:33 +0900 Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBPQU2x4rz6xsAsILTjtOc=?= Message-ID: <851501c5a87b$5681d440$8310fe81@email1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_8510_01C5A8C6.C6673250" 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: 24 Aug 2005 07:13:33.0776 (UTC) FILETIME=[56A0F500:01C5A87B] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Level: *** X-Spam-Status: No, score=3.3 required=5.0 tests=AWL,BAYES_50,HTML_50_60, HTML_CONVERTED,HTML_IMAGE_ONLY_16,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: 4.6 (++++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This is a multi-part message in MIME format. ------=_NextPart_000_8510_01C5A8C6.C6673250 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ------=_NextPart_000_8510_01C5A8C6.C6673250 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy Ij4NCjxESVY+PEJSPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyA8U1RS T05HPkZyb206PC9TVFJPTkc+ICJBZHJpYW4gRmFycmVsIiAmbHQ7YWRyaWFuQG9sZGRvZy5jby51 ayZndDs8QlI+Jmd0OyA8U1RST05HPkZyb20gRGF0ZTo8L1NUUk9ORz4gMjAwNS0wOC0yMiC/wMD8 IDE6Mzk6MDg8QlI+Jmd0OyA8U1RST05HPlRvOjwvU1RST05HPiAiY2NhbXBAb3BzLmlldGYub3Jn IiAmbHQ7Y2NhbXBAb3BzLmlldGYub3JnJmd0OzxCUj4mZ3Q7IDxTVFJPTkc+Q2M6PC9TVFJPTkc+ IDxCUj4mZ3Q7IDxTVFJPTkc+U3ViamVjdDo8L1NUUk9ORz4gTm90IHZvdGluZyBvbiB0aGUgY2hh cnRlciBtaWxlc3RvbmVzPEJSPiZndDsgPEJSPg0KPERJVj48IS0tIENvbnZlcnRlZCBmcm9tIHRl eHQvcGxhaW4gZm9ybWF0IC0tPiZndDsgPEJSPg0KPFA+PEZPTlQgc2l6ZT0yPiZndDsgSGksPEJS PiZndDsgPEJSPiZndDsgT2YgY291cnNlIHdlIGRvbid0IHZvdGUsIGJ1dCBLaXJlZXRpIGFuZCBJ IGRvIG5lZWQgZXZpZGVuY2Ugb2Ygcm91Z2g8QlI+Jmd0OyBjb25zZW5zdXMuIFdlIGhhdmUgYSBo YWQgYSBnb29kIG51bWJlciBvZiBlbWFpbHMgcGlja2luZyB1cCBvbiBzbWFsbDxCUj4mZ3Q7IHBv aW50cywgYnV0IG5vdGhpbmcgb2YgYW55IHN1YnN0YW5jZSBzYWlkIGFnYWluc3QgdGhlIHByb3Bv c2VkIG1pbGVzdG9uZXMuPEJSPiZndDsgV2UgaGF2ZSBzb21lIGV2aWRlbmNlIG9mIGdlbmVyYWwg c3VwcG9ydC48QlI+Jmd0OyA8QlI+Jmd0OyBDYW4geW91IHBsZWFzZSBzcGVhayB1cC48QlI+Jmd0 OyBEbyB5b3UgYnJvYWRseSBzdXBwb3J0IHRoZSBwcm9wb3NlZCBuZXcgQ0NBTVAgbWlsZXN0b25l cz88QlI+PC9GT05UPjwvUD4NCjxQPjxGT05UIHNpemU9Mj5ZZXMsPEJSPjxCUj5UaGFua3M8QlI+ PEJSPlJlZ2FyZHMuLi4gWW91bmc8QlI+PEJSPiZndDsgVGhhbmtzLDxCUj4mZ3Q7IEFkcmlhbjxC Uj4mZ3Q7PEJSPjwvUD48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxh eTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0iaHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0 ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9Y2NhbXBAb3BzLmlldGYub3JnJm5hbWU9Y2NhbXAl NDBvcHMuaWV0Zi5vcmcmZnJvbWVtYWlsPXlod2tpbUBldHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0My ZDJlYWQ3Ni02YjFjLTRhY2EtOTZkZS1jNzFiZjg5OGFkM2FAZXRyaS5yZS5rciUzRSI+ ------=_NextPart_000_8510_01C5A8C6.C6673250-- From owner-ccamp@ops.ietf.org Wed Aug 24 05:23:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7rTz-0005jx-Sr for ccamp-archive@megatron.ietf.org; Wed, 24 Aug 2005 05:23: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 FAA08983 for ; Wed, 24 Aug 2005 05:23:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7rUH-0000r9-Ny for ccamp-archive@ietf.org; Wed, 24 Aug 2005 05:24:02 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7rLK-000NtY-Aa for ccamp-data@psg.com; Wed, 24 Aug 2005 09:14:46 +0000 Received: from [129.254.16.131] (helo=email1.etri.info) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7rLI-000NtK-AY for ccamp@ops.ietf.org; Wed, 24 Aug 2005 09:14:44 +0000 Received: from mail pickup service by email1.etri.info with Microsoft SMTPSVC; Wed, 24 Aug 2005 18:16:16 +0900 Thread-Topic: L2SC [Was: Moving forward with the CCAMP charter] thread-index: AcWojHscJFB6MppNR0qz2reOZpx7VQ== Reply-To: "CHO, JAI HYUNG" From: "CHO, JAI HYUNG" To: "Adrian Farrel" , Subject: RE: L2SC [Was: Moving forward with the CCAMP charter] Date: Wed, 24 Aug 2005 18:16:16 +0900 Comment: GQ19@|@ZEk=E?,18?x, BcN1b MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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: 24 Aug 2005 09:16:16.0649 (UTC) FILETIME=[7B3E3790:01C5A88C] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.2 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: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit A bit late in this response, but..... I do support the proposed CCAMP milestone, and, just in case if L2SC work is considered as new WG/BoF, I'd most welcome such idea, and will support the new WG. thanks Dr. Jaihyung Cho ETRI, Korea phone : 042) 860-5514 oversea: +82-42-860-5514 fax: +82-42-861-5550 -----?? ???----- From: "Adrian Farrel" From Date: 2005-08-17 ?? 6:20:04 To: "CHO, JAI HYUNG" , "ccamp@ops.ietf.org" Cc: Subject: L2SC [Was: Moving forward with the CCAMP charter] Hi Jaihyung, The Ethernet GMPLS work has certainly not been forgotten! The work of the design team is very important and we need more people to read and digest draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt. it is particularly important that folk read this draft rather than relying on scare stories or email threads. Many of the common concerns and issues have been carefully answered by the DT, and many of the other are not actually raised in this draft. For the moment, the CCAMP list remains the correct place to discuss these issues, but it would seem that the work involved is both larger than the scope of the CCAMP charter and larger than can be easily swallowed by the existing working group (you will have noticed that there are plenty of other things to occupy the WG's time). For this reason (and see the CCAMP draft minutes) we are currently investigating whether there could be a better home for this work. The most obvious solution is to create a new WG, but this would obviously require careful scoping and also would need support from the community. More information on this as it becomes available. Thanks, Adrian ----- Original Message ----- From: "CHO, JAI HYUNG" To: "Adrian Farrel" ; Sent: Wednesday, August 17, 2005 9:10 AM Subject: RE: Moving forward with the CCAMP charter > > Hi, Adrian > > Thank you for your milestone work. > However, I can not find L2SC work in your document. > Where does it belong to ? > I believe there's some number of people supporting thie work > and also we see clear industry need for this work. > I think it would be good if we have L2SC milestone > at least for framework and solution document. > > thanks > > Jaihyung > > > Dr. Jaihyung Cho > ETRI, Korea > phone : 042) 860-5514 > oversea: +82-42-860-5514 > fax: +82-42-861-5550 > > > > > -----?? ???----- > From: "Adrian Farrel" > From Date: 2005-08-16 ?? 8:28:11 > To: "ccamp@ops.ietf.org" > Cc: "zinin@psg.com" , "'Kireeti Kompella'" > Subject: Moving forward with the CCAMP charter > > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. > > This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. > > Thanks, > Adrian > > > > > > From owner-ccamp@ops.ietf.org Wed Aug 24 07:57:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7tsr-0000cf-VY for ccamp-archive@megatron.ietf.org; Wed, 24 Aug 2005 07:57: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 HAA15724 for ; Wed, 24 Aug 2005 07:57:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7tt6-0005Xx-5i for ccamp-archive@ietf.org; Wed, 24 Aug 2005 07:57:53 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7tlI-0008Sk-JM for ccamp-data@psg.com; Wed, 24 Aug 2005 11:49:44 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7tlF-0008SK-Bi; Wed, 24 Aug 2005 11:49:41 +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 1E7tlB-000MF7-HK; Wed, 24 Aug 2005 12:49:39 +0100 Message-ID: <045301c5a8a2$46bb8570$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Bill Fenner" Cc: Subject: CCAMP Requests to add new milestones to its charter Date: Wed, 24 Aug 2005 12:50:52 +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: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Hi Alex and Bill, The CCAMP working group has had further discussions about the potential work it could do over the next 1.5 to 2 years. This has led us to produce the following set of milestones with which there appears to be overwhelming consensual support within the working group. Therefore, we would like to ask you to arrange for us to have these milestones added to our charter. You will notice that the proposed milestones are unusually detailed. At the moment we feel that this is important to help focus the working group into the right activities and to ensure that we deliver. We could (of course) drop the interim milestones from the charter if this would make people more comfortable - we can still run the detailed milestones for our own benefit. At this stage we feel that it is not essential to modify the text of our charter. Although we could take this opportunity to tidy it up and improve the focus, we feel that all of the proposed milestones fall within the existing charter work. Please let us know your thoughts and what the next steps should be. Thanks, Adrian and Kireeti ==== Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh membership Nov 05 Submit ASON Routing evaluation I-D for IESG review Nov 05 First version of WG I-D on path computation implementation advice Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Nov 05 First version WG I-D MPLS to GMPLS migration strategies Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS Nov 05 First version WG I-D Change of LSP ownership between management and control planes Dec 05 First version of WG I-D for ASON Routing solutions Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Dec 05 Submit Per-domain path computation signaling I-D for IESG review Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region Networks Dec 05 First version WG I-D for Evaluation of existing protocols for MLN/MRN Dec 05 First version WG I-D for Protocol solutions for MLN/MRN Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG review Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module Jan 06 First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and solutions Jan 06 First version WG I-D GMPLS OAM Requirements Jan 06 First version WG I-D Routing and signaling for link viability constraints Feb 06 Submit LSP Stitching I-D for IESG review Mar 06 First version of WG informational I-D Aligning GMPLS protocols across the standards bodies Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for IESG review Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module Mar 06 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Jun 06 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review Jun 06 Submit Change of LSP ownership between management and control planes I-D for IESG review Aug 06 Submit path computation implementation advice I-D for IESG review Oct 06 Submit ASON Routing solutions I-D for IESG review Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG review Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Dec 06 Submit GMPLS OAM Requirements I-D for IESG review Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review Oct 07 Submit Routing and signaling for link viability constraints I-D for IESG review Oct 07 Recharter or close Working Group From owner-ccamp@ops.ietf.org Wed Aug 24 15:51:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81Hb-0007MO-3S for ccamp-archive@megatron.ietf.org; Wed, 24 Aug 2005 15:51: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 PAA15439 for ; Wed, 24 Aug 2005 15:51:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81Hp-0005AG-Ni for ccamp-archive@ietf.org; Wed, 24 Aug 2005 15:51:58 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E814d-000Fvp-Jd for ccamp-data@psg.com; Wed, 24 Aug 2005 19:38:11 +0000 Received: from [66.163.169.225] (helo=smtp105.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E814a-000FvY-Dn for ccamp@ops.ietf.org; Wed, 24 Aug 2005 19:38:08 +0000 Received: (qmail 38160 invoked from network); 24 Aug 2005 19:38:07 -0000 Received: from unknown (HELO LIFEBOOK) (vsharma87@221.128.174.46 with login) by smtp105.mail.sc5.yahoo.com with SMTP; 24 Aug 2005 19:38:07 -0000 Reply-To: From: "Vishal Sharma" To: "'Adrian Farrel'" , Subject: RE: Not voting on the charter milestones Date: Wed, 24 Aug 2005 12:37:39 -0700 Organization: Metanoia, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcWmbuPlOguWax5UTvebX8Nf64ZezwCdDp4A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <012c01c5a66f$1672a540$20849ed9@Puppy> 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 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Adrian, > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, August 21, 2005 9:39 AM > To: ccamp@ops.ietf.org > Subject: Not voting on the charter milestones > > Hi, > > Of course we don't vote, but Kireeti and I do need evidence > of rough consensus. We have a had a good number of emails > picking up on small points, but nothing of any substance said > against the proposed milestones. > We have some evidence of general support. > > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? Yes. (Perhaps a few things will need to be refined as the discussion proceeds further, but I think broadly it is a good set of milestones -- and kudos on taking the time to get them down to such detail.) -Vishal From owner-ccamp@ops.ietf.org Wed Aug 24 20:34:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E85h4-0004I9-4Y for ccamp-archive@megatron.ietf.org; Wed, 24 Aug 2005 20:34:12 -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 UAA06051 for ; Wed, 24 Aug 2005 20:34:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E85hM-0007LQ-80 for ccamp-archive@ietf.org; Wed, 24 Aug 2005 20:34:36 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E85ay-000A9H-C5 for ccamp-data@psg.com; Thu, 25 Aug 2005 00:27:52 +0000 Received: from [192.26.91.6] (helo=mandala.kddilabs.jp) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E85aw-000A93-Is for ccamp@ops.ietf.org; Thu, 25 Aug 2005 00:27:50 +0000 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 3A9B1EC8BD; Thu, 25 Aug 2005 09:27:49 +0900 (JST) Received: from platinum.onw.kddilabs.jp (platinum.onw.kddilabs.jp [2001:200:601:1300:172:19:83:254]) by mandala.kddilabs.jp (Postfix) with ESMTP id 9BD3AEC8BA; Thu, 25 Aug 2005 09:27:48 +0900 (JST) Received: from [IPv6:2001:200:601:1e02:0:5efe:ac13:570f] (unknown [IPv6:2001:200:601:1e02:0:5efe:ac13:570f]) by platinum.onw.kddilabs.jp (Postfix) with ESMTP id C09D8578103; Thu, 25 Aug 2005 09:20:48 +0900 (JST) Message-ID: <430D108C.80802@kddilabs.jp> Date: Thu, 25 Aug 2005 09:27:56 +0900 From: Tomohiro Otani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Not voting on the charter milestones References: <012c01c5a66f$1672a540$20849ed9@Puppy> In-Reply-To: <012c01c5a66f$1672a540$20849ed9@Puppy> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new 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: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Hello everyone, I agree with the proposed new milestones. Regards, tomo Adrian Farrel wrote: >Hi, > >Of course we don't vote, but Kireeti and I do need evidence of rough >consensus. We have a had a good number of emails picking up on small >points, but nothing of any substance said against the proposed milestones. >We have some evidence of general support. > >Can you please speak up. >Do you broadly support the proposed new CCAMP milestones? > >Thanks, >Adrian > > > > > From owner-ccamp@ops.ietf.org Fri Aug 26 07:35:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8cUj-0006GH-U1 for ccamp-archive@megatron.ietf.org; Fri, 26 Aug 2005 07:35: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 HAA12661 for ; Fri, 26 Aug 2005 07:35:37 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8cVM-0002jQ-Po for ccamp-archive@ietf.org; Fri, 26 Aug 2005 07:36:22 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8cMc-00084Z-Ub for ccamp-data@psg.com; Fri, 26 Aug 2005 11:27:14 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8cMY-00084F-T3 for ccamp@ops.ietf.org; Fri, 26 Aug 2005 11:27:11 +0000 Received: from du-069-0157.access.clara.net ([217.158.132.157] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E8cMP-000EoU-Dg for ccamp@ops.ietf.org; Fri, 26 Aug 2005 12:27:09 +0100 Message-ID: <0be801c5aa31$73753df0$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Final draft of response to the OIF Date: Fri, 26 Aug 2005 12:27: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: 958aa603499a3de6b2b87d68741ed60e Content-Transfer-Encoding: 7bit Thanks to all who have commented so far. Here is an updated draft. I plan to send by the end of August, so furhter comments should be made quickly. Thanks, Adrian ====== 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. 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. We believe that this final sentence should read "greater than or equal to 1," and that this interpretation resolves all of your issues and makes the text consistent with the examples. We plan to issue a revision to RFC 3946 to make this clarification. The text of this clarification still needs to be agreed by the CCAMP working group, but the draft revision contains the nodes as updated below with the addition of a third note as shown. 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 implies a number of contiguous components greater than or equal to 1. Note 3: Following these rules, when requesting a VC-4 signal, the RCC and the NCC values must be set to 0 whereas for an STS-3c SPE signal, the RCC and the NCC values must be set 1. However, if local conditions allow and since the setting of the RCC and NCC values is locally driven, the requesting upstream node MAY set the RCC and NCC values to either SDH or SONET settings without impacting the function. Moreover, the downstream node SHOULD accept the requested values if local conditions allow. If these values can not be supported, the receiver downstream node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively). > 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 is currently discussing the use of GMPLS for control of Ethernet devices. We will respond to this point in a separate email. Best regards, Adrian Farrel Kireeti Kompella From owner-ccamp@ops.ietf.org Fri Aug 26 11:07:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8foA-0000Nm-JG for ccamp-archive@megatron.ietf.org; Fri, 26 Aug 2005 11:07: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 LAA25472 for ; Fri, 26 Aug 2005 11:07:52 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fom-0001Ic-Hs for ccamp-archive@ietf.org; Fri, 26 Aug 2005 11:08:41 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8fgX-000O1S-Jx for ccamp-data@psg.com; Fri, 26 Aug 2005 15:00:01 +0000 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8fgU-000O0K-Lo for ccamp@ops.ietf.org; Fri, 26 Aug 2005 14:59:58 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 26 Aug 2005 15:11:41 +0000 X-SBRS: None X-IronPort-AV: i="3.96,144,1122854400"; d="scan'208"; a="27050834:sNHT26338212" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Aug 2005 09:59:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Final draft of response to the OIF Date: Fri, 26 Aug 2005 09:57:07 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWqMXrRFH6Zn8PbTZ+MdFV9yog1bAAHBWYQ From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" , X-OriginalArrivalTime: 26 Aug 2005 14:59:17.0654 (UTC) FILETIME=[BB4DDB60:01C5AA4E] Content-Transfer-Encoding: 7bit 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: b7b1e91f6d312d4248b994050b22d659 Content-Transfer-Encoding: 7bit Hi Adrian, I proposed a simple (and I think technically sound) solution to item #1 and saw no objections, however the answer has not changed. I do not understand the reason for different encodings for VC-4 and STS-3c SPE. I think they should be the same, unless there is a technical need to distinguish them. I also do not understand the RCC=1 NCC=1 encoding, since the rule contained in the current RFC actually makes more sense. If there is only one signal element, there is no contiguous concatenation, by definition. So I fail to see the usefulness of these encodings. Regards, Ben > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, August 26, 2005 6:27 AM > To: ccamp@ops.ietf.org > Subject: Final draft of response to the OIF > > Thanks to all who have commented so far. > > Here is an updated draft. I plan to send by the end of > August, so furhter > comments should be made quickly. > > Thanks, > Adrian > > ====== > > 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. > > 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. > > We believe that this final sentence should read "greater than > or equal to > 1," and that this interpretation resolves all of your issues > and makes the > text consistent with the examples. > > We plan to issue a revision to RFC 3946 to make this > clarification. The > text of this clarification still needs to be agreed by the > CCAMP working > group, but the draft revision contains the nodes as updated > below with the > addition of a third note as shown. > > 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 implies a number of contiguous components greater than or > equal to 1. > > Note 3: Following these rules, when requesting a VC-4 signal, the > RCC and the NCC values must be set to 0 whereas for an > STS-3c SPE > signal, the RCC and the NCC values must be set 1. However, if > local conditions allow and since the setting of the RCC and NCC > values is locally driven, the requesting upstream node MAY set > the RCC and NCC values to either SDH or SONET settings without > impacting the function. Moreover, the downstream node SHOULD > accept the requested values if local conditions allow. If these > values can not be supported, the receiver downstream node MUST > generate a PathErr/NOTIFICATION message (see Sections 2.2 and > 2.3, respectively). > > > 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 is currently discussing the use of GMPLS for > control of Ethernet devices. We will respond to this point in > a separate > email. > > Best regards, > Adrian Farrel > Kireeti Kompella > > ============================================================ 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 Fri Aug 26 13:29:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8i1U-0000yr-8z for ccamp-archive@megatron.ietf.org; Fri, 26 Aug 2005 13:29: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 NAA03014 for ; Fri, 26 Aug 2005 13:29:45 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8i2F-0006Dl-Ta for ccamp-archive@ietf.org; Fri, 26 Aug 2005 13:30:36 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8hvp-0009KA-Mu for ccamp-data@psg.com; Fri, 26 Aug 2005 17:23:57 +0000 Received: from [147.28.0.62] (helo=usmovnazinin.alcatel.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8hvo-0009Jq-L4; Fri, 26 Aug 2005 17:23:56 +0000 Date: Fri, 26 Aug 2005 10:23:44 -0700 From: Alex Zinin Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <99619327.20050826102344@psg.com> To: "Adrian Farrel" CC: "Bill Fenner" , ccamp@ops.ietf.org Subject: Re: CCAMP Requests to add new milestones to its charter In-Reply-To: <045301c5a8a2$46bb8570$c5919ed9@Puppy> References: <045301c5a8a2$46bb8570$c5919ed9@Puppy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-4.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, PRIORITY_NO_NAME autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Adrian, Ack. Will review and discuss with the WG chairs. -- Alex http://www.psg.com/~zinin Wednesday, August 24, 2005, 4:50:52 AM, Adrian Farrel wrote: > Hi Alex and Bill, > The CCAMP working group has had further discussions about the potential > work it could do over the next 1.5 to 2 years. This has led us to produce > the following set of milestones with which there appears to be > overwhelming consensual support within the working group. > Therefore, we would like to ask you to arrange for us to have these > milestones added to our charter. > You will notice that the proposed milestones are unusually detailed. At > the moment we feel that this is important to help focus the working group > into the right activities and to ensure that we deliver. We could (of > course) drop the interim milestones from the charter if this would make > people more comfortable - we can still run the detailed milestones for our > own benefit. > At this stage we feel that it is not essential to modify the text of our > charter. Although we could take this opportunity to tidy it up and improve > the focus, we feel that all of the proposed milestones fall within the > existing charter work. > Please let us know your thoughts and what the next steps should be. > Thanks, > Adrian and Kireeti > ==== > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS > and OSPF > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh > membership > Nov 05 Submit ASON Routing evaluation I-D for IESG review > Nov 05 First version of WG I-D on path computation implementation advice > Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS > and OSPF > Nov 05 First version WG I-D MPLS to GMPLS migration strategies > Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS > Nov 05 First version WG I-D Change of LSP ownership between management and > control planes > Dec 05 First version of WG I-D for ASON Routing solutions > Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG > review > Dec 05 Submit Per-domain path computation signaling I-D for IESG review > Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region > Networks > Dec 05 First version WG I-D for Evaluation of existing protocols for > MLN/MRN > Dec 05 First version WG I-D for Protocol solutions for MLN/MRN > Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG > review > Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review > Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module > Jan 06 First version WG Informational I-D for Analysis of inter-domain > issues for disjoint and protected paths > Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF > for IESG review > Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and > solutions > Jan 06 First version WG I-D GMPLS OAM Requirements > Jan 06 First version WG I-D Routing and signaling for link viability > constraints > Feb 06 Submit LSP Stitching I-D for IESG review > Mar 06 First version of WG informational I-D Aligning GMPLS protocols > across the standards bodies > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for > IESG review > Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module > Mar 06 First version of WG I-D for additional MIB module to cover RSVP-TE > signaling extensions > Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for > IESG review > Jun 06 Submit Informational I-D for Analysis of inter-domain issues for > disjoint and protected paths for IESG review > Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review > Jun 06 Submit Change of LSP ownership between management and control > planes I-D for IESG review > Aug 06 Submit path computation implementation advice I-D for IESG review > Oct 06 Submit ASON Routing solutions I-D for IESG review > Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D > for IESG review > Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG review > Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for > IESG review > Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review > Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review > Dec 06 Submit GMPLS OAM Requirements I-D for IESG review > Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review > Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review > Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor > and IESG review > Oct 07 Submit Routing and signaling for link viability constraints I-D for > IESG review > Oct 07 Recharter or close Working Group From owner-ccamp@ops.ietf.org Fri Aug 26 13:47:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8iId-0007M5-4F for ccamp-archive@megatron.ietf.org; Fri, 26 Aug 2005 13:47: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 NAA03828 for ; Fri, 26 Aug 2005 13:47:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8iJK-0006mt-CI for ccamp-archive@ietf.org; Fri, 26 Aug 2005 13:48:19 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8iDm-000AyI-K1 for ccamp-data@psg.com; Fri, 26 Aug 2005 17:42:30 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8iDj-000Axy-4M for ccamp@ops.ietf.org; Fri, 26 Aug 2005 17:42:27 +0000 Received: from du-069-0146.access.clara.net ([217.158.132.146] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1E8iDZ-0008co-FT; Fri, 26 Aug 2005 18:42:25 +0100 Message-ID: <0c2201c5aa65$e0b4c7d0$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Arthi Ayyangar" , "'Jean Philippe Vasseur'" Cc: Subject: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt Date: Fri, 26 Aug 2005 18:42:52 +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: bc102ac530ba955ef81f1f75b8bebe44 Content-Transfer-Encoding: 7bit Hi, In Paris you said that you hoped for comments on this revision soon so that you could do a quick re-spin and request last call. So here are my comments. Cheers, Adrian === Section 2.1 Contiguous - A contiguous TE LSP is a single end-to-end TE LSP that is setup across multiple domains using RSVP-TE signaling procedures described in [RSVP-TE]and [RSVP-GMPLS]. No additional TE LSPs are required to signal a contiguous TE LSP and the same RSVP-TE information for the TE LSP is maintained along the entire LSP path. s/[RSVP-TE]and/[RSVP-TE] and/ ==== Section 2.1 Nesting - Nesting one or more TE LSPs into another TE LSP is described in [LSP-HIERARCHY]. This technique can also be used to nest one or more inter-domain TE LSPs into an intra-domain FA-LSP. While similar to stitching in the control plane, in the data plane, nesting allows for one or more inter-domain LSPs to be transported over a single intra-domain FA-LSP using the label stacking construct. s/technique can also be used/technique can be used/ Not sure that I like you saying "FA-LSP" here. The intra-domain LSP may be an FA-LSP or it may be a TE LSP advertised as a TE link into the other domain. It's a bit odd to compare with stitching which you haven't described yet. Suggest you re-write the paragraph as... Nesting - Nesting one or more TE LSPs into another TE LSP is described in [LSP-HIERARCHY]. This technique can be used to nest one or more inter-domain TE LSPs into an intra-domain TE LSP using the label stacking construct. ==== Section 2.1 Stitching - The concept of LSP stitching as well as the required signaling procedures are described in [LSP-STITCHING]. This technique can be used to stitch an inter-domain TE LSP to an intra-domain LSP segment. A inter-domain stitched TE LSP is a TE LSP made up of different TE LSP segments within each domain which are "stitched" together in the data plane so that an end-to-end LSP is achieved in the data plane. In the control plane, however, the different LSP segments are signaled as distinct RSVP sessions which are independent from the RSVP session for the inter-domain LSP. s/signaling procedures are described/signaling procedures is described/ (yes, really) You could add the comparison with hierarchies here. For example... While stitching is similar to nesting in the control plane, in the data plane stitching allows for only one inter-domain LSPs to be associated with any one intra-domain LSP, but does not require the use of label stacks. ==== Section 2.1 I think this section should say that later in the document you will define signaling extensions that allow the initiator of an inter-domain LSP to request the type of signaling technique used. This will help the flow of section 3. ==== Section 3 and 3.1 Could you format the bullet paragraphs better, please. ==== Section 3 Whether an inter-domain TE LSP is contiguous, nested or stitched is determined mostly by the signaling method supported by or configured on the intermediate nodes, usually the domain boundary nodes that the inter-domain TE LSP traverses through. It may also depend on certain s/traverses through/traverses/ ==== Section 3 inter-domain TE LSP traverses through. It may also depend on certain parameters signaled by the head-end node for the inter-domain TE LSP. s/may also depend/also depends/ s/parameters signaled by/parameters that may be signaled by/ ==== Section 3, second bullet. Is it possible that the policies or capabilities at the boundary node prohibit the support of the mechanism that is signaled? If yes, you should add a note describing rejection. If no, you should add "MUST use the mechanism requested in the signaling message" === Section 3, 4th and 7th bullets "Determine the next hop node" seems to be in conflict with "perform any path computation". I guess that when you say "determine the next hop node" you mean find the next sub-object in the ERO, or determine the destination or next boundary node. ==== Section 3.1 I would prefer you to say hierarchical LSP rather than FA-LSP. ==== Section 3.1 Please avoid using the word "appropriate". For example... then a PathErr with the appropriate error code should be sent back Please supply the actual error code that should be used. (Also use "SHOULD".) ==== Section 3.1 Should you also describe the case where there is no ERO? ==== Section 3.2 The propagation of Path Error upstream may be limited to within the domain or it may be sent all the way upstream to the head-end node of the inter-domain TE LSP. This sounds as though a domain boundary is allowed to silently swallow the PathErr message. I understand that you mean that a domain boundary may attempt re-routing, but that is not what you have said. ==== Section 3.2 Your discussion of crankback is limited to attempting to select another egress boundary node. This would certainly apply when a failure from a downstream domain is reported to the ingress boundary node of an upstream domain. However, you should also cover the case where the failure is within the domain and the ingress boundary node attempts to re-route within the domain. ==== Section 3.2 When a PathErr crosses a domain boundary it may be subject to policy and aggregation of information. I think you should describe this. ==== 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 you having to change your code too often.) ==== Section 4.1 (and section 9.1) Given that you have chosen to place you LSP Attributes bit in the optional (transparent) version of the object, you may want to consider how you will police its use. For example, what would happen if a domain boundary ignored this flag? The LSP Attributes draft suggests the use of the flag in the RRO in order to record whether it has been acted on (if not recorded, then not acted on and it is possible that nesting has been used). You might want to adopt this procedure, too. ==== Section 5.1 <-- AS-1 ---> <--- AS-2 ---> <-- AS-3 --> c Spurious letter "c" ==== Section 5.1 You figure shows R7 connected to the egress CE, but your example says... - A protected inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 in AS3 with following possible paths: ==== Section 5.1 Your example starts to talk about building a protected inter-AS LSP. But it transpires that you propose using FRR to provide protection for the resources used by a single unprotected LSP. I think you need to be careful with your terminology. ==== Section 5.1 - A protected inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 in AS3 with following possible paths: LSP hops: R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6 o p1 - a set of loose node hops crossing AS-2 R0-X1-ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R6 o p2 - a set of strict interface hops crossing AS-2 R0-X1-ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict) -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R6 You need to be careful. What do you mean by "LSP hops"? Is this the path of the LSP? In which case why are be bothering with the example? On the other hand, what are p1 and p2? Are they possible paths? In which case how can they have loose or strict hops? They must actually be explicit routes (i.e. EROs). So why have you chosen this set of two EROs when there are so many others possible? ==== Section 5.1 If you must use FRR in an example (although I can't see the value at all) you need to get the example right. B3 as quoted (ASBR1-ASBR2-ASBR3-ASBR6-ASBR7) is impossible on your topology. You probably mean ASBR1-ASBR2-ASBR3-ASBR6-R4-ASBR8-ASBR7 Similarly, B5 is not possible. You probably mean ASBR4-ASBR5-ASBR6-R4-ASBR8-ASBR10-ASBR9 ==== Section 5.2 Let us consider an inter-AS TE LSP setup from R0 to R6, with example paths p1, p2 each. Delete "each" ==== Section 5.2 What was the point of the discussion of the FRR bypass tunnels? They didn't feature in the example at all, and only served to add confusion. It would seem that you should move the discussion of FRR into section 6. ==== Section 6.1.3 For each protected inter-domain TE LSP traversing the boundary node to be protected, a NNHOP backup must be selected by the PLR. This requires the PLR to setup a bypass tunnel terminating at the NNHOP. Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be achieved by analyzing the content of the RRO object received in the RSVP Resv message of both the bypass tunnel and the protected TE LSP(s) (see [NODE-ID]). You need to be clear (as you are for tunneled and stitched cases) that for inter-domain LSPs the RRO may well be masked. That is, in your example, the RRO reaching the PLR ASBR1 will only contain hops ASBR4 and ASBR7 (R3 having been masked as confidential). The AS number may have been inserted. So your tunnel B2 will not do the job and B3 will be needed (even though B2 is functional, you can't use it because you don't know whether it is functional). Further, as you pointed out earlier in the document, local policy may prevent the setup of TE LSPs that terminate within the domain. So B2 might not exist. Same comments do not apply to the use of B4 because it starts within the upstream domain. ==== Section 6.2 This section looks to be a bit pointless. What are you trying to say? Certainly you have not covered the need for disjoint paths (which is out of scope) but doesn't just work without some effort. You also haven't mentioned segment protection that applies signaling control to the positioning of one-to-one protection tunnels. ==== Section 7 The above mechanisms SHOULD be used for a contiguous inter-domain TE LSP to allow the head-end node of the inter-domain TE LSP to initiate make-before-break procedures. You may want to relax this "SHOULD" in the light of [LOOSE-REOPT] being informational, and describe the alternative procedures for reoptimization of contiguous LSPs. ==== Notify messages. You haven't described how Notify messages may be handled with respect to domain boundaries. ==== Section 11.2 I don't think you need to reference RSVP-UNNUM or BUNDLING. From owner-ccamp@ops.ietf.org Fri Aug 26 19:46:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ntz-0000rA-6E for ccamp-archive@megatron.ietf.org; Fri, 26 Aug 2005 19:46: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 TAA01670 for ; Fri, 26 Aug 2005 19:46:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8nuj-0004D0-Rz for ccamp-archive@ietf.org; Fri, 26 Aug 2005 19:47:18 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8no7-000CZ9-Er for ccamp-data@psg.com; Fri, 26 Aug 2005 23:40:23 +0000 Received: from [213.46.243.15] (helo=amsfep17-int.chello.nl) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8no4-000CYQ-Sw for ccamp@ops.ietf.org; Fri, 26 Aug 2005 23:40:21 +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 <20050826175831.NHHF1863.amsfep12-int.chello.nl@[192.168.1.2]> for ; Fri, 26 Aug 2005 19:58:31 +0200 Message-ID: <430F573F.6020308@chello.nl> Date: Fri, 26 Aug 2005 19:54:07 +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: ccamp Subject: Re: Final draft of response to the OIF 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=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: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Hello Ben, You wrote: > I proposed a simple (and I think technically sound) solution to > item #1 and saw no objections, however the answer has not changed. > > I do not understand the reason for different encodings for > VC-4 and STS-3c SPE. I think they should be the same, unless > there is a technical need to distinguish them. If there is agreement that they should be the same, we should also look at higher order contiguous concatenated signals: i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c STS-768c == VC-4-256c > I also do not understand the RCC=1 NCC=1 encoding, since the rule > contained in the current RFC actually makes more sense. However indicating the number of signals concatenated in NCC makes your first objective impossible: STS-3Xc == VC-4-Xc so there will always be a difference of a factor 3 between STS and VC-4 encoding > If there is > only > one signal element, there is no contiguous concatenation, by definition. In fact a single signal is always contiguous concatenated ;-) > So I fail to see the usefulness of these encodings. NCC = 1 would normally not occur, so it could be used for this specific case of SONET signals transported in an SDH world, or SDH signals transported in SONET land. And if these signals would not cross borders the value NCC > 1 can be used. > Regards, > Ben Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From hensley@yahoo.com Sun Aug 28 05:15:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9JGG-0006Wi-7i for ccamp-archive@megatron.ietf.org; Sun, 28 Aug 2005 05:15: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 FAA06191 for ; Sun, 28 Aug 2005 05:15:29 -0400 (EDT) From: hensley@yahoo.com Message-Id: <200508280915.FAA06191@ietf.org> Received: from donpac-dialup.ttn.ru ([217.106.91.40] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E9JGs-0005vd-UL for ccamp-archive@ietf.org; Sun, 28 Aug 2005 05:16:41 -0400 X-AntiVirus: Checked by Dr.Web [version: 4.32, engine: 4.32, virus records: 66606, updated: 1.03.2005] Date: Âñ, 28 àâã 2005 13:16:56 +0100 Return-path: From: "Gysi" To: Subject: Penis enlargement breakthrough! Message-ID: <000801c5ab20$ac4dcc10$0700a8c0@wkuhddwi> MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0004_01C5AB42.305894B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C5AB42.305894B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0005_01C5AB42.305894B0" ------=_NextPart_001_0005_01C5AB42.305894B0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
 
Penis Enlargement = Pills=20 !!!
 
3D""=20
 
 
------=_NextPart_001_0005_01C5AB42.305894B0-- ------=_NextPart_000_0004_01C5AB42.305894B0 Content-Type: image/jpeg; name="penis.jpg" Content-Transfer-Encoding: base64 Content-ID: <000301c5ab20$a94483b0$0700a8c0@sanya> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAqoAAAYbgAAQxf/2wCEABALCwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8eFxoaGhoX Hh4jJSclIx4vLzMzLy9AQEBAQEBAQEBAQEBAQEABEQ8PERMRFRISFRQRFBEUGhQWFhQaJhoaHBoa JjAjHh4eHiMwKy4nJycuKzU1MDA1NUBAP0BAQEBAQEBAQEBAQP/CABEIAOkBdgMBIgACEQEDEQH/ xADcAAACAwEBAQAAAAAAAAAAAAAABAEDBQIGBwEBAAMBAQAAAAAAAAAAAAAAAAECAwQFEAACAgIC AQIGAgICAwEAAAABAgMEAAUREgYhExAgMDEUFUEyIhZCI0AzJDQRAAIBAgQEAwMGCQcLAgcAAAEC AwARITESBEFRIhNhcTKBkRQQodFCIzQgMLHBUjOT0wVicoKS0iSU8OGissJDU2Nzw+NAg/GzRGR0 FTUSAAIBAwEHAwMDAwUAAAAAAAABESExAkEQMFFhcYGRobES4SIy8MFSIGLSQNHxQnL/2gAMAwEA AhEDEQAAAPoAAABEwC7CNLTVFfJt21lv9ON0xOkExMSBBMATAERPInXcjEKr2cY6oXVt8/QxsZUd fHs098YbMkcIcvoU68dQwbLRtGOGwee0TQMTo2THDYAAAImAQfSyvUk0rwdPParXTnp9Zej1c9sR MWJ5ETAAHEulrKqzVTbUjNrYqpNK+itW69rfFLss43pZqoXWZWOXGu3Dy2htloyKd0MB3SDENsMg 1wmJgoMzJPUHlqT2lPn9OJ7qVjzOmllNCN93muezi0GfPxtTe4wqKX26MevPTThO3LVthCZrqU5r XRhCTkaYJTXbz9XnrOGOffZ9F57YvnaVWxFryL3Vl1MTtmAAAAAAAQAUWHZVaFF9MSsu/n8G8JP8 8e3Vs8+jz03dcWjNynqeXqy+bKLRZzRKOmqe4nT7yNeLWdrsd/nK1FuWyBQ3z9TWt5zYnPUuybZz b1PM2b19JPmuejL055HbNMiQAAA89m+yDxOn6MPHR7IPH7OvTE5im6jz6Ixo8+dqp21V1UuytTF3 aKO0hS2Yg6cvVnF3Sc01a5qm3X1arHNLN6Us8V3oo+k1S920mwrbdHXGztnB1u6rPak93Nffn8mr KVZomUGqJg4AAARMBTdTE8qtqY6V98XcOhEzMKZmx5/WfR8k9OaSW0nx7oovpV14ZqIm9HktDuU3 M1jLHrUmnWqWaYavyorLPGMYWmp6Xvjzr2n32c2FxtSZtO52eet0mBAvB8AAAiYCm6mJhJ3Oy07U za8buwp3J9Gnqs6LOVNo3Uqr4Ya7VHJ3Raq1rjXfHRRh2W3oafS9q2aFd+ct9Uzz0tTvz7XtYrO/ FZrnjoxOqOR2y3LJtruHTfCQAIzDUjywepoxtGJ6w9HH59q+Ipw2ur17a2w7HM6JruX6vS845vXV zWc7LRqxVuttTGZSmqWxlaWkXccWZS8wjflVyUuKVsoW6123G86r0+HePIRpT2HPkXjd5wKT1XXi mj1R5QPWJN+TPRJ5Cp6R3ynohooqrOcj2vy9FTiWhhu3dzXWuhX0Z0wEvQ52l0etOu1qGqe627sV VidnO1UorlP11aQxpZbGU6NyMVxfz6OLaXOZ+ltXTuy0vR4/R8+LtmPYizIU3hBIQSFeB6IPPc+j Dz9fpA83qvq1ny1d1PH1cPKP5au12RSt8dGNZ896Dz+jYuxlLTtq5N0X0ncW+aaObPETX3Fk3YvR 5mmhQtFZY6Xcsfczp9Dk0LMtbSm+eRemNuPHMHrzy1B7CfJeqLCAkAAAiYBVpKs+fXtT4+q3QyNP LTU57XjO9fO4i23i9qScYSui/a1sVutDMJ57o4HLEukOCoO9q6+2NrSZ28rcplobuzlJjePMxMen PJ3npTzbBuBIAGNVdYKsz2IdDBS3XVW2Uwiz5/bjbGFsJ0lb12cusTaPM9P4ldNDRznoFvTNCvV8 WrzVfWV8dURermWa21rZn0+Dk6LRzJJFN9kxlMaHExnRqgh06BMSABCbgeJc9UHkKfZ9Hlth+us+ Z73fN8nTmadGzE2Z+qlQ11lNxbPydnLu7do1Ki1y/bHLnTm8ZZp1QzKtSvn2xWmmKzEvno8iEvAg PyIZHprZjylXsiY856MkAAAAAImDzXHSJTqrrh6Xyvs4lOjTS59ereLYmih+kwYerw2UydamLGtV ra5KXMWdGCcOloRh7ms5/OjxS6Hb3QuNTtmnLQKjYKLalMxl9vdzGR29aXsU3EgAAESEc9hBIVc3 UxIvfXleu7i6sxPHe1K8vYMNcNp8peJk3wJmLCYmYiJKzBIQdRMEABMkEhF1N0xITaIJCJAAAAP/ 2gAIAQIAAQUA+MjBR7vrGey/N6ZY5Kohxo+Q3HCv/kPozD/rBPNZ/TOPkPwP3Y8D3zhbkhyMRuw+ gRyJRwyngrMOA6nHlQY05wTPgsHlJFbCvIlHAxSOX9MgP+H0Dl1MDesQRoxH1BUK3Zc9MPrn9TG/ ZZfUDnjocctzX5+icsf0YlcryMcc85MgK+mc8Z35z+EkZckbAQF9eZTy1IcH6Byb+jp2f14V+c4y dAmcHG5BQcgBhnLE+vZ7BBEkhyqSW+gcm9VAAwsBjqpAdsl6uoH+RC4rNnJxGILORnL4nbKwPX6B xzyzMeW54DYHIzsucLyU9VBJA4xgcYMc9tsCEZEhRPoN9vUKx9HcnOQhRuUJ4wN6c8YeVZP8sZDn tOcETDIYCzj6L/15/wATxwR6k9jCDyycnrwOGwKcA4x17DpiQs2RxhFH0X/ryOP+RHqIlxEKtIjZ w2dTnU51OdDkMBYqiqMH0X/q3Azjkj1IQdF9Q/OBWOEPhDnCSM5wDgc/AfRbJowMVMf0diwAbhWP ORqRnAxjxj+mIeWzn4D6JywB7a40RIH2+2RpiAAFRnUYyqcWJAfTPTPTB9E5Lx0Tj4Tezi+zz6cD j4HjBxnpz8R83//aAAgBAwABBQD4qOcC+jDhvmPPFbhWkdcWQcjOP8T9GP8Asv3sIeeeRnOc/Ek8 D7KOSYVwLxnUcsOD9AHgqTh4dGjIPDDEidsWEYYUxoBw8ZUdiGiPJ4Jx+efXJPv9AZEfRSQXLdi3 OBiV6tnBHw45ySPq8IIPHq7DnJft9AZH9wMYcYo4yJyCCDnUnPbw+hkjVjEvGcEsQCP5nH/X9Bcj /sT8APTnI5PTnkLxwx4JKnAFGHjqVXOgJsBQv0Bkf3/kKTiEhimICD90Xk4wXOBjKCCPUgZGoJsE dvoDAOAijjsudQcaMHArYC4HcgegznnAQAWzsCQVAkbs30B9x6sB6hF4wNi8NhUkmPkJwQ/phdCC 4JTgZNKOp+iv345bk4PQfwPXAOTxIMb3DgJGFvgCBjyhQzlifor9+Dz/AB/x68ZwAFdSAwGe4udl OcrnOSShcLEnD9FfupJH2Bzse3pyOMYgZyDgK4OMPAB+/HwP0RkUnONJgPoACeP8uPRs5weuLj/1 4zj4H6IyI8Mx9Q4wfcZI3o3OcnPXOzYXbj1z1z1w/RGJzy33yL3cf3ePk9cHPyH5v//aAAgBAQAB BQD539GJIw/5FJlEvx/jBn8+nw++emE4epEsZilmdJlnZlS1J7Ly29iM1dsWLsUk1N4bCzL3PWBm Wd2GVZAVxP6/+BNMUmfs0Pu9MlYda83dBnPx++cZ9sIOcc5wPhI3VWVpEIJWYcze1HYjk1O4levR XUDr2EEn4sishhcBgSWEAKvxkm7owWk8t1orDySmp/2bWmY+S6wZa8rr16trb1aklnyalGP9l1yt H5Jr5a3zfxa6rOHDliSsTd8pTmF0cOBx8P45Oc565ycJPwYhVkHONJxkwIaYtHO5hGe7C2WUKoJL pVXSYa6KWVfwrAFepLIv4c64tK2RNoK9m1Z8Pk9qbxmnMsPj9SCVfFaSRzeK0JcuaeG3M/jFCSV/ GaTmPx+pHB89xeUZeWlUJIGMEs8PfK9tkZJAw7Z98JOc+vxZ1IkYDG/o465YBVLyEpFKrosokm6/ l7GSxrap/F1+xTUmWpt1VciT/wCkDmSFu0a/14Hw4GcfDgZwM4GcD4zXK8EqXK8k9i5BWw3K4s91 ImT3FRi2WYHljnLca+TvHaqL2hsvCYrqPgfkO5GSW4YlfbQ423scNtbjn8y7ymwvQldpA+Axu1r/ ANcnHaeMxNUKe5WcQqzs7QWHgacI8DjtiIUmU8PUXqif0+nvtZYuzt43tBB/re1a2PFdv7dLxyzH amrbcySVNtE4i2hyzS2QHt7BGg/Zzo1PZODrdjwtbeLktfZ4te/2syXo4xdWFV2VMt+ZXZAqdkTi McxOtxbETHkn0yZBXsRqhsOrxyRwmNdcO+tpyvPSfstk9fyIm4sL/X6nAzgZwM4GEf5W05RiqBer rZpuhpVyFkRowOTinjLalJ71+WCRdfs5UbW3VI11rrJr7xHe7XWptbUSQ36thHgkUQSiVOcuMPe5 k/Y7ZoLVtKYVNVZWUUCIa/cGfgDJX6W0/r9LnFt12RXEiRTwzZ/OH+x9cUenHBkIWWJihDs78Mpm assd2wJZCLfssskrCtMc9uaM92jKX5kIs1py8cytTngtQxj25/Tm6e1kuEWmhJknEba610vVbxXE 2Xa3+1k5u7U95PJp43/2e0q1/IrySf7nP7Wr2U1x/l8slsRwPR8oVIdPvopdVU20N6vqd3BcTWeQ tHJrvJC0i70y9PIMcbxJ/b3hYDec8bzrR99EPpl6z7kkOuhjqOjK1qs0oZ4XUyRRiUQzk1JM/FlG RLZGV3MU2wnSGeSdy6N2Z68v4dWQMsqIkWqjfmElI6RLx+vO2cKatWq0H6rWe0+voyAarWBI4IYm +UqpzgZwM4GcDOBgAxgOfTLSd5owjIVQlR2aRDHN6ZRbm/wCdl7ccMdebtY18UmeqkhSTFWVZXr8 Kjsl9HrQxRS7OzflWOXXqtiW5tXmNWogm2CyrFWMYjH/AFRRRezEQSNpw9qttaESnf6gAb3WOIfI NZI03kWtjL7Sithd3q2jbfa9WHkOtM42dM1fnb+xHpOR+TDxiDAOiyIGUSiJqLql7k4yB1s1+8QZ g01aGwmwrLVrQ043SOusD219qC9zctO1avF+HLem21b8GpVrB2SqpFimjtHr6/P4Ncn9bDyddX4l qRPIvjwmtDwxBUk8bRxF4lHG0Xh4Sa343DZ2aeKotM+JA5N4y07LqQus+dvvk/rZjUM4/wASSeT6 5NB7qP7lO6rq6qScZQVMSWYplkglvTyT0oGlaHpKcsVIga9hqsiVrOys39iKYlnnmypECzqscWtr ixYhSKQL1VW68WHENeNPSOaKNYbtWZfyIDn7Oj+QuxpvZa5UVBLGxG2oG2bEAxNtQki+dvuMsP1c GKrBNuIVb9tK4XYzdxsZuu0lWazBJNElS7DYYehjm6mRy0U3/wCWOwIqxm6AwTyNXrsE2U1ikvty ZFRlZqtGaKaaO3YspSnhjjp2s/DsdvxbXN+OxzUpzyy2fH7H7Gh4zs2gTxm7HXreK7KKCPxa6lOD xyzDY8Z1Vmvi+H3w8fjGxD19D7VP52++TSr2msvdmkkgporW3VpbcYF6ucb8c5r5jHCvIngMU4Zw ctf4PIVStUitsFhWJhWuyTyDYV1lkvW5xWts8dbYiFzsjZhjvxqBuUdF3QwfvWLPu0SQ7d818W5L 7bebOjcbfbZa8/ke1hi/e7WnBHu9vBE222K6Fd9ed18i3Mqrttha3PA+g3PNiQrFsZO5LJVhgQQh 9pPO35+zjJ2taTHq1J4xcmrzVdrVV7c8diVZ7CmGSK9BfrtWhidAldVkePrFHuWeOhWjPFGj7yWJ izR1IoTWgV8rxsVTjkDk3JPckYAtrY+kIp1jY6Ic6rhRDhCDLFaCzFVpVakQCEdV57D5NztJddGv l1iQ2PK5w1XyKWS5JsaMbX5+SgDyp/32VD7CetSeSA0JSJaA5k1TII5Jacc1ulddqtYj8a0Atynr 6rSNPNUepxVl2rxtJs+uxa7ZqQSWDktu7HBFNaihhGxdmtXpD+Tss9/ZFpdhsI1Fi8MSa+zJb2qJ av7ZdlFf8olrz7XySMPs9+YqSbO+1ebcQbbbbjYw7Wnc31VTc8giWtHaGi54z9vrQh2uvBvHR7ZH seOkHXa98TXUEmZUBtysTI4Su/MOtqQAE7SeV4bkhfgnGrxMNlR9qV6lWWuulUqulZcr60qUqwoz QRFluyQ2+6iw8rwTND+NLMFZfd9ycOUhrxCMAAFnREkcu4PJowh5cX+vAySKKVAABwPg1Km1jgZw PhIqvHHX1oppQ11KhXqUDUTU652j3mqaEbnXEWtrr0F/YUi1t4fw7nJnnYpFXVa9Yp3Ak7Z2LLto jLWrKs9evQnFeazcgK7CIhbtSMPsYwqmaeS3CURmWxFNyKSTWA4FlDC9w41u3hu2VEt63Mxs2cWa 3zXt3IY/2N3NptdnBeXa+TjXW93ujDRlmmqfNIgdJPGpZKK+JwZX8V9lT4tE2DxVjXbxLvlmrW9q 3HETeAJiQybOSMvYsHqFA9pgO3YFgVYL2r3agBjd4gWo6+wW0NbqukroYatSorKLKzT1y1kcVooL BWCZERJIlE1ruSSxbEjJynVZfhxigdeFzheIp4ZiLddps5+XgfDgZwM4Hwsge1b4Mc4b8qivFyNO 1ydD269nI5yPgL7Y5uCYTibbV4Pw9hLjpsomj2W4RF22zbF2V58e1dbDZ2zBYtoZOm04I2ZzpslA GzGH9ripsyYae6Yezvs9vf57e/y7U3Ul9aPkXCU9sfH4dJu4o30m2hjr6zdizDqt8YZqG96Rhgn0 LA7RXFCl/W9E3XYVyVtSAM0ZLTz2IK6jY0wYrMMqWz/9FzkQ8AY47Y1ZGwwzJnuNyknGe4CFkHPu YJOc5JPtgmFGlaCkkZPwODFA6/DgZwM4GcDOAPpXZDFXtlrSi201us/W/DJxac8M1gVq5vQVGG4s rJHNFZyztKk8sl/XtXOwoYdhr8/M1pH5mv5exrmUya8FrtJMXYanBsdUMO11YwbigchuUJXj2eni T9vqeP2+qz9xqc/carP2+qy95NHUtS+Wt2l8kuES+WW2WTzBeZfKJPxqnkXvbT4z+R1YLcXldSaJ fJYC1fe1rFA+S+5bj8qqSlPJ6ckuzPWrUjPtBI0eqzSWZUb2JJTNDviWajqkQy0l4u1nqS2WCTwy SDXxuZE5IwRNwBIoSVlzupLJEc/GibGoVmEkVOHI27vWrpFD0XOqZ1TOqYUTOiZY1dC29fxrVwyH R6tpJPH9YTT8foV4m02taOPVa+O18V8fqtfTQa1FXSasldNSip0PGa9eSDRamu3+v6otf1kHt06U aS3wVqxqyQWh7qQ9mqbDq+1gIAmIJvRdgwaKKoAIqih6yIQwT0IHPX16chq6MJKIcNrCQ9SrBlNQ 4HHHHycn4KQBhZQeBnHw4+TgZtUlk1qR7nW1bMm+WnPY8hSOBdzFJVbdpNK98vsonp2Gk9xIomyf 20mZAkW0DpbiP+DkBZ5r7CxLOX1s1pW1s+xEQk2YPv7Uj3dpgk2+e7txhm2+PZ2uPPt2DLd7VX2Y Hvbs5727Oe9uznvbvDNu+fyN3nv7vNou9h2Rsb0Uem0E2os7d9n8/Azgc8DCwHwJAxvvPVr2Y54T Tnj1u6azrtf+OJwGi2UDTUad7hJbHaNyTllO0muZIa+pgYVwuKg6iNc4UYV5LxkYRkqtx7PrAhIH Gc8AAYAM45z1OcDFA65wPpb/AGG6rTWLW/Slsa28sRCTefny2d7csSWLTN+HJMZIEitJx2UAqwJy Nur26MlKRXVsmljrx92Z3eKvTrXdVBDHtNX2/carP2+p4/barP2+rx9rqiP2WsI/Y6zn9hrci2Ws D/t9Vn7jU5+41WDcaoZ+41OfuNTn7jU5L5HDHfXyr3K0/krxOPKngpL5UzWKNtLtT5t/Nu47sF3f TWK37mVUfyGUX9luq8a8lPTLnpZjB+HXLdKOzE1k1XngoyGzq1fAkdZ9TrHz2yFSNQQiHOqYUQ50 Tj2wMIQYU7ERdQkYA6Lx0TOinOq51XAq50XH1WvmspodUmHUUDZl8d1MyDTa1XrV4q0PzcYkccY4 GcDJa1eZm++WUU5GicKo4+EsUMyzaBOx0lpsraatAQnA6jAAM+2ff48Z1zrgAzjABh5Jz1zjOPgv 9fhwPrN98s/+sfYfb+M/4/y39R9jhwY2L8f4/nBn/JcTP+fx/lf6/R//2gAIAQICBj8A2y9ie4aX ElnAXET87pxpU+6vsPB7jrXZeRNDXOLdhNaqdzA8Xlio9xZLJCWTRcuilSqZ/kRYR0nZE8vJTjBH 8ZW6WfkoJReZH8XA8m9tRNeBMyHQ50frHsQlJl213Vk668xTjjXkJ5JYrOiElqSqQV8loeyvQWHM g5kcHHglSZKZot0v/SP7Vw6kfxt1EsqZYv0OpP8A1ZDhlGTJOvAirEp6jhkSzKeC3SXMlIqSrk3U SRUSZUcNckROLK/GtimWPU/PEn5YDbacvTdPgiPJPualChSo3wPqSfU0XQ08kL4ix5bquv7jf8si tdBpN2J4ENkWIVZ0GlxF1Kx5PqW9SWlCvun0J5r2MVy9yOI2ZJ2f/H7jyeS8lMse5fBdCPlj5L4+ Srx8kJ4ruUeJ8Vun0GuH+xi/7R9S1SicfWSPiz8ci2RZln4LMrKSIxUbt9BNai6wJPifJvsKuq8M mdEyjFsqvUuJcN7MxL/Uk8HInpNR4stjdELFOiHRFViUSJaTI+OO+fLZKUyQ/qcEfNzLJrs1NSUn vsptt++J5XNe523/AP/aAAgBAwIGPwDbTY1uFOo1izkMa3SHAsluI4UGtC3xGmMjcySkRBaGW8Ex Q+5wUaP8djfM6x77EV4HXdQ9Cg2VqJJVHqSyg09dRruYr9XOB3/Y7GL3XYuyg29CuooiujJmUVI5 N+DLLRIbg5C5w/IzDvuux12OOD9ChBKmmxqLr4kJW1NBtLoKgqKpjG6bK7J0GrNONjgoJQ5u2WyQ 2poiqypoWyJ+LoQtN0uLJfbmNTbgaMrRlV4HNBaIvIlxKnUhbG90nw/YS/jj7kRsqpPtaJhk5Uiz E+KqPWlC9EXJ1ITq90hrk/czfM9dj6FmuxOPyPuWTPxyj2PxZ+ORTF9y2RL3SJ/VzNcMmLmalHdR 3LlMkVa8lGi5dEJpslvdohj6SU0T9Sha+PqPlkyyLI4H5ehNyd7bSpHKCgmhVdhttr7i7Lsuy7Py e+6rZDJXlWKXPji7e/8ARdESt8tv2THOxWO3+g//2gAIAQEBBj8A/DNudXB4+Xvq179VKmFmBNz5 1zq9c/lx+TD5OXym/HOtKmx9SPbK3CmK9NhZ+V6OgkG1/dUJHV0dKcCxJxwrWHU/yQtLGyhS6usi jIi1KikuiZqAA4A5c6MsZXUR1EnhXTa1vWxsvs508chYl7PH0kKByBNAjljwB8CKZf0Tx5H5B5f+ hYD0qNR5nGixwYi9vLGr8DjSyIMEYg+RoN5C/sq3D8DlWP4POjiCTew8qZierh4URgAWsVHBgON6 ZG/RAUEcaVLhZ4iVXUekryNdMV8AdSsLY0Ztywk3ZuERSbC/MigzC7WzNWGMUmBBt03/ADGhMpUh R6ySbEUJFwZbXGdxyxoEDUc75+dqV81a6knDEfINkxYzAqrhVLKpf06iMr0s8xIBGpjGruijWY1J bSMyOVBJjaVmYBIwznSj9vUekcaeFTKzxu0fTGxDSJiyDDMCo2V2ZJFVjIFYookOldZ+rcjjTSGM ybgB2EKajZUft6mYqNOI5VFHLrMky6wiKzkLgCx0jAC+dTLFqeaNZGRWBRZDD+sVHIxtTI5YNGGE hClkDovcdA4FiQKm3SmTRAiyuCjBu2/pcC2K/iEcj1XU+VWHI/PSscRbSQOFTQi1yA3DGijggHEA 539talOBzFCrfJasav8AN8nL5L3sOJrW9wBfEZ0AMTwxNDSMZBnxDDKhn1iw8xV3sGBwIvf5qujM 2NsBf+sWoO7PGzN0qpGtscPUCKv35b8MUt/8qikm53EZGBBMXzER00R3swsbWtFYi+BxjNaz/EJl XE2+xGf/ALVApvtxoBKg2i/dUwO+nBjNx+qy5/qqBH8Q3GIvlD+6qLdzzTNJHpNiVsWT63p6b8dN hS7PZzlNsyqjs569Kyd7LTjicMvbSq8sulWd2UEEMXbWcCptYnAjGu6jSau++5xIPXKuhhllakiW WYRKEV0utpBG5kXV03zPC1WEs0bFXjd1K3dJH7pVrqR6uVRzmWWKSJdF4m0akuG0sfNeFO7vKQRL 20uNMZ3H6wrhfHxvUv2koSYuxjBFhJInaZx03vp9lSwK8mibbptXuRfQgKhhhnj+ILfosDSFRkdJ UcudFM1N2PhSO3VzvWtBgcVNaXBDG/lnVwcbXArCsavVqzrGr10m+PCscSR50QwxJyPjxpWxLE+V 6VsLqdXPIUzxnrU6gOYtQewvxB51a3St8sqKAXVLKmrDhixoiYDViBqvqOOYC5Uz7V9LKDdHy9t8 qO1dmUSjSt+YxwvWpyWbM48eRNTFGYxkKdF+kHjagFyZGBvypMeAFDy/GRQyyBZJyREp+tpFzUu3 SQGWEKZV/R1jp99J35AncZY1v9ZmNlAobXuDvlS+i+OkGxNDHPLEU6c70ptjYg+YoP8AWTEHnQuM GwJ5EGvh3JDLil+I5VrQaWAOHA+VBZL3GRtwoC46rZf56uMqAvYnEY0S7BRmbkC3hR7UbyAYFgtl /rHCiywqoGVyW+ZL1pEwWwN9Mf03oFZ8bEnBR+WruqyA5A9BPkaA3CNt2JsGtdT7aEkbhwPSym49 9G50kD33o+QHzUZEH2RN3C5qbZ+VNZrgnhW8nOLRDEW4tRdiSzYknHOlePAqcRj1A8xW138Q69u6 Fif0W4HyoW+sAy8qAJwIN87kqf8APS3bqvoYeBJpkJuVY28qHl+M2c8UMc6bcyF4ZTpDa10rwbjU kYaN2dIEcazdu2HDYsrDDULXBqGaYpNp+FPedyWiMAtIq3BvqOPCpow0aTPC8R3Ac65i0qy3fpvi otxrYvOqmDbvM7xO/cALqunSAir6he1qZo98iRkkqhhB0jlfXRX45LHruIB7R66Vfj0scQvw4w/0 6JO8VlY2NoBgf69KU3YwxDdkYEf0q1nfIGGBUwC/+vRvvktx/u6/26Onegty+HXl/PrSu6YWzU7c W/1zV9xvlQ8SYFuL+Tmhp3gdgMGaBffi1dybdhodQUuIAxUnn14UJG3Y3QawREQRkfyjiaVdZCvn IQQl/bRmEirFiq3N7kZ4VjbHFlGFgRhlRswdbegm3z5UHhbtsvqj4EZ5ZEUUZQko9QBwNj9Wjx+Q OqkrINIA4EGt3DcfbrGTf+V03oxuLOt1IPhRmkPWFOlOX840Ymw1wOx8SDcGtu69OqPFseHC1Qlb PqurE3uFONxqNBbXNy1/yUyHiAR+Sh5fj8vkJ4m9CS1yhv8A0TnV2wXAH20zWvE+DAc61INStjb6 auRcHPUBetIHSThfOi2iWMj69r/TQ6ifM86KtciwItfiKWPbKGdl6hYsxubWtX6iRQ2LEnSp/osR QLhADgbyIpIHtrSe265j7ROk+81jty4/SSxHuWnBaRNYCtcEGy+eNaZkE8ekhScDq8WpYnB7oHpA ICk8jQZfWvoY/WA4edBsm+sPH5IVPiffXSLGSAKB43q0I0lLpLLbBnBr7eYOCLBF+mkiYW7R0kfp IcBTRH/cuR89RgA6gGJJFsKv9bK/hULcGBX5qHl+MkkWVCkJKysGBCFfUG5WoOhDK2IINwR504ik WTtsUfSQdLDNTbiPlPnVuedPGVuUbTlw4GrLkw6l8qRTchibAciONH9HLxqRwRpXBRnkc6uz6SBl zppJHC2sNZwueFAkSXYALt0wkfxkf6i/PRMOna4dKRLdjbPVI2N6KyFpG43ZiRceNEaFtcjUcT5V 1IbY4cKs2qMm3pa3zVpEhZAPrdQ/qtRWWAK36cV1b3GhuNpKZFXhazLbmpo2Lm2LBrAhq/kyDL+U K8KjXDpU6j+j5Vut0ucUYAPJlFzb2mrv1Bhf89aBDNIBbFFBHztTMu13BW2KqgJxPi1Ssdju21uS bItuX6dGRNlugEXSFCKBjz66P9w3duWhf7dQH4LdAq4JvGMR/Xrf221of4fHG7B2IkYyrqVdIBtY 50kcm2RZ3dhdpAsYVU7pLHEqfA1Kdwkckb7xNvFob0Iya7+nGviBtV7ap3ZR3DqC95oOnpxyrcQ7 iJYpts4RtDFlOpQ4sSBwP4WxWAy/abuNHWFijuhDXW4Zc/OjoMzB4GiVRKNUcnd1ozanH1MLgmt7 2EkiM0m5kLCUBJBIpEVl1+rVxsKjbcibQEGt2lBj09tF0aOq7a744eZrdtt0kgebc7iVJe4OyUdC I7oGbHVY+moFJ3CL3Nv8QGnuxCh++wIkPSbjAe6oQ0k/ZVZFVUlAdX7t0LsWxBSw+t5Uwjk2wS/R qRy1vEhgL1+s2n9ST+1RJk2upyAxCSez61au5tNYFvRJz/nUTr2o080k+bqq/c2mPJJB/tU6bhoj Irf7oMBbx1Emg5vY2F6LKmso3bgQ8ZOLHyoxOdcsp+1c5sTxv4UEk1dF+23EkUdxEPtAPtEbAsfp rU11tcWvx41dXDNgbC/PjR6eViKJuAgyuaBUgm3DhV26SPRc9V6RtAUzsVYW6dS+HjUTlyAxwsLl T5caWSHuAZnXYBrcAuNPO4GB/wArCpobY9ks1stbkG3DhSgjEXx41ck6+I+mm3Dr+scBLYkhTj89 FQRizNc+dSOxu2ojVzA51YC1uI51GSb4Eiu4YkLbhFEzFReQAWGvnXY+Ei7WrX29C6dVrarWzqQS beNhLp7l1B1afTq52rtjaRBNOjToW2m+q2WV8ado0VGkN3IABYgWx/CxA+XL8A+fyMnEqDeg+RIz 8qOoYjjzvWm+C4k+IrWDeNz1jlfjWJuL3xxqEyEYCSTH9Ik0Bw4VdgdTN0ED0sT6sKb41iJPqDIM KaVIjHuQdRGYa9dsoY5FsSrYWv8Alrqy4nnXcEYGAC4/ParKrXyw6rgDlnTSIuhRmXzP81c6ggPV KArSMeDsdXzZUJcoISFux9TDlQ7vRGtlW3C/GgqW+Hj6mlyDMOV+FNBsm7cLm0kpHU5HLlRIcgcQ c6BEo0JfNswOQ50kkQARIlEYGeth/kaER1dwrbAYajnicKWMHC2LeNEWtY586CEagiYedQbV51Wc qo0Hmw6b8r1Ix3SaYhdzfIBtFxz6sKtHuFZjq0rkSVF9ONsajiadUnlCkRkgkFxqVdQwxqII5lMs 6beyZhpL6WOq3SbZ022adVmRlV14gsC6j2qDTyruFKR2DZ3Or02GZvwtnX61e0Yu93dQtYNotp9W eGVaBJePsifvjFLM3bC89Vxyo7wTKYFOkvyN9Om2d78PxB86tQHHSPy1JGbEKwCnlfGlBFzzqw/y xoh8jhhXbkYcLNzB/PSB8w8kItjjqJw99Z2AHvpkbFTgfpoLKcB6GGaWyamjnwkAurf8S3K9ESDU bWVgbEYcD4UkkUj9xSoOqxDK2HCtUiCR3xJLMtr30jSPKjp0xlum6Xvf201/049Oo9R6hXY+s73b mqjOjt0TBekE4WNvVzvQSMyvCGAeTuOfO2pqjjhMiLMSAO9LdVGYtqtjXSzhVGPW4/2qxMlz/wA2 T+1QRO5qayqO45z82qGMPNZOqT7aUYAWW3VzrUWmIBxAnlxY+n69E6pyBw+Im/t1qLThb/8AHm/e U7XlFzZT3pSbDzeoN6s7RhVjLKBaRtItYyAjUDx1XqbaLOBG40owiXWB3e71Pe7cuVEd+2rc/FX0 jinb01q+IJOvbP6R/wDSro5/WpJG3RftzxzglAGbtF2Adr4nrzqTfGYosqgTQqPW4VolfUcrK1NB 3Y7kIqMIVGEeHUfUWPMMPChq3bMyw9kMRc6hIJ1OJvYEZcuNdybddyTtRoS0Y0l45DLqKrYWN7W+ en2YaO7v3GPZXt3DB7drlhzv4/iD5n5M8NIFvbUpt9bG3O1W9t+XhRtY2yFW9pPjXJsweVEPmkvc 1NxVhifmq4y48atzxJFG9gQLqaEcoWVb25FT4HhRSGbVFGOoyjV1H6qleVTBghCFTeO/FhbBhSuh VegEkg545VjMbG46BjbzxoSF3Y6gFDMSS/IeRp2WPuSN+se5LYDAAUDP9jAMWPFv5K18FsAE0YM4 x0/yV5nxoCeVpNJw1G4F+VAAEAgleGI50rh8frLY3H9LKhM1wkZ6TnZuZ8qa4PXmcrKMqGkcgByF EZhsaZjYNz5k8KVfU/01HE7qJNIshOJ8hSsj2Ml9CtdWOm4PS2PCh9opx05/WHCjtxMvcVO6f0dG rTfVlmKfbLMpmjUSSLcdKHImhI0yBDfSxYWNs8aChlLMNQAOY50dkJlO4CdwpwC6tHqy9XCj9ouB 0+oerlUk6TqY4ZBDI9+kSEhQt/NvxB8/kd+IsLczQaYgMcW5k+FaVsLZXBY4cwLD56AHcGrL0gey w/PWnuOBkMQ3v1ChkQMbONJ961FLYq3aYOp5qRYfOaR0BeFhiOTU4RwHQgFL2IHlRY4ADO9Oyg6Z WJXlgaANwdTEnmWPGplHFL/1Tela2uZ+iGM5Eg5nwFBmOuUgKFHqc+XKu88rJLlHGoQqL8buGx8a 1jcyCQ5WWIi4PjHSLFu5PiJAda6YulD5JnX61754hfoqMmYhHGZVMP8ARoB9y6AcQI7X8CUtXw8O 4dtRsXKR6QL5nSldmDdygPewCxenmfs8zVvjpscMFhOWf+6qx301+HTD+6o/32cqMjph/dUkZ3sr D1NdYcLZZR0B8XIMcwsR/wC3T/xB2G5jPacFywkQwgg6UjsrFv8AIV/DpGKxNAweRSxDr9o7n0jH UrDOkRTtxLtp0lQgMO8seoXlbgTq5e+grPEX7aoVDNYkTPMRq03A0tnUsBeHuyQJGZcSdUTlwpNr lWXA1FudyIpIo33Esm2QFtIlVQixgqL+nwqXcbsMqhWg2Yk/WLDqZgX8eqnGuAKsIiRhe8jLMJg0 nThcCxxNGWX4aQybiaV4pNToqTaMRgt2XT4Vutoxj7M+6XcIVX6okSXQy/0bfiD5/I07AlVYiNP0 iPrUWuQt8LHE41aQG54LibHmaV4tuApGBY4keIvRLwqRjcjw9tWkQqbZg8PbUcgkDJqswtY9Qtem jjYhQx1I3Uo/OKklePUjqDrS5ZTfjxrTFuWe1tURa1/DHGgqdDR5R2GI8KKabK7Fl8zwqZmP+7YZ XzytWqOJdRWwlfGy/wAlDhjzNE3Mk7YGQ4nTfLkKHw/ZsQNIkDhgOJNqdv7r2tuOr9ZmOVPKxi1u xY+rAUDaHSRa/XagoO2suFmEmVRQ6tvoLaSvXbzorCu1RQbkjuanPJjRI+F7kvH7TCgqna2H/Uon +64nD9ZTOTtQoz/WV3H+G1Ocj3MqLx/CXA49zjSbSNolkG2Sbt6SxlkZ9BRLkHGp57oiLvvhNRTC GPVjK2OPKtuxKdWsahGbzaZNCsilgLFccGv4Wr+IPLJqnTdSBVkQgJGqao8L4BrYc6n3TOHbcy7f SrqQm3imQNq/m36fOo94xiM7yLG0yq3bVC+nuaW0nAeypty0vc+GTcIvZBKuI3jVZCtyL2Y0SjRD tbeSdmVCyuYpTHYdQwYVBFLKIUTdNH8KgIZoxGWWRsbkHytWX4g+Zo6cGayr5mu2h0qo0qRjhfE+ 2g+AkbBVtzp95vMZbXUNkq+XOrbaN5CMibqD7sfeRVn25TixDE/OdQpu/FdsASy8D7/y0zbV9JsT 2zYgjkMcKJAMkcyh2RRccmNWZXUk5LYnOhJGhUj1E4EmltIcM1bG3kaAmT1XAkH1T9NGEtrMzqIy L3KDqJYVaORQEATFs9Isauh1c3tZReiIAWOkkucLm1RRE2aSQ67cdOBrFbFr9X5q14hUvjbA2HiR Xw+1Us9xqOQFNI7B5T63GWfpj+mu64tpvpvhp8vGmmfFibDwHhVjibceVKw5cON6EIGC9TnjerkU WtYscB4UN4Yx8QE7Yk46L6tNeke6hgMMsKxUG+eFYgW435CjDMoZM7DAjkRbKjFt4wikktxLE5li cSTWQtblV7C/O1Z4ZfgbcwxrLJuJhCA7FQuoE3NgeVQiLaAlkMspZwqgCQxEBmsPq3xqWPs6EvuY 45Ee7h9sNeIZLYjzqPbSRqsblUEhe5ZmW/1V03/kmx40yvuYlYHFS6gg3440NDAqouCMQWYdPzUG J6V58hT7lzeOL9Wv1dQ5+FB2I7SEhAMjb6zUDHpVDhdr9Q5qBSjoawwaxU+zOiJY7KPrOoYH2ofy 13duSjHG/D30sjfrImZTbHUHxH5aQzKqMvqYAqx55Vfb7vQLZSDVl4rQvNDpJtqsxw8qaGOTuvID qduo+xRRnk1KFUKoNrotr9RbC5ooHclQSCuFmPM8aBOzeRT+rPdjF1prbJlJBIJmj9tLKdkyLt2L Oe4hwvj40LbXViCD3EGfGgI9kUc2BbvJY3oB9kRqxJ7qAyNyruybEm2AAmjAUUEXYHSPV9tHkK// AJ5sf+dHRY/w9sMLCaP56P8AcCHbBfto6+4G5zPeSgBsiScP10dBV/hjYCw+2jraxiOSLbPEpKon dBmZwGR2GACrxuPbW56pE3KRSSMhiGlHjk6UiOnq1JfnUkkurbxJBNuQxQW0sFEUZJHrQnEUzQvM +27yBNw0WmQoYtTYCI4auOipNv8AxCeZYG2yA2jWMM0mtWN2W4Iw9tJs9cz7ZX0LaIaO2FsNTMo8 9WvP6tCCKZkibcwwRoqBkdHF5NTFT1X8a2O2jjnWLQBIWjJXq13PoJuptmR5UivJO6yQwSyydkF4 2eTTKqBU4LwINbsuZ7nfLJHIUPe7ffjbuBNP6Nz6fZV74UZTu4u2raS2tbBiPTnnS33MfWvcUaxi gx155YGoBNuYpYop1ZAHUq0ljpQ53uDlW3LvtSEw2pOjDSdPR7RV220TXLNcoM5BZz/S40Nwm2jW ZcBIEAYWGnPypiVGFzlRfVa4LC3DgPmqRybG2kGludMkgsviXOn8lQx2shA1tl0LiffRj2UJZFPr bBbeFCLcRhdWAYYgk1Y5Xw91FiNDH6y4X9lXw0TLyv1JxtztSyq2mTJtJIAPG4N61RSauJ1AHA/z SDSsLMMrlSPyuKDdC3+sLC4+etWBci6mx025gc/Gg1lfEXJxzpdtubPA1tLWsyewV2XBVOpQcbHV bjU0EourE6lNtJHh50uOrayn7KTivHQ3lUaLibqL+3hSRH0RLqsARY+mtAv3GOo2+rfnVz1Na5I5 VbNrGw8L1qY2AzPOi5430jkKNqBNrJifP5B5fI0ciB0fBlYXBHiKsBYDIVl8i7loEO4X0ylRrHkf wHVjZWBBOVhatS/xGJjs5E7b9vABFZRrAOp8CTe9q3W12+9SaV9m23VWst3KyT6tV7Ws/u41HPN/ EY13Mb7bSFQlFeJCEUpe7agTiM6i2ifxOMSwa1kYJZjaQyuoYtwvk1+dGRd0pVSq343b09OZ1VEf iUIn/VWyOOnH21LGd1CsqggqZFBB5G5olNxCwsoazoeHnS9sj7Ug6lOrVW1g1agpVj/RwA99WIsW ULe+RfF/yUqgZjEZZ07DpI6qC3swAPzVa3IXppI11PAdYA+tb1L7RU22MYkTSJYif5XqsaB2kp0r h25MR5BqK7iDTfDUCbDxXMUAynhlw91AXci9+oHOrRR6icSWwH9WgFJaRzgeN+dKDcuV6rc7Y5UY pASVFklA4HnU6sBrjCvfhdDnUMi7czRqdWoMi43OHURwqSRtnJaQ9PXFgBn9fOhbYylBgT3Ir/69 WGwlUWII7kI/26u2xlxzYyQ3P+nQPwT6B6R3Iv7dWOyf9pF/brHYyEnICSL+3Vv/ANbMTmW1w5/t K/8A5k/9eH95WyjgR40kCdxGXUvW2hl1KGFwMcx7aMoeSSeSJpLGJegxzBOkaRmlzjUku3lIhE8g VhGQ7RqiFQhZCuZOefA1DLMCsjoGdSuggnmtzb3/AIbIcmBU+2vg33pZVYCENEulY1UoFYZtnzoK 8zGLsCFkAAJk7fZ7t8fqYWqAHcLq28sUoKRKmpYVKAMcyTfMmpQ8zFZtxLuHAFsJ0MbJnwvnRifc B3CxRxsYxpVIQQuBN72Y9QIPKtrq3jyfDAAiQa72fu3W56Tw44VKTDGWxN9IvfnVxGg1Ph0jLLOo EUabAAAcKcW1LEEJI8Tq/wBqo1wIZsAP5Nsa0nH/AONOMsLX86wOOnE0o4qMeWFE3wuKhIa6CaWA jLoILL7qCpiAxuBhTF9IFvS2furCNbjjGdJ+atCSSX5NZrfnoF5Wa/AWX6aOhQG4uTcj21bUA6j7 M+PjTRbmN0kBPXHgbj8tNCmr7ayKGwbTmb2rTqW1rKoF8PM00G8we3TKciPbxoBpcMTp51aMtp5n BfpNBmNzzOFqtQLHC9d2QWY+lTw+UXHKshhWVN2pFk7bFJNJB0sM1NsjR26yqZ1GoxBhrA56c/w8 vwpbmw0tjSi+TYYm4Fr1tgwub4+QFb1b4dC2vidI/wA1bdbWC6mN88/81DDE1GmS6rkeAo24m3sF NqyuRRCWC4+WAq8LIGG4ZgZASMuAUippVk23SRcaJPrG2HXRleTbtKLklkkPuOuh+pU8GRZBl5PW gS7d7cHV7589dfaGJR4RSN+SSivf2484Jbf69XE8DYWusEow/r0oHwzKvF43/PIb00pk2xc3uSj4 eA66/WbawH/Dk/t11SbVvONz/wBysDtFvyjcf7dfrdthyjk/t1bube+WMcl8P6dYvtrnnHJ/boO0 m1XkDHIf+5X6/a/spP3lfeNr+yf95X3ja/spP3lbWWJy0LoibjQxjjjMbiQsEJudY6a3moSjUyFY 0lFmKs19JZr202JHTfwobc6l3hYMwWU6ygfUVDljYlcPV7akKRzxxvuJ5O0kqiRhIEEbM+u2Fjz8 q3B2yyK8u4hkmIkBeWIKO4EYkC+ryoFnmWOPaOsDSzarbku2jWFwJ0nkahRzuQWlg+K1TCxVb90p pa4B88eVRxxCZ1RpVQCbBV7l01HWrenjqNv0aXWeoAavP8TKOYYWpo9QL3DFbcDW3Bxwxw8K3SjA Bxb2oahDYFo7HG+N2rHhTkYCMBffjQkdwqk4jM+wV1B7EkltB02NHssGAJGGdFbEkTYj+cL0iD68 gv4gVhwoXyxtR0nSeAq6gNhmMaF7heI4VqJwt51n51nax5UBmPHCrry86GGPjXXhzwrRCNXiBh7T QMnW4HsFYfgDy+XL5Mvky/FSyL6gDbzJsKE2z6dxHcKrf7wKcahYLodCFMZzBGZtU4Nr9LEt4Jb8 9bU8G1RkjwNEnAZ+6gxsZ52IRTb1tkPYKBLHdbh82K3byUcBRkl2rGIDpVbECmm2P2Uy2uhw1eyl dpUQgKZF1D1rhekb4mMujrpOsZccL196i/rrX3mL+stfeYr/AM8VhuogP563rHcQt/TW/wCWujdx AjgWBHz0Q0sTcSUcUD8Qqk5gmvvKe8VfvqTyBFdEqDldgKUSbqFb59YsBQjTd7cKBYASKK++wftF +mvv0H7Ra++wftF+mvvsH7Rfpr77B+0X6ai2u3gfeFoxMzRdQ7ZbR06Q1z7vOp4xtzGEbcRxy6gx 17ddZumGBFbcwxBYjKkM0jm7MWj7pCoMvO9Qx7SESSK22G4eQ6bncDUAoW/DjW37G2MnxBiTqcLp eYsFU4H9A13OyYTLHI0TXDkNAdMgK4ezHGm/hzwNFiQjyMFZtI9QRrXU4+kn8A7aWKVVEo25msuj uMutVwbViPCmljgnIGjt9KkP3G7YsQ1hjwJFM4SQJEsvdh0apBJEyoVBViPrf56n34R0h2+rXfSS dIvhoZh89Jt44Xi0SBdyJAGOl43lXR22PBaRItvNJJI7xqi6M0XuE6tem2k86hRIpWE4QqxCqPtO A1MC2njpvan5E2OHOkBxGnAi+BBoyyMCVGo4WNlHOhK/qnfUT5mwFXB64iHjvgSc2ApJFyfThl51 tttGLTFtSyDNF5gVr9Ujep2xY3rmbZGk3m2ADK3UnHOkmH+9XqAyuwOHvqZWvpjfDibBqAJubXv5 jnWPqyOF6BDZ8q9VyMgaN0IFHVblaulgPnq7MDXrA8qtr1Mcsa1KtwL9ROZoLmSLsfE1kPdXpHur 0j3V6R7q9I91ZD3Uk24hV5EGkNzUHVpa3qF8bGtxK8ZmfcNIzFzcL3vWqDhh7aEpgGpQLAEgdI0g 2va9sL0kkcIjmjVRHIt8DGLRsRkxXheiki/ESGb4lpHtqM36XTYC1CNoFKKHCrjh3Td/fXxkcKif EhhwLYMwGQJ5/gTb7ckzPJIJY0a4SNlXQDpvpJ8a0LGxW6kBndrds6lC3bAA1I6x4yGQyEO2cpDP xwyHlU+0gUom4v3GN3YluJL3vU0u6Y7mSZg2OrSNKGK1mZicGOZpXhiIMRJUl3a2pe2fUf0cPCo2 MRIhChF1tosnpuuqxt41LMHn1X1ECeULnj0hrCpIWeYFWuFE0gGk8T1VPp4xta3DwFQzqbCNh4m5 yqGS5DLIM74BlYt7KhBPVdAOFKT9VABQ44CieeYphlxy50UJBaKYEY46WN636RnUGBNjfDjUfAFe nHMisur5qF1qwFvCvKrnjwrz5C1WDHHkbH311Sthj7qDMwNuOd61HAZqvI3ofJjWFW+VQSL2y+Sx OX4ndLCWEpifQY/XqthpraxbFJUcwwusax3WSdmHeEx04WXmRTzRyTdx93okXRcx7dWazRqq6jfD nWzKNuJC62YCIRsza7Atg4Xp4Nat/EYpF28h3ckIVC/clPpEmpSLW9NsDUMpabt/FLCYDGBGIO2C WsFBwbC9Mq7eMx3I1GW1x5aDSytclRa4yaLkeZWlDse2bDV/JYUdqw+0WTQBncg4VDttWlnuQpxL D0r+Wok/QZfmqCW/Q91vyNLc4286PHDjRJ2sY4D7f/x1M77dVIVS3236J/mVu5E2ykBFZwZbYFcx 9mb0EXaowB6SZrcP+ma+5R3/AOv/AOKrnZxf4g/uq+5w2/8AyD+6r7nFh/8Acf8Air7pF/iP/FX3 SLHD7x/4qw2SYWymP7qj/dFA/wCtz/8AbrW20TDCxnv/ANutQ2iANh1T2OP/ALdD+5w/4g/uq+5w /wCIP7qrfBw/4g/uqt8HB/iD+6r7nD/iD+6r7pB/iD+6r7lB/iD+6pt5tkk1PsisSJ9pGk2oFlGH 6OIvnRIlncd22owMrEab2vYvpvx0Z4ZVudxLHO8m4j2jRpIgcAK9pMlKgjP56dN13miOvUWTtotj hYFfdpY3H4m9sfkxw+THDzo12txGHTkeFPt9jIZQpw25tKw+j2024YGN2IbUNIA4U805726a2qQ9 Vh4U9+AuLc6YqblLSIV5jEigSbjC9XON6vkDUyggWREy4ltVbydmszt21UjOw0r7K1nHE29leBNL ccK8PGhgOVCyi3HCr8DXPxrSOPEViOOOBpdWZYfJjV6N/ZWPyj8ZOmxErB4ojttEXcGvX9piFNun nTzI0vdfdmNgUBMcAZrMirGTjhwNSyzGecybQIgVCg1iUX+zAwJWxx/zVDslnm+HWVlebtrqKCJX W50aba7iptvuIJjt1eN0vGRZknCmzKoFtGPHzp44NuQVw7kpCx+zSSx91X3cpkX/AIK9MeHl1N7T 7KsihEKjSFAH5KFxccaIAzrSRjR27cATGeBHI13IhfbucUGJU0CDcfnoySmyr44seQokreVzrf8A nH0J7Kh2rMoJYtIzWAuTxJoQru4QAP8AiLn76Grdwgf9Rf7VffIP2i/TX3yH9ov0198g8PtF+mvv kH7RfprHeQHykUfnr75CMP8AiL9NYbuHD/mL9Nfe4MePcX6aUneQADP7Rfpr77B+0X6a++QftF+m vvkGH/MX6a++QftF+mvvkP7Rfpr75B+0X6a++wftF+mo9mIyY5NIWcsFV9Qzj1YNbC9jUe6j2shj nmG32xLKBIWLLc8VxXlTqNqToc7fVrFviAnc0/zfGll3W3Jl+Gj3L6GGn7V+2AL++jt02rMzPLHC dYAdoMXv+jhjUW7jBVZlDBWzF/wx8D3tKrGdusa3jeQyWkEhtgNPMipm2MksxHxaya0+zQobQ9sk AE3qOJp9yY2mCvKYzGwAjJaxa506wMSBW2cpLHLK23j3LrHpbt6pVe7ab5BTQG4nlhWOGQxkDraU TFE7llyKcbClJzIFz4kfIjHJlIPmKBuR4VfnwoA486KXKMfS44Ghtt6lhkJB1KRWtCCrYmRW0m/l SFSVkRrqW6lt4g0XldZJcgoGkXvyzr4yb1G/bT6aJYXPCwHCuBwwrIe6sh7qyHurL5qtYY1ewq4F vOrnH2CsVF6uQPdVyB7qyHur0jDwo9I9wrIe4V6R7qXdPCDMLG+IBK+ksowJHChp26jTKJlAvhIp JBHIY5ZUd0YQZSdRxOktbTq0enVbjSJJBqWMaVGph0lteg2OIByHClkEA1o0jqccGmwkOfGk28K6 IoxZFxwHt/EEIoUEkkAWxOJNZfIryxK7R4ozAEqfCj5/IrHMXtQBztx/NQvwq/yFJVVxxB/NQbbN p42Yn5jV/ibNyxwFCWS80ox1ucL87UAAABwGFYVz/A8q/P8AJ5/JblWFc6/N+CPL/wBCfP5PfSeV D5RTeVeyvZ+GflHyH8QPL8V//9k= ------=_NextPart_000_0004_01C5AB42.305894B0-- X-Spam-Score: 1.9 (+) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From owner-ccamp@ops.ietf.org Mon Aug 29 10:29:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kdQ-0005KX-Kp for ccamp-archive@megatron.ietf.org; Mon, 29 Aug 2005 10:29: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 KAA13405 for ; Mon, 29 Aug 2005 10:29:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9keg-0001WJ-68 for ccamp-archive@ietf.org; Mon, 29 Aug 2005 10:30:41 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9kP4-000Q0p-Sw for ccamp-data@psg.com; Mon, 29 Aug 2005 14:14:26 +0000 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E9kP1-000PxI-1k for ccamp@ops.ietf.org; Mon, 29 Aug 2005 14:14:23 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 29 Aug 2005 14:26:33 +0000 X-SBRS: None X-IronPort-AV: i="3.96,149,1122854400"; d="scan'208"; a="27172515:sNHT24481608" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Aug 2005 09:13:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Final draft of response to the OIF Date: Mon, 29 Aug 2005 09:11:32 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWqV26XP5LabOwhTMKk34aYghybOwCSkKug From: "Mack-Crane, T. Benjamin" To: "Huub van Helvoort" Cc: "Adrian Farrel" , X-OriginalArrivalTime: 29 Aug 2005 14:13:19.0403 (UTC) FILETIME=[CE7F67B0:01C5ACA3] Content-Transfer-Encoding: 7bit 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: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Hi Huub, See in-line below. Regards, Ben > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > Sent: Friday, August 26, 2005 10:56 AM > To: Mack-Crane, T. Benjamin > Cc: Adrian Farrel; ccamp@ops.ietf.org > Subject: Re: Final draft of response to the OIF > > Hello Ben, > > You wrote: > > > I proposed a simple (and I think technically sound) solution to > > item #1 and saw no objections, however the answer has not changed. > > > > I do not understand the reason for different encodings for > > VC-4 and STS-3c SPE. I think they should be the same, unless > > there is a technical need to distinguish them. > > If there is agreement that they should be the same, we should > also look at higher order contiguous concatenated signals: > i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c > STS-768c == VC-4-256c These signals are already encoded the same way (for instance see examples 3 and 9 in RFC 3946). > > > I also do not understand the RCC=1 NCC=1 encoding, since the rule > > contained in the current RFC actually makes more sense. > > However indicating the number of signals concatenated in NCC > makes your first objective impossible: STS-3Xc == VC-4-Xc > so there will always be a difference of a factor 3 between > STS and VC-4 encoding All the encodings of contiguous concatenated signals use VC-4 (STS-3c SPE) as the base, so the NCC values are the same. This was done to align SONET and SDH encodings. > > > If there is > > only > > one signal element, there is no contiguous concatenation, > by definition. > > In fact a single signal is always contiguous concatenated ;-) > > > So I fail to see the usefulness of these encodings. > > NCC = 1 would normally not occur, so it could be used for > this specific case of SONET signals transported in an > SDH world, or SDH signals transported in SONET land. > And if these signals would not cross borders the value > NCC > 1 can be used. The SDH and SONET encodings have been aligned in all cases except this one (VC-4, STS-3c SPE). So these should also be aligned. > > > Regards, > > Ben > > Cheers, Huub. > > -- > ================================================================ > 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 Mon Aug 29 18:59:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sbU-0002n3-Mw for ccamp-archive@megatron.ietf.org; Mon, 29 Aug 2005 18:59: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 SAA17991 for ; Mon, 29 Aug 2005 18:59:45 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9scv-0001oy-77 for ccamp-archive@ietf.org; Mon, 29 Aug 2005 19:01:17 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9sS5-000Nt9-Nu for ccamp-data@psg.com; Mon, 29 Aug 2005 22:50:05 +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 1E9sS2-000Nre-NU for ccamp@ops.ietf.org; Mon, 29 Aug 2005 22:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E9sS1-0000Q1-Mi; Mon, 29 Aug 2005 18: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-te-exclude-route-05.txt Message-Id: Date: Mon, 29 Aug 2005 18: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: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : Exclude Routes - Extension to RSVP-TE Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-rsvp-te-exclude-route-05.txt Pages : 26 Date : 2005-8-29 The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. In some networks where precise explicit paths are not computed at the head end it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SLRGs) can be excluded is also specified in this document. This document specifies ways to communicate route exclusions during path setup using RSVP-TE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.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-te-exclude-route-05.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-te-exclude-route-05.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-8-29165947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-te-exclude-route-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-29165947.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Aug 30 17:08:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EADKs-0004hO-Qk for ccamp-archive@megatron.ietf.org; Tue, 30 Aug 2005 17:08: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 RAA09810 for ; Tue, 30 Aug 2005 17:08:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EADMJ-000674-0C for ccamp-archive@ietf.org; Tue, 30 Aug 2005 17:09:43 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EADBO-000PTf-3i for ccamp-data@psg.com; Tue, 30 Aug 2005 20:58:14 +0000 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1EADBI-000PSo-RB for ccamp@ops.ietf.org; Tue, 30 Aug 2005 20:58:08 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j7UKw5oh023553; Tue, 30 Aug 2005 13:58:05 -0700 (PDT) Received: from fujitsu7i.fnanic.fujitsu.com ([133.164.253.7]) by fujitsu0.fujitsu.com (8.13.1/8.13.1) with ESMTP id j7UKw4ts023539; Tue, 30 Aug 2005 13:58:04 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsu7i.fnanic.fujitsu.com (8.13.2/8.13.2) with ESMTP id j7UKw33Y017857; Tue, 30 Aug 2005 13:58:03 -0700 (PDT) Received: from [133.164.16.65] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id j7UKw0W09703; Tue, 30 Aug 2005 13:58:02 -0700 (PDT) Message-ID: <4314C857.9050604@us.fujitsu.com> Date: Tue, 30 Aug 2005 13:57:59 -0700 From: Richard Rabbat Organization: Fujitsu Labs of America 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: Huub van Helvoort , Adrian Farrel , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------010407070100000003070807" 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: 6ba8aaf827dcb437101951262f69b3de This is a multi-part message in MIME format. --------------010407070100000003070807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ben, Adrian's final draft of the response is most inclusive. From what you said earlier, it seems that you've already coded it in one way (whichever) but are accepting both sets of values for NCC & RCC (both 1 or 0). Is there an engineering problem with the text of the response besides that you would be able to remove those couple of lines of code? if so, we should solve it. Richard. Mack-Crane, T. Benjamin wrote: >Hi Huub, > >See in-line below. > >Regards, >Ben > > > >>-----Original Message----- >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] >>Sent: Friday, August 26, 2005 10:56 AM >>To: Mack-Crane, T. Benjamin >>Cc: Adrian Farrel; ccamp@ops.ietf.org >>Subject: Re: Final draft of response to the OIF >> >>Hello Ben, >> >>You wrote: >> >> >> >>>I proposed a simple (and I think technically sound) solution to >>>item #1 and saw no objections, however the answer has not changed. >>> >>>I do not understand the reason for different encodings for >>>VC-4 and STS-3c SPE. I think they should be the same, unless >>>there is a technical need to distinguish them. >>> >>> >>If there is agreement that they should be the same, we should >>also look at higher order contiguous concatenated signals: >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c >>STS-768c == VC-4-256c >> >> > >These signals are already encoded the same way (for instance see >examples 3 and 9 in RFC 3946). > > > >>>I also do not understand the RCC=1 NCC=1 encoding, since the rule >>>contained in the current RFC actually makes more sense. >>> >>> >>However indicating the number of signals concatenated in NCC >>makes your first objective impossible: STS-3Xc == VC-4-Xc >>so there will always be a difference of a factor 3 between >>STS and VC-4 encoding >> >> > >All the encodings of contiguous concatenated signals use VC-4 >(STS-3c SPE) as the base, so the NCC values are the same. This >was done to align SONET and SDH encodings. > > > >>>If there is >>>only >>>one signal element, there is no contiguous concatenation, >>> >>> >>by definition. >> >>In fact a single signal is always contiguous concatenated ;-) >> >> >> >>>So I fail to see the usefulness of these encodings. >>> >>> >>NCC = 1 would normally not occur, so it could be used for >>this specific case of SONET signals transported in an >>SDH world, or SDH signals transported in SONET land. >>And if these signals would not cross borders the value >>NCC > 1 can be used. >> >> > >The SDH and SONET encodings have been aligned in all cases >except this one (VC-4, STS-3c SPE). So these should also >be aligned. > > > >>>Regards, >>>Ben >>> >>> >>Cheers, Huub. >> >>-- >>================================================================ >> 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 >============================================================ > > > --------------010407070100000003070807 Content-Type: text/x-vcard; charset=utf-8; name="richard.vcf" Content-Disposition: attachment; filename="richard.vcf" Content-Transfer-Encoding: 7bit begin:vcard fn:Richard Rabbat n:Rabbat;Richard org:Fujitsu Labs of America;IP Networking Research adr:MS 345;;1240 East Arques Ave;Sunnyvale;CA;94085;USA email;internet:richard@us.fujitsu.com title:Senior Project Manager tel;work:1-408-530-4537 tel;fax:1-408-530-4515 tel;cell:1-650-714-7618 x-mozilla-html:TRUE version:2.1 end:vcard --------------010407070100000003070807-- From owner-ccamp@ops.ietf.org Tue Aug 30 17:57:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAE6e-0002Tq-Nh for ccamp-archive@megatron.ietf.org; Tue, 30 Aug 2005 17:57: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 RAA11727 for ; Tue, 30 Aug 2005 17:57:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAE8A-0007IG-W6 for ccamp-archive@ietf.org; Tue, 30 Aug 2005 17:59:05 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAE0P-000ACK-55 for ccamp-data@psg.com; Tue, 30 Aug 2005 21:50:57 +0000 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAE0N-000AC0-5V for ccamp@ops.ietf.org; Tue, 30 Aug 2005 21:50:55 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 30 Aug 2005 22:04:03 +0000 X-SBRS: None X-IronPort-AV: i="3.96,154,1122854400"; d="scan'208"; a="27342660:sNHT24430084" 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, 30 Aug 2005 16:50:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Final draft of response to the OIF Date: Tue, 30 Aug 2005 16:48:39 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWtpbcSdsIcyKOURZS82NqCXAxtoQABMWHQ From: "Mack-Crane, T. Benjamin" To: "Richard Rabbat" Cc: "Huub van Helvoort" , "Adrian Farrel" , X-OriginalArrivalTime: 30 Aug 2005 21:50:54.0397 (UTC) FILETIME=[E55CC6D0:01C5ADAC] Content-Transfer-Encoding: 7bit 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: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Hi Richard, A long time ago an agreement was reached to unify the SDH and SONET encodings, since carriers did not want to manage unnecessary differences. What implementations have done as a result of the bad example in RFC 3946 is unfortunate, and leads to interop problems -- and thus the item from the OIF. This is our opportunity to fix the example and removed the problem (and then folks can simplify their implementations). If the difference remains, there will be opportunity for creating more interop problems (if implementations behave differently for the different encodings). So, rather than make things more complicated by modifying an accepted rule (RCC=1 requires NCC>1), retaining two encodings for the same signal, and adding notes to attempt to explain the interworking options, it is much easier to correct the example. This is good engineering practice, in my view. Regards, Ben > -----Original Message----- > From: Richard Rabbat [mailto:richard@us.fujitsu.com] > Sent: Tuesday, August 30, 2005 3:58 PM > To: Mack-Crane, T. Benjamin > Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org > Subject: Re: Final draft of response to the OIF > > Ben, > Adrian's final draft of the response is most inclusive. From what you > said earlier, it seems that you've already coded it in one way > (whichever) but are accepting both sets of values for NCC & > RCC (both 1 > or 0). > Is there an engineering problem with the text of the response besides > that you would be able to remove those couple of lines of > code? if so, > we should solve it. > Richard. > > > Mack-Crane, T. Benjamin wrote: > > >Hi Huub, > > > >See in-line below. > > > >Regards, > >Ben > > > > > > > >>-----Original Message----- > >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > >>Sent: Friday, August 26, 2005 10:56 AM > >>To: Mack-Crane, T. Benjamin > >>Cc: Adrian Farrel; ccamp@ops.ietf.org > >>Subject: Re: Final draft of response to the OIF > >> > >>Hello Ben, > >> > >>You wrote: > >> > >> > >> > >>>I proposed a simple (and I think technically sound) solution to > >>>item #1 and saw no objections, however the answer has not changed. > >>> > >>>I do not understand the reason for different encodings for > >>>VC-4 and STS-3c SPE. I think they should be the same, unless > >>>there is a technical need to distinguish them. > >>> > >>> > >>If there is agreement that they should be the same, we should > >>also look at higher order contiguous concatenated signals: > >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c > >>STS-768c == VC-4-256c > >> > >> > > > >These signals are already encoded the same way (for instance see > >examples 3 and 9 in RFC 3946). > > > > > > > >>>I also do not understand the RCC=1 NCC=1 encoding, since the rule > >>>contained in the current RFC actually makes more sense. > >>> > >>> > >>However indicating the number of signals concatenated in NCC > >>makes your first objective impossible: STS-3Xc == VC-4-Xc > >>so there will always be a difference of a factor 3 between > >>STS and VC-4 encoding > >> > >> > > > >All the encodings of contiguous concatenated signals use VC-4 > >(STS-3c SPE) as the base, so the NCC values are the same. This > >was done to align SONET and SDH encodings. > > > > > > > >>>If there is > >>>only > >>>one signal element, there is no contiguous concatenation, > >>> > >>> > >>by definition. > >> > >>In fact a single signal is always contiguous concatenated ;-) > >> > >> > >> > >>>So I fail to see the usefulness of these encodings. > >>> > >>> > >>NCC = 1 would normally not occur, so it could be used for > >>this specific case of SONET signals transported in an > >>SDH world, or SDH signals transported in SONET land. > >>And if these signals would not cross borders the value > >>NCC > 1 can be used. > >> > >> > > > >The SDH and SONET encodings have been aligned in all cases > >except this one (VC-4, STS-3c SPE). So these should also > >be aligned. > > > > > > > >>>Regards, > >>>Ben > >>> > >>> > >>Cheers, Huub. > >> > >>-- > >>================================================================ > >> 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 > >============================================================ > > > > > > > ============================================================ 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 Tue Aug 30 18:18:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAER5-0008Uh-H7 for ccamp-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:18:32 -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 SAA13319 for ; Tue, 30 Aug 2005 18:18:28 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAEST-0007kE-Q2 for ccamp-archive@ietf.org; Tue, 30 Aug 2005 18:20:09 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAELF-000F2C-4O for ccamp-data@psg.com; Tue, 30 Aug 2005 22:12:29 +0000 Received: from [80.168.70.142] (helo=relay2.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAELD-000F1y-Ta for ccamp@ops.ietf.org; Tue, 30 Aug 2005 22:12:28 +0000 Received: from du-069-0151.access.clara.net ([217.158.132.151] helo=Puppy) by relay2.mail.uk.clara.net with smtp (Exim 4.50) id 1EA9AW-000OOw-7S for ccamp@ops.ietf.org; Tue, 30 Aug 2005 17:41:06 +0100 Message-ID: <0eb701c5ad81$fe3f87d0$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: RFC 3946 bis Date: Tue, 30 Aug 2005 17:43: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 autolearn=ham version=3.0.2 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Hi, In view of the issues raised on the list in March and more recently by the OIF in their questions, I have asked the editors of RFC 3946 to prepare an I-D that is a bis on the RFC to document what they intended to write. That is, to document the consensus of the WG at the time the I-D was submitted to be an RFC, As such, this I-D is not a change to the procedures that were agreed, and does not reflect any change in the implementation. it is simply a clarification of what was written. In particular, it fixes a typo where "greater than" was written and "greater than or equal to" was meant. I note that Ben has been raising an issue that proposes a change to the procedures documented in RFC 3946. I have not seen any support for this so far, and I do not propose that we should make such a change to RFC 3946 in this I-D. Thanks to Dimitri for moving forward with these editorial changes. If you look through the draft you will see that Dimitri has inserted notes to highlight the changes (to make it easy for you to review and to explain the changes). I would like to move this I-D through the process PDQ so I will give you a short time to read, digest and send mail. Barring any major upsets, we will make this a WG I-D on 7th September, and then look for any other editorial clarifications we should make at the same time, before moving rapidly on to WG last call. Thanks, Adrian ----- Original Message ----- From: To: Sent: Monday, August 29, 2005 11:50 PM Subject: I-D ACTION:draft-papadimitriou-ccamp-rfc3946bis-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Generalized Multi-Protocol Label Switching > (GMPLS) Extensions for Synchronous Optical > Network (SONET) and Synchronous Digital > Hierarchy (SDH) Control > Author(s) : E. Mannie, D. Papadimitriou > Filename : draft-papadimitriou-ccamp-rfc3946bis-00.txt > Pages : 24 > Date : 2005-8-29 > > This document provides minor clarification to RFC 3946. > > This document is a companion to the Generalized Multi-Protocol > Label Switching (GMPLS) signaling. It defines the Synchronous > Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) > technology specific information needed when using GMPLS signaling. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-rfc3946bis-00.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-papadimitriou-ccamp-rfc3946bis-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-papadimitriou-ccamp-rfc3946bis-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------- ------ > _______________________________________________ > 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 Tue Aug 30 18:38:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAEkZ-0004q0-CU for ccamp-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:38: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 SAA14344 for ; Tue, 30 Aug 2005 18:38:36 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAEmB-00089k-6n for ccamp-archive@ietf.org; Tue, 30 Aug 2005 18:40:20 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAEhO-000JcG-BP for ccamp-data@psg.com; Tue, 30 Aug 2005 22:35:22 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAEhN-000Jbl-Lq for ccamp@ops.ietf.org; Tue, 30 Aug 2005 22:35:21 +0000 Received: from du-069-0190.access.clara.net ([217.158.132.190] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1EA9wE-000Pv0-J1 for ccamp@ops.ietf.org; Tue, 30 Aug 2005 18:30:23 +0100 Message-ID: <0ee701c5ad88$e1c18200$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Clarifying the basis for new work in CCAMP Date: Tue, 30 Aug 2005 18:15:43 +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: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Hi, I have had some email seeking clarification of the basis upon which we will construct new CCAMP drafts if/when we have new milestones within our charter. The text accompanying the milestones was intended to fuel the discussion and is not proposed as part of the charter. It included the words... > Existing drafts > are referenced to indicate that work is already in progress - > this is not intended to provide a complete list of existing > drafts. My covering email said... > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. To clarify this still further: The CCAMP WG drafts will be refined and submitted to the IESG by the WG. The milestones are: a. To have a WG draft on the subject b. To submit that draft to the IESG This doesn't prohibit other WG drafts near the subject, but I would assume that we only have one draft that is precisely on target. We will obviously need to select drafts to use as the foundations of the WG drafts. This choice will be made on a case by case basis. In some cases an existing draft will be used; in others we will need to start a new draft because no pre-existing work exists, or because we need to combine two or more existing drafts. The point, however, is to build a WG draft out of the working group, and then refine the draft until it is submitted. All material is taken as input and filtered through WG consensus. I hope this clarifies. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Aug 30 18:38:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAEkb-0004qE-VZ for ccamp-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:38: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 SAA14350 for ; Tue, 30 Aug 2005 18:38:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAEmE-00089r-T3 for ccamp-archive@ietf.org; Tue, 30 Aug 2005 18:40:23 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAEfl-000JNM-Ua for ccamp-data@psg.com; Tue, 30 Aug 2005 22:33:41 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAEfk-000JN4-OJ for ccamp@ops.ietf.org; Tue, 30 Aug 2005 22:33:41 +0000 Received: from du-069-0239.access.clara.net ([217.158.132.239] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1EA5eg-0006wN-Ie for ccamp@ops.ietf.org; Tue, 30 Aug 2005 13:56:00 +0100 Message-ID: <0dde01c5ad62$8c1dca50$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-05.txt Date: Tue, 30 Aug 2005 13:43: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: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Hi, Revision 04 of this document was made by the authors to include updates after WG last call. Revision 05 was made by me to handle purely editorial issues (formatting, section numbering, typos) and includes no technical changes. I will now pass this to the ADs for IESG review. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, August 29, 2005 11:50 PM Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-05.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 : Exclude Routes - Extension to RSVP-TE > Author(s) : A. Farrel, et al. > Filename : draft-ietf-ccamp-rsvp-te-exclude-route-05.txt > Pages : 26 > Date : 2005-8-29 > > The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP > Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized > Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation > Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow > abstract nodes and resources to be explicitly included in a path > setup, but not to be explicitly excluded. > > In some networks where precise explicit paths are not computed at the > head end it may be useful to specify and signal abstract nodes and > resources that are to be explicitly excluded from routes. These > exclusions may apply to the whole path, or to parts of a path between > two abstract nodes specified in an explicit path. How Shared Risk > Link Groups (SLRGs) can be excluded is also specified in this > document. > > This document specifies ways to communicate route exclusions during > path setup using RSVP-TE. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.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-te-exclude-route-05.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-te-exclude-route-05.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 Aug 30 19:13:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAFIT-0000Bl-AB for ccamp-archive@megatron.ietf.org; Tue, 30 Aug 2005 19:13: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 TAA16862 for ; Tue, 30 Aug 2005 19:13:37 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAFK6-0000wK-CR for ccamp-archive@ietf.org; Tue, 30 Aug 2005 19:15:23 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAFEM-000Pse-WD for ccamp-data@psg.com; Tue, 30 Aug 2005 23:09:27 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAFEK-000PsI-IO for ccamp@ops.ietf.org; Tue, 30 Aug 2005 23:09:24 +0000 Received: from du-069-0024.access.clara.net ([217.158.132.24] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EAFEB-0009Bg-FT; Wed, 31 Aug 2005 00:09:21 +0100 Message-ID: <0f6601c5adb8$3967d160$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Mack-Crane, T. Benjamin" , "Richard Rabbat" Cc: "Huub van Helvoort" , References: Subject: Re: Final draft of response to the OIF Date: Wed, 31 Aug 2005 00:11: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: a4a24b484706be629f915bfb1a3e4771 Content-Transfer-Encoding: 7bit Hi Ben, > A long time ago an agreement was reached to unify > the SDH and SONET encodings, since carriers did not > want to manage unnecessary differences. Good motivation. Presume that here you are not really talking about the SDH and SONET encoding, but rather the control plane encodings. > What implementations have done as a result of the > bad example in RFC 3946 is unfortunate, and leads to > interop problems -- and thus the item from the OIF. Whether the example is bad or not clearly depends on the encoding rules specified in the RFC. With the clarification from the Editors, it would appear that the example is good. Now, you can object to the encoding rules, but that doesn't mean that the example is bad. I have not heard of any interop problems. Centrainly the message from the OIF did not report any such problems. My understanding is that there were no interope problems, merely a question about intended encodings. With the rule of "liberal in what you receive" I would not expect any interop problems. > This is our opportunity to fix the example and > removed the problem (and then folks can simplify > their implementations). If the difference remains, > there will be opportunity for creating more interop > problems (if implementations behave differently for > the different encodings). I'd like to clarify the extent of the simplification that you are proposing in people's implementations. You are suggesting replacing a line of code that says: if ( (rcc==1) && (ncc == 0 || ncc == 1) ) with a line of code that says if ( (rcc==1) && (ncc == 1) ) Why is this a big deal? > So, rather than make things more complicated by > modifying an accepted rule (RCC=1 requires NCC>1), > retaining two encodings for the same signal, and > adding notes to attempt to explain the interworking > options, it is much easier to correct the example. Again, I think you are misrepresenting what the authors are doing. In their view they are not changing the rules, but correcting an editorial mistake. In their opinion the example is already correct. Now, I don't want to start any voting here, but I see several people who are expressing support for the ideas in draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying make the change the other way. If I was to judge consensus today, it is pretty clear how I would call it. Let's hear some opinions from other people who have an interest in this work. Thanks, Adrian > > This is good engineering practice, in my view. > > Regards, > Ben > > > -----Original Message----- > > From: Richard Rabbat [mailto:richard@us.fujitsu.com] > > Sent: Tuesday, August 30, 2005 3:58 PM > > To: Mack-Crane, T. Benjamin > > Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org > > Subject: Re: Final draft of response to the OIF > > > > Ben, > > Adrian's final draft of the response is most inclusive. From what you > > said earlier, it seems that you've already coded it in one way > > (whichever) but are accepting both sets of values for NCC & > > RCC (both 1 or 0). > > Is there an engineering problem with the text of the response besides > > that you would be able to remove those couple of lines of > > code? if so, > > we should solve it. > > Richard. > > > > > > Mack-Crane, T. Benjamin wrote: > > > > >Hi Huub, > > > > > >See in-line below. > > > > > >Regards, > > >Ben > > > > > > > > > > > >>-----Original Message----- > > >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > > >>Sent: Friday, August 26, 2005 10:56 AM > > >>To: Mack-Crane, T. Benjamin > > >>Cc: Adrian Farrel; ccamp@ops.ietf.org > > >>Subject: Re: Final draft of response to the OIF > > >> > > >>Hello Ben, > > >> > > >>You wrote: > > >> > > >> > > >> > > >>>I proposed a simple (and I think technically sound) solution to > > >>>item #1 and saw no objections, however the answer has not changed. > > >>> > > >>>I do not understand the reason for different encodings for > > >>>VC-4 and STS-3c SPE. I think they should be the same, unless > > >>>there is a technical need to distinguish them. > > >>> > > >>> > > >>If there is agreement that they should be the same, we should > > >>also look at higher order contiguous concatenated signals: > > >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c > > >>STS-768c == VC-4-256c > > >> > > >> > > > > > >These signals are already encoded the same way (for instance see > > >examples 3 and 9 in RFC 3946). > > > > > > > > > > > >>>I also do not understand the RCC=1 NCC=1 encoding, since the rule > > >>>contained in the current RFC actually makes more sense. > > >>> > > >>> > > >>However indicating the number of signals concatenated in NCC > > >>makes your first objective impossible: STS-3Xc == VC-4-Xc > > >>so there will always be a difference of a factor 3 between > > >>STS and VC-4 encoding > > >> > > >> > > > > > >All the encodings of contiguous concatenated signals use VC-4 > > >(STS-3c SPE) as the base, so the NCC values are the same. This > > >was done to align SONET and SDH encodings. > > > > > > > > > > > >>>If there is > > >>>only > > >>>one signal element, there is no contiguous concatenation, > > >>> > > >>> > > >>by definition. > > >> > > >>In fact a single signal is always contiguous concatenated ;-) > > >> > > >> > > >> > > >>>So I fail to see the usefulness of these encodings. > > >>> > > >>> > > >>NCC = 1 would normally not occur, so it could be used for > > >>this specific case of SONET signals transported in an > > >>SDH world, or SDH signals transported in SONET land. > > >>And if these signals would not cross borders the value > > >>NCC > 1 can be used. > > >> > > >> > > > > > >The SDH and SONET encodings have been aligned in all cases > > >except this one (VC-4, STS-3c SPE). So these should also > > >be aligned. > > > > > > > > > > > >>>Regards, > > >>>Ben > > >>> > > >>> > > >>Cheers, Huub. > > >> > > >>-- > > >>================================================================ > > >> 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 > > >============================================================ > > > > > > > > > > > > ============================================================ > 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 Tue Aug 30 20:55:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAGsd-0002Yt-9m for ccamp-archive@megatron.ietf.org; Tue, 30 Aug 2005 20:55:09 -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 UAA20813 for ; Tue, 30 Aug 2005 20:55:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAGu6-0003Jw-Lb for ccamp-archive@ietf.org; Tue, 30 Aug 2005 20:56:49 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAGmL-000HBD-Mg for ccamp-data@psg.com; Wed, 31 Aug 2005 00:48:37 +0000 Received: from [66.226.64.2] (helo=pro.abac.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAGmJ-000H7w-Bb for ccamp@ops.ietf.org; Wed, 31 Aug 2005 00:48:35 +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 j7V0mMLa085660; Tue, 30 Aug 2005 17:48:25 -0700 (PDT) (envelope-from gregb@grotto-networking.com) Message-ID: <4314FE56.4070407@grotto-networking.com> Date: Tue, 30 Aug 2005 17:48:22 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: "Mack-Crane, T. Benjamin" , Richard Rabbat , Huub van Helvoort , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF References: <0f6601c5adb8$3967d160$c5919ed9@Puppy> In-Reply-To: <0f6601c5adb8$3967d160$c5919ed9@Puppy> 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=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: 52f402fbded34a6df606921f56b8bdd8 Content-Transfer-Encoding: 7bit Hi folks, a bit of history. At the time the ID was originally written a number of manufacturers had (and still offer) more flexible forms of concatenation rather than the standard SONET/SDH contiguous concatenation. This and the usual standards related compromises lead to the rather general and possibly confusing rules that appear in RFC 3946. Unknown to us at the time was that none of these proprietary schemes would become standardized. This is mostly due to the greater abilities of Virtual Concatenation (VCAT) which was standardized and since extended beyond SONET/SDH to OTN and PDH. Hence though RFC3946 encoding seems a bit obtuse the intentions were aimed at future proofing (but part of that future didn't happen). I've tried to make ammends by working with Richard and others to clear things up while minimizing the impact to implementations. At this point in time is there any other option since this is already a standards track RFC? Greg B. Adrian Farrel wrote: >Hi Ben, > > > >>A long time ago an agreement was reached to unify >>the SDH and SONET encodings, since carriers did not >>want to manage unnecessary differences. >> >> > >Good motivation. > >Presume that here you are not really talking about the SDH and SONET >encoding, but rather the control plane encodings. > > > >>What implementations have done as a result of the >>bad example in RFC 3946 is unfortunate, and leads to >>interop problems -- and thus the item from the OIF. >> >> > >Whether the example is bad or not clearly depends on the encoding rules >specified in the RFC. >With the clarification from the Editors, it would appear that the example >is good. Now, you can object to the encoding rules, but that doesn't mean >that the example is bad. > >I have not heard of any interop problems. Centrainly the message from the >OIF did not report any such problems. My understanding is that there were >no interope problems, merely a question about intended encodings. With the >rule of "liberal in what you receive" I would not expect any interop >problems. > > > This is our opportunity to fix the example and > > >>removed the problem (and then folks can simplify >>their implementations). If the difference remains, >>there will be opportunity for creating more interop >>problems (if implementations behave differently for >>the different encodings). >> >> > >I'd like to clarify the extent of the simplification that you are >proposing in people's implementations. You are suggesting replacing a line >of code that says: > > if ( (rcc==1) && (ncc == 0 || ncc == 1) ) > >with a line of code that says > > if ( (rcc==1) && (ncc == 1) ) > >Why is this a big deal? > > > >>So, rather than make things more complicated by >>modifying an accepted rule (RCC=1 requires NCC>1), >>retaining two encodings for the same signal, and >>adding notes to attempt to explain the interworking >>options, it is much easier to correct the example. >> >> > >Again, I think you are misrepresenting what the authors are doing. In >their view they are not changing the rules, but correcting an editorial >mistake. In their opinion the example is already correct. > >Now, I don't want to start any voting here, but I see several people who >are expressing support for the ideas in >draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying >make the change the other way. If I was to judge consensus today, it is >pretty clear how I would call it. > >Let's hear some opinions from other people who have an interest in this >work. > >Thanks, >Adrian > > > > >>This is good engineering practice, in my view. >> >>Regards, >>Ben >> >> >> >>>-----Original Message----- >>>From: Richard Rabbat [mailto:richard@us.fujitsu.com] >>>Sent: Tuesday, August 30, 2005 3:58 PM >>>To: Mack-Crane, T. Benjamin >>>Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org >>>Subject: Re: Final draft of response to the OIF >>> >>>Ben, >>>Adrian's final draft of the response is most inclusive. From what you >>>said earlier, it seems that you've already coded it in one way >>>(whichever) but are accepting both sets of values for NCC & >>>RCC (both 1 or 0). >>>Is there an engineering problem with the text of the response besides >>>that you would be able to remove those couple of lines of >>>code? if so, >>>we should solve it. >>>Richard. >>> >>> >>>Mack-Crane, T. Benjamin wrote: >>> >>> >>> >>>>Hi Huub, >>>> >>>>See in-line below. >>>> >>>>Regards, >>>>Ben >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] >>>>>Sent: Friday, August 26, 2005 10:56 AM >>>>>To: Mack-Crane, T. Benjamin >>>>>Cc: Adrian Farrel; ccamp@ops.ietf.org >>>>>Subject: Re: Final draft of response to the OIF >>>>> >>>>>Hello Ben, >>>>> >>>>>You wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>I proposed a simple (and I think technically sound) solution to >>>>>>item #1 and saw no objections, however the answer has not changed. >>>>>> >>>>>>I do not understand the reason for different encodings for >>>>>>VC-4 and STS-3c SPE. I think they should be the same, unless >>>>>>there is a technical need to distinguish them. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>If there is agreement that they should be the same, we should >>>>>also look at higher order contiguous concatenated signals: >>>>>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c >>>>>STS-768c == VC-4-256c >>>>> >>>>> >>>>> >>>>> >>>>These signals are already encoded the same way (for instance see >>>>examples 3 and 9 in RFC 3946). >>>> >>>> >>>> >>>> >>>> >>>>>>I also do not understand the RCC=1 NCC=1 encoding, since the rule >>>>>>contained in the current RFC actually makes more sense. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>However indicating the number of signals concatenated in NCC >>>>>makes your first objective impossible: STS-3Xc == VC-4-Xc >>>>>so there will always be a difference of a factor 3 between >>>>>STS and VC-4 encoding >>>>> >>>>> >>>>> >>>>> >>>>All the encodings of contiguous concatenated signals use VC-4 >>>>(STS-3c SPE) as the base, so the NCC values are the same. This >>>>was done to align SONET and SDH encodings. >>>> >>>> >>>> >>>> >>>> >>>>>>If there is >>>>>>only >>>>>>one signal element, there is no contiguous concatenation, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>by definition. >>>>> >>>>>In fact a single signal is always contiguous concatenated ;-) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>So I fail to see the usefulness of these encodings. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>NCC = 1 would normally not occur, so it could be used for >>>>>this specific case of SONET signals transported in an >>>>>SDH world, or SDH signals transported in SONET land. >>>>>And if these signals would not cross borders the value >>>>>NCC > 1 can be used. >>>>> >>>>> >>>>> >>>>> >>>>The SDH and SONET encodings have been aligned in all cases >>>>except this one (VC-4, STS-3c SPE). So these should also >>>>be aligned. >>>> >>>> >>>> >>>> >>>> >>>>>>Regards, >>>>>>Ben >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Cheers, Huub. >>>>> >>>>>-- >>>>>================================================================ >>>>> 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 >>>>============================================================ >>>> >>>> >>>> >>>> >>>> >>============================================================ >>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 Wed Aug 31 00:59:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAKgm-0005VC-F5 for ccamp-archive@megatron.ietf.org; Wed, 31 Aug 2005 00:59:13 -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 AAA01863 for ; Wed, 31 Aug 2005 00:59:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAKi3-0000pS-Dh for ccamp-archive@ietf.org; Wed, 31 Aug 2005 01:00:53 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAKXc-0009uL-6j for ccamp-data@psg.com; Wed, 31 Aug 2005 04:49:40 +0000 Received: from [63.118.39.27] (helo=mdmxm02.ciena.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAKXW-0009lq-UZ for ccamp@ops.ietf.org; Wed, 31 Aug 2005 04:49:35 +0000 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: Wed, 31 Aug 2005 00:47:40 -0400 Message-ID: <0901D1988E815341A0103206A834DA07614896@mdmxm02.ciena.com> Thread-Topic: Final draft of response to the OIF thread-index: AcWtuClga8yGbSLuR6uk3RqoONxALAAK8TFw From: "Ong, Lyndon" To: "Adrian Farrel" , "Mack-Crane, T. Benjamin" , "Richard Rabbat" Cc: "Huub van Helvoort" , 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: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: quoted-printable Hi Adrian, I have some sympathy with Ben's comments, it seems like a single value would simplify configuration the most. We were able to work around the problem at the OIF test, but the number of vendors was limited and it did cause some initial headaches. Short of a single value, maybe a slight rewording of your text would make a stronger recommendation that implementations be able to accept both, e.g.: " Note 3: Following these rules, when requesting a VC-4 signal, the RCC and the NCC values must be set to 0 whereas for an STS-3c SPE signal, the RCC and the NCC values must be set 1. However, if local conditions allow (e.g., no differentiation of VC-4 vs. STS-3c format is required), then the requesting upstream node MAY set the RCC and NCC values to either SDH or SONET settings without impacting the function, and the downstream node SHOULD accept either of the requested values. If the received value cannot be supported, the receiver downstream node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively). " Cheers, Lyndon -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, August 30, 2005 4:12 PM To: Mack-Crane, T. Benjamin; Richard Rabbat Cc: Huub van Helvoort; ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF Hi Ben, > A long time ago an agreement was reached to unify the SDH and SONET=20 > encodings, since carriers did not want to manage unnecessary=20 > differences. Good motivation. Presume that here you are not really talking about the SDH and SONET encoding, but rather the control plane encodings. > What implementations have done as a result of the bad example in RFC=20 > 3946 is unfortunate, and leads to interop problems -- and thus the=20 > item from the OIF. Whether the example is bad or not clearly depends on the encoding rules specified in the RFC. With the clarification from the Editors, it would appear that the example is good. Now, you can object to the encoding rules, but that doesn't mean that the example is bad. I have not heard of any interop problems. Centrainly the message from the OIF did not report any such problems. My understanding is that there were no interope problems, merely a question about intended encodings. With the rule of "liberal in what you receive" I would not expect any interop problems. > This is our opportunity to fix the example and > removed the problem (and then folks can simplify their=20 > implementations). If the difference remains, there will be=20 > opportunity for creating more interop problems (if implementations=20 > behave differently for the different encodings). I'd like to clarify the extent of the simplification that you are proposing in people's implementations. You are suggesting replacing a line of code that says: if ( (rcc=3D=3D1) && (ncc =3D=3D 0 || ncc =3D=3D 1) ) with a line of code that says if ( (rcc=3D=3D1) && (ncc =3D=3D 1) ) Why is this a big deal? > So, rather than make things more complicated by modifying an accepted=20 > rule (RCC=3D1 requires NCC>1), retaining two encodings for the same=20 > signal, and adding notes to attempt to explain the interworking=20 > options, it is much easier to correct the example. Again, I think you are misrepresenting what the authors are doing. In their view they are not changing the rules, but correcting an editorial mistake. In their opinion the example is already correct. Now, I don't want to start any voting here, but I see several people who are expressing support for the ideas in draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying make the change the other way. If I was to judge consensus today, it is pretty clear how I would call it. Let's hear some opinions from other people who have an interest in this work. Thanks, Adrian > > This is good engineering practice, in my view. > > Regards, > Ben > > > -----Original Message----- > > From: Richard Rabbat [mailto:richard@us.fujitsu.com] > > Sent: Tuesday, August 30, 2005 3:58 PM > > To: Mack-Crane, T. Benjamin > > Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org > > Subject: Re: Final draft of response to the OIF > > > > Ben, > > Adrian's final draft of the response is most inclusive. From what=20 > > you said earlier, it seems that you've already coded it in one way > > (whichever) but are accepting both sets of values for NCC & RCC=20 > > (both 1 or 0). > > Is there an engineering problem with the text of the response=20 > > besides that you would be able to remove those couple of lines of=20 > > code? if so, we should solve it. > > Richard. > > > > > > Mack-Crane, T. Benjamin wrote: > > > > >Hi Huub, > > > > > >See in-line below. > > > > > >Regards, > > >Ben > > > > > > > > > > > >>-----Original Message----- > > >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > > >>Sent: Friday, August 26, 2005 10:56 AM > > >>To: Mack-Crane, T. Benjamin > > >>Cc: Adrian Farrel; ccamp@ops.ietf.org > > >>Subject: Re: Final draft of response to the OIF > > >> > > >>Hello Ben, > > >> > > >>You wrote: > > >> > > >> > > >> > > >>>I proposed a simple (and I think technically sound) solution to=20 > > >>>item #1 and saw no objections, however the answer has not changed. > > >>> > > >>>I do not understand the reason for different encodings for > > >>>VC-4 and STS-3c SPE. I think they should be the same, unless=20 > > >>>there is a technical need to distinguish them. > > >>> > > >>> > > >>If there is agreement that they should be the same, we should also > > >>look at higher order contiguous concatenated signals: > > >>i.e. STS-12c =3D=3D VC-4-4c, STS-48c =3D=3D VC-4-16c, STS-192c = =3D=3D VC-4-64c > > >>STS-768c =3D=3D VC-4-256c > > >> > > >> > > > > > >These signals are already encoded the same way (for instance see=20 > > >examples 3 and 9 in RFC 3946). > > > > > > > > > > > >>>I also do not understand the RCC=3D1 NCC=3D1 encoding, since the = rule > > >>>contained in the current RFC actually makes more sense. > > >>> > > >>> > > >>However indicating the number of signals concatenated in NCC makes > > >>your first objective impossible: STS-3Xc =3D=3D VC-4-Xc so there = will=20 > > >>always be a difference of a factor 3 between STS and VC-4 encoding > > >> > > >> > > > > > >All the encodings of contiguous concatenated signals use VC-4=20 > > >(STS-3c SPE) as the base, so the NCC values are the same. This was > > >done to align SONET and SDH encodings. > > > > > > > > > > > >>>If there is > > >>>only > > >>>one signal element, there is no contiguous concatenation, > > >>> > > >>> > > >>by definition. > > >> > > >>In fact a single signal is always contiguous concatenated ;-) > > >> > > >> > > >> > > >>>So I fail to see the usefulness of these encodings. > > >>> > > >>> > > >>NCC =3D 1 would normally not occur, so it could be used for this=20 > > >>specific case of SONET signals transported in an SDH world, or SDH > > >>signals transported in SONET land. > > >>And if these signals would not cross borders the value NCC > 1 can > > >>be used. > > >> > > >> > > > > > >The SDH and SONET encodings have been aligned in all cases except=20 > > >this one (VC-4, STS-3c SPE). So these should also be aligned. > > > > > > > > > > > >>>Regards, > > >>>Ben > > >>> > > >>> > > >>Cheers, Huub. > > >> > > >>-- > > = >>=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=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 > > >> http://members.chello.nl/hhelvoort/ > > = >>=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=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 > > >>Always remember that you are unique...just like everyone else... > > >> > > >> > > >> > > = >=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >The information contained in this message may be privileged and=20 > > >confidential and protected from disclosure. If the reader of this=20 > > >message is not the intended recipient, or an employee or agent=20 > > >responsible for delivering this message to the intended recipient,=20 > > >you are hereby notified that any reproduction, dissemination or=20 > > >distribution of this communication is strictly prohibited. If you=20 > > >have received this communication in error, please notify us=20 > > >immediately by replying to the message and deleting it from your=20 > > >computer. Thank you. Tellabs=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=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=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=3D=3D=3D=3D=3D=3D > The information contained in this message may be privileged and=20 > confidential and protected from disclosure. If the reader of this=20 > message is not the intended recipient, or an employee or agent=20 > responsible for delivering this message to the intended recipient, you > are hereby notified that any reproduction, dissemination or=20 > distribution of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by=20 > replying to the message and deleting it from your computer. Thank you. > Tellabs = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > From owner-ccamp@ops.ietf.org Wed Aug 31 08:15:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EARUg-0007Es-0f for ccamp-archive@megatron.ietf.org; Wed, 31 Aug 2005 08:15:08 -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 IAA17008 for ; Wed, 31 Aug 2005 08:15:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EARWO-0003yc-DM for ccamp-archive@ietf.org; Wed, 31 Aug 2005 08:16:54 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EARK4-000FIP-Jc for ccamp-data@psg.com; Wed, 31 Aug 2005 12:04:08 +0000 Received: from [192.11.226.163] (helo=hoemail2.lucent.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EARK1-000FHz-Cb for ccamp@ops.ietf.org; Wed, 31 Aug 2005 12:04:05 +0000 Received: from nbgif1.de.lucent.com (h135-246-31-82.lucent.com [135.246.31.82]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7VC3xJP009125; Wed, 31 Aug 2005 07:04:00 -0500 (CDT) Received: from slds1.de.lucent.com (slds1.de.lucent.com [135.246.29.35]) by nbgif1.de.lucent.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7VC3xB00384; Wed, 31 Aug 2005 14:03:59 +0200 (MEST) Received: from lucent.com (WROTHKEGEL-1 [135.246.90.29]) by slds1.de.lucent.com (8.11.7p1+Sun/8.8.5) with ESMTP id j7VC3wb14652; Wed, 31 Aug 2005 14:03:58 +0200 (MEST) Message-ID: <43159CB2.1030900@lucent.com> Date: Wed, 31 Aug 2005 14:04:02 +0200 From: WALTER ROTHKEGEL Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: Adrian Farrel CC: "Mack-Crane, T. Benjamin" , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF References: <0f6601c5adb8$3967d160$c5919ed9@Puppy> Content-Type: text/plain; charset=us-ascii 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: bfe538a859d88717fa3c8a6377d62f90 Content-Transfer-Encoding: 7bit Adrian, I support Ben's arguments. I do not see any reason which would require the two different encodings. Regards Walter On 31.08.2005 01:11, Adrian Farrel wrote: > Hi Ben, > > >>A long time ago an agreement was reached to unify >>the SDH and SONET encodings, since carriers did not >>want to manage unnecessary differences. > > > Good motivation. > > Presume that here you are not really talking about the SDH and SONET > encoding, but rather the control plane encodings. > > >>What implementations have done as a result of the >>bad example in RFC 3946 is unfortunate, and leads to >>interop problems -- and thus the item from the OIF. > > > Whether the example is bad or not clearly depends on the encoding rules > specified in the RFC. > With the clarification from the Editors, it would appear that the example > is good. Now, you can object to the encoding rules, but that doesn't mean > that the example is bad. > > I have not heard of any interop problems. Centrainly the message from the > OIF did not report any such problems. My understanding is that there were > no interope problems, merely a question about intended encodings. With the > rule of "liberal in what you receive" I would not expect any interop > problems. > > > This is our opportunity to fix the example and > >>removed the problem (and then folks can simplify >>their implementations). If the difference remains, >>there will be opportunity for creating more interop >>problems (if implementations behave differently for >>the different encodings). > > > I'd like to clarify the extent of the simplification that you are > proposing in people's implementations. You are suggesting replacing a line > of code that says: > > if ( (rcc==1) && (ncc == 0 || ncc == 1) ) > > with a line of code that says > > if ( (rcc==1) && (ncc == 1) ) > > Why is this a big deal? > > >>So, rather than make things more complicated by >>modifying an accepted rule (RCC=1 requires NCC>1), >>retaining two encodings for the same signal, and >>adding notes to attempt to explain the interworking >>options, it is much easier to correct the example. > > > Again, I think you are misrepresenting what the authors are doing. In > their view they are not changing the rules, but correcting an editorial > mistake. In their opinion the example is already correct. > > Now, I don't want to start any voting here, but I see several people who > are expressing support for the ideas in > draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying > make the change the other way. If I was to judge consensus today, it is > pretty clear how I would call it. > > Let's hear some opinions from other people who have an interest in this > work. > > Thanks, > Adrian > > > >>This is good engineering practice, in my view. >> >>Regards, >>Ben >> >> >>>-----Original Message----- >>>From: Richard Rabbat [mailto:richard@us.fujitsu.com] >>>Sent: Tuesday, August 30, 2005 3:58 PM >>>To: Mack-Crane, T. Benjamin >>>Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org >>>Subject: Re: Final draft of response to the OIF >>> >>>Ben, >>>Adrian's final draft of the response is most inclusive. From what you >>>said earlier, it seems that you've already coded it in one way >>>(whichever) but are accepting both sets of values for NCC & >>>RCC (both 1 or 0). >>>Is there an engineering problem with the text of the response besides >>>that you would be able to remove those couple of lines of >>>code? if so, >>>we should solve it. >>>Richard. >>> >>> >>>Mack-Crane, T. Benjamin wrote: >>> >>> >>>>Hi Huub, >>>> >>>>See in-line below. >>>> >>>>Regards, >>>>Ben >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] >>>>>Sent: Friday, August 26, 2005 10:56 AM >>>>>To: Mack-Crane, T. Benjamin >>>>>Cc: Adrian Farrel; ccamp@ops.ietf.org >>>>>Subject: Re: Final draft of response to the OIF >>>>> >>>>>Hello Ben, >>>>> >>>>>You wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>I proposed a simple (and I think technically sound) solution to >>>>>>item #1 and saw no objections, however the answer has not changed. >>>>>> >>>>>>I do not understand the reason for different encodings for >>>>>>VC-4 and STS-3c SPE. I think they should be the same, unless >>>>>>there is a technical need to distinguish them. >>>>>> >>>>>> >>>>> >>>>>If there is agreement that they should be the same, we should >>>>>also look at higher order contiguous concatenated signals: >>>>>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c >>>>>STS-768c == VC-4-256c >>>>> >>>>> >>>> >>>>These signals are already encoded the same way (for instance see >>>>examples 3 and 9 in RFC 3946). >>>> >>>> >>>> >>>> >>>>>>I also do not understand the RCC=1 NCC=1 encoding, since the rule >>>>>>contained in the current RFC actually makes more sense. >>>>>> >>>>>> >>>>> >>>>>However indicating the number of signals concatenated in NCC >>>>>makes your first objective impossible: STS-3Xc == VC-4-Xc >>>>>so there will always be a difference of a factor 3 between >>>>>STS and VC-4 encoding >>>>> >>>>> >>>> >>>>All the encodings of contiguous concatenated signals use VC-4 >>>>(STS-3c SPE) as the base, so the NCC values are the same. This >>>>was done to align SONET and SDH encodings. >>>> >>>> >>>> >>>> >>>>>>If there is >>>>>>only >>>>>>one signal element, there is no contiguous concatenation, >>>>>> >>>>>> >>>>> >>>>>by definition. >>>>> >>>>>In fact a single signal is always contiguous concatenated ;-) >>>>> >>>>> >>>>> >>>>> >>>>>>So I fail to see the usefulness of these encodings. >>>>>> >>>>>> >>>>> >>>>>NCC = 1 would normally not occur, so it could be used for >>>>>this specific case of SONET signals transported in an >>>>>SDH world, or SDH signals transported in SONET land. >>>>>And if these signals would not cross borders the value >>>>>NCC > 1 can be used. >>>>> >>>>> >>>> >>>>The SDH and SONET encodings have been aligned in all cases >>>>except this one (VC-4, STS-3c SPE). So these should also >>>>be aligned. >>>> >>>> >>>> >>>> >>>>>>Regards, >>>>>>Ben >>>>>> >>>>>> >>>>> >>>>>Cheers, Huub. >>>>> >>>>>-- >>>>>================================================================ >>>>> 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 >>>>============================================================ >>>> >>>> >>>> >>> >>============================================================ >>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 >>============================================================ >> >> > > > -- ________________________________________________________________________ Walter Rothkegel, Lucent Technologies Network Systems GmbH, Dept. O-SE Thurn-und-Taxis-Str. 10-14, 90411 Nuernberg, Germany Phone: +49 911 526-4084 Fax: +49 911 526-6299 mailto:wrothkegel@lucent.com From owner-ccamp@ops.ietf.org Wed Aug 31 11:44:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAUlD-0001gC-2G for ccamp-archive@megatron.ietf.org; Wed, 31 Aug 2005 11:44: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 LAA27415 for ; Wed, 31 Aug 2005 11:44:20 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAUmt-0000tH-GI for ccamp-archive@ietf.org; Wed, 31 Aug 2005 11:46:13 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAUZZ-0003Pm-B6 for ccamp-data@psg.com; Wed, 31 Aug 2005 15:32:21 +0000 Received: from [47.129.242.57] (helo=zcars04f.nortelnetworks.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAUZX-0003PP-3m for ccamp@ops.ietf.org; Wed, 31 Aug 2005 15:32:19 +0000 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j7VFWEf00747 for ; Wed, 31 Aug 2005 11:32:14 -0400 (EDT) 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: Wed, 31 Aug 2005 11:32:00 -0400 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A0112242E@zcarhxm0.corp.nortel.com> Thread-Topic: Final draft of response to the OIF Thread-Index: AcWtuJvkIbjLmQP6T8S0ra1KYZUpkQAhzlpw From: "Stephen Shew" To: X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.2 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: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable I prefer Ben's solution of having one encoding for STS-3c and VC-4. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, August 30, 2005 19:12 > To: Mack-Crane, T. Benjamin; Richard Rabbat > Cc: Huub van Helvoort; ccamp@ops.ietf.org > Subject: Re: Final draft of response to the OIF >=20 >=20 > Hi Ben, >=20 > > A long time ago an agreement was reached to unify > > the SDH and SONET encodings, since carriers did not > > want to manage unnecessary differences. >=20 > Good motivation. >=20 > Presume that here you are not really talking about the SDH=20 > and SONET encoding, but rather the control plane encodings. >=20 > > What implementations have done as a result of the > > bad example in RFC 3946 is unfortunate, and leads to > > interop problems -- and thus the item from the OIF. >=20 > Whether the example is bad or not clearly depends on the=20 > encoding rules specified in the RFC. With the clarification=20 > from the Editors, it would appear that the example is good.=20 > Now, you can object to the encoding rules, but that doesn't=20 > mean that the example is bad. >=20 > I have not heard of any interop problems. Centrainly the=20 > message from the OIF did not report any such problems. My=20 > understanding is that there were no interope problems, merely=20 > a question about intended encodings. With the rule of=20 > "liberal in what you receive" I would not expect any interop problems. >=20 > > This is our opportunity to fix the example and > > removed the problem (and then folks can simplify > > their implementations). If the difference remains, > > there will be opportunity for creating more interop > > problems (if implementations behave differently for > > the different encodings). >=20 > I'd like to clarify the extent of the simplification that you=20 > are proposing in people's implementations. You are suggesting=20 > replacing a line of code that says: >=20 > if ( (rcc=3D=3D1) && (ncc =3D=3D 0 || ncc =3D=3D 1) ) >=20 > with a line of code that says >=20 > if ( (rcc=3D=3D1) && (ncc =3D=3D 1) ) >=20 > Why is this a big deal? >=20 > > So, rather than make things more complicated by > > modifying an accepted rule (RCC=3D1 requires NCC>1), > > retaining two encodings for the same signal, and > > adding notes to attempt to explain the interworking > > options, it is much easier to correct the example. >=20 > Again, I think you are misrepresenting what the authors are=20 > doing. In their view they are not changing the rules, but=20 > correcting an editorial mistake. In their opinion the example=20 > is already correct. >=20 > Now, I don't want to start any voting here, but I see several=20 > people who are expressing support for the ideas in=20 > draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one=20 > person saying make the change the other way. If I was to=20 > judge consensus today, it is pretty clear how I would call it. >=20 > Let's hear some opinions from other people who have an=20 > interest in this work. >=20 > Thanks, > Adrian From owner-ccamp@ops.ietf.org Wed Aug 31 13:49:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAWiG-0004r8-QU for ccamp-archive@megatron.ietf.org; Wed, 31 Aug 2005 13:49: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 NAA02814 for ; Wed, 31 Aug 2005 13:49:27 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAWjz-0004OH-Hk for ccamp-archive@ietf.org; Wed, 31 Aug 2005 13:51:20 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAWas-00046I-Tz for ccamp-data@psg.com; Wed, 31 Aug 2005 17:41:50 +0000 Received: from [80.168.70.143] (helo=relay3.mail.uk.clara.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAWap-000461-6p for ccamp@ops.ietf.org; Wed, 31 Aug 2005 17:41:47 +0000 Received: from du-069-0057.access.clara.net ([217.158.132.57] helo=Puppy) by relay3.mail.uk.clara.net with smtp (Exim 4.46) id 1EAWan-000LUX-FL for ccamp@ops.ietf.org; Wed, 31 Aug 2005 18:41:46 +0100 Message-ID: <007a01c5ae53$a3141c90$48849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: ID Tracker State Update Notice: draft-ietf-ccamp-gmpls-alarm-spec Date: Wed, 31 Aug 2005 18:39:21 +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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Hi, The AD has looked at this draft and made some suggestions. I will work with the Editor to get a new version out quickly. Please look at the AD's comments: - to check that you agree - to learn what you should be doing in your I-Ds. Cheers, Adrian ----- Original Message ----- From: "The IESG" To: ; Sent: Wednesday, August 31, 2005 2:35 AM Subject: ID Tracker State Update Notice: draft-ietf-ccamp-gmpls-alarm-spec > 'State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Alex Zinin' > ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11679&rfc_flag=0 > > > From owner-ccamp@ops.ietf.org Wed Aug 31 15:05:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAXtp-0002RB-QD for ccamp-archive@megatron.ietf.org; Wed, 31 Aug 2005 15:05: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 PAA06413 for ; Wed, 31 Aug 2005 15:05:27 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAXvW-0006ay-HF for ccamp-archive@ietf.org; Wed, 31 Aug 2005 15:07:21 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAXn0-000KKw-9f for ccamp-data@psg.com; Wed, 31 Aug 2005 18:58:26 +0000 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAXmv-000KKN-UX for ccamp@ops.ietf.org; Wed, 31 Aug 2005 18:58:22 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 31 Aug 2005 19:10:59 +0000 X-SBRS: None X-IronPort-AV: i="3.96,158,1122854400"; d="scan'208"; a="27434113:sNHT33310412" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Aug 2005 13:57:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Final draft of response to the OIF Date: Wed, 31 Aug 2005 13:55:21 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWtt+nRqt2VKERdSkWGpR8I1f1/oQAosaQg From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" , "Richard Rabbat" Cc: "Huub van Helvoort" , X-OriginalArrivalTime: 31 Aug 2005 18:57:41.0189 (UTC) FILETIME=[DCF0D750:01C5AE5D] Content-Transfer-Encoding: 7bit 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: 4515df9441674711565101d9d5c4f63f Content-Transfer-Encoding: 7bit Hi Adrian, > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, August 30, 2005 6:12 PM > To: Mack-Crane, T. Benjamin; Richard Rabbat > Cc: Huub van Helvoort; ccamp@ops.ietf.org > Subject: Re: Final draft of response to the OIF > > Hi Ben, > > > A long time ago an agreement was reached to unify > > the SDH and SONET encodings, since carriers did not > > want to manage unnecessary differences. > > Good motivation. > > Presume that here you are not really talking about the SDH and SONET > encoding, but rather the control plane encodings. Yup. > > > What implementations have done as a result of the > > bad example in RFC 3946 is unfortunate, and leads to > > interop problems -- and thus the item from the OIF. > > Whether the example is bad or not clearly depends on the > encoding rules > specified in the RFC. > With the clarification from the Editors, it would appear that > the example > is good. Now, you can object to the encoding rules, but that > doesn't mean > that the example is bad. 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. > > I have not heard of any interop problems. Centrainly the > message from the > OIF did not report any such problems. My understanding is > that there were > no interope problems, merely a question about intended > encodings. With the > rule of "liberal in what you receive" I would not expect any interop > problems. The problem was that both encodings were in use and some were not liberal in what they received. That was easily fixed. If only one encoding was specified, there would have been no problem. > > > This is our opportunity to fix the example and > > removed the problem (and then folks can simplify > > their implementations). If the difference remains, > > there will be opportunity for creating more interop > > problems (if implementations behave differently for > > the different encodings). > > I'd like to clarify the extent of the simplification that you are > proposing in people's implementations. You are suggesting > replacing a line > of code that says: > > if ( (rcc==1) && (ncc == 0 || ncc == 1) ) > > with a line of code that says > > if ( (rcc==1) && (ncc == 1) ) > > Why is this a big deal? Your first line of code is incorrect (uh-oh, more interop problems...;-) But, what I am concerned about is the possibility of code like this: if (rcc==1 && ncc==1) {do behavior A} if (rcc==0 && ncc==0) {do behavior B} Which has the potential for creating diversity in behavior where it should not exist. Having only one encoding greatly reduces the chances of this... > > > So, rather than make things more complicated by > > modifying an accepted rule (RCC=1 requires NCC>1), > > retaining two encodings for the same signal, and > > adding notes to attempt to explain the interworking > > options, it is much easier to correct the example. > > Again, I think you are misrepresenting what the authors are doing. In > their view they are not changing the rules, but correcting an > editorial > mistake. In their opinion the example is already correct. Changing the encoding in the example could be considered editorial, as it's just an example in an annex. Changing the rule RCC=1 implies NCC>1 to RCC=1 implies NCC>0 is a semantic change (which in my view doesn't make sense, unless, as Huub suggested, we consider all elementary signals to be contiguous concatenations of 1 element and then RCC=1 always...:-o) > > Now, I don't want to start any voting here, but I see several > people who > are expressing support for the ideas in > draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one > person saying > make the change the other way. If I was to judge consensus > today, it is > pretty clear how I would call it. > > Let's hear some opinions from other people who have an > interest in this > work. > > Thanks, > Adrian > > > > > > This is good engineering practice, in my view. > > > > Regards, > > Ben > > > > > -----Original Message----- > > > From: Richard Rabbat [mailto:richard@us.fujitsu.com] > > > Sent: Tuesday, August 30, 2005 3:58 PM > > > To: Mack-Crane, T. Benjamin > > > Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org > > > Subject: Re: Final draft of response to the OIF > > > > > > Ben, > > > Adrian's final draft of the response is most inclusive. > From what you > > > said earlier, it seems that you've already coded it in one way > > > (whichever) but are accepting both sets of values for NCC & > > > RCC (both 1 or 0). > > > Is there an engineering problem with the text of the > response besides > > > that you would be able to remove those couple of lines of > > > code? if so, > > > we should solve it. > > > Richard. > > > > > > > > > Mack-Crane, T. Benjamin wrote: > > > > > > >Hi Huub, > > > > > > > >See in-line below. > > > > > > > >Regards, > > > >Ben > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > > > >>Sent: Friday, August 26, 2005 10:56 AM > > > >>To: Mack-Crane, T. Benjamin > > > >>Cc: Adrian Farrel; ccamp@ops.ietf.org > > > >>Subject: Re: Final draft of response to the OIF > > > >> > > > >>Hello Ben, > > > >> > > > >>You wrote: > > > >> > > > >> > > > >> > > > >>>I proposed a simple (and I think technically sound) solution to > > > >>>item #1 and saw no objections, however the answer has > not changed. > > > >>> > > > >>>I do not understand the reason for different encodings for > > > >>>VC-4 and STS-3c SPE. I think they should be the same, unless > > > >>>there is a technical need to distinguish them. > > > >>> > > > >>> > > > >>If there is agreement that they should be the same, we should > > > >>also look at higher order contiguous concatenated signals: > > > >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c > == VC-4-64c > > > >>STS-768c == VC-4-256c > > > >> > > > >> > > > > > > > >These signals are already encoded the same way (for instance see > > > >examples 3 and 9 in RFC 3946). > > > > > > > > > > > > > > > >>>I also do not understand the RCC=1 NCC=1 encoding, > since the rule > > > >>>contained in the current RFC actually makes more sense. > > > >>> > > > >>> > > > >>However indicating the number of signals concatenated in NCC > > > >>makes your first objective impossible: STS-3Xc == VC-4-Xc > > > >>so there will always be a difference of a factor 3 between > > > >>STS and VC-4 encoding > > > >> > > > >> > > > > > > > >All the encodings of contiguous concatenated signals use VC-4 > > > >(STS-3c SPE) as the base, so the NCC values are the same. This > > > >was done to align SONET and SDH encodings. > > > > > > > > > > > > > > > >>>If there is > > > >>>only > > > >>>one signal element, there is no contiguous concatenation, > > > >>> > > > >>> > > > >>by definition. > > > >> > > > >>In fact a single signal is always contiguous concatenated ;-) > > > >> > > > >> > > > >> > > > >>>So I fail to see the usefulness of these encodings. > > > >>> > > > >>> > > > >>NCC = 1 would normally not occur, so it could be used for > > > >>this specific case of SONET signals transported in an > > > >>SDH world, or SDH signals transported in SONET land. > > > >>And if these signals would not cross borders the value > > > >>NCC > 1 can be used. > > > >> > > > >> > > > > > > > >The SDH and SONET encodings have been aligned in all cases > > > >except this one (VC-4, STS-3c SPE). So these should also > > > >be aligned. > > > > > > > > > > > > > > > >>>Regards, > > > >>>Ben > > > >>> > > > >>> > > > >>Cheers, Huub. > > > >> > > > >>-- > > > >>================================================================ > > > >> 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 > > > >============================================================ > > > > > > > > > > > > > > > > > ============================================================ > > 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 > > ============================================================ > > > > > ============================================================ 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 Wed Aug 31 15:43:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYUc-0005Fm-DU for ccamp-archive@megatron.ietf.org; Wed, 31 Aug 2005 15:43:30 -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 PAA09234 for ; Wed, 31 Aug 2005 15:43:28 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAYWP-0007gV-DJ for ccamp-archive@ietf.org; Wed, 31 Aug 2005 15:45:22 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAYOn-0002k3-93 for ccamp-data@psg.com; Wed, 31 Aug 2005 19:37:29 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAYOm-0002je-B8; Wed, 31 Aug 2005 19:37:28 +0000 Message-ID: <43160704.3030008@psg.com> Date: Wed, 31 Aug 2005 21:37:40 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 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 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=-5.9 required=5.0 tests=ALL_TRUSTED,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: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit 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 From owner-ccamp@ops.ietf.org Wed Aug 31 16:02:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAYnL-0001RJ-FT for ccamp-archive@megatron.ietf.org; Wed, 31 Aug 2005 16:02: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 QAA11211 for ; Wed, 31 Aug 2005 16:02:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAYp8-0000JB-OX for ccamp-archive@ietf.org; Wed, 31 Aug 2005 16:04:44 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAYio-0007Nf-2f for ccamp-data@psg.com; Wed, 31 Aug 2005 19:58:10 +0000 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAYim-0007NJ-D7 for ccamp@ops.ietf.org; Wed, 31 Aug 2005 19:58:08 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 31 Aug 2005 20:11:27 +0000 X-SBRS: None X-IronPort-AV: i="3.96,158,1122854400"; d="scan'208"; a="27439087:sNHT24600580" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Wed, 31 Aug 2005 14:58:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Final draft of response to the OIF Date: Wed, 31 Aug 2005 14:55:48 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWuY3E1uV77LrzDTwKpcI+RgCvsnwAAYkdw From: "Mack-Crane, T. Benjamin" To: , Cc: "Adrian Farrel" , "Richard Rabbat" , "Huub van Helvoort" , X-OriginalArrivalTime: 31 Aug 2005 19:58:08.0061 (UTC) FILETIME=[4EB996D0:01C5AE66] Content-Transfer-Encoding: 7bit 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: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit 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 Wed Aug 31 16:36:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAZJU-0004yo-GU for ccamp-archive@megatron.ietf.org; Wed, 31 Aug 2005 16:36:05 -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 QAA13927 for ; Wed, 31 Aug 2005 16:36:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAZLI-0001cq-Um for ccamp-archive@ietf.org; Wed, 31 Aug 2005 16:37:57 -0400 Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAZEE-000Eaj-7H for ccamp-data@psg.com; Wed, 31 Aug 2005 20:30:38 +0000 Received: from localhost ([127.0.0.1]) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAZEB-000ERJ-CW; Wed, 31 Aug 2005 20:30:36 +0000 Message-ID: <43161377.4040804@psg.com> Date: Wed, 31 Aug 2005 22:30:47 +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.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mack-Crane, T. Benjamin" CC: dimitri.papadimitriou@alcatel.be, Adrian Farrel , Richard Rabbat , Huub van Helvoort , 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=-5.9 required=5.0 tests=ALL_TRUSTED,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: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit 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: Wed, 31 Aug 2005 20:31:41 +0000 Message-ID: <43161377.4040804@psg.com> Date: Wed, 31 Aug 2005 22:30:47 +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.8) Gecko/20050511 MIME-Version: 1.0 To: "Mack-Crane, T. Benjamin" CC: dimitri.papadimitriou@alcatel.be, 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=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 31 Aug 2005 19:58:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Final draft of response to the OIF Date: Wed, 31 Aug 2005 14:55:48 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWuY3E1uV77LrzDTwKpcI+RgCvsnwAAYkdw From: "Mack-Crane, T. Benjamin" To: , Cc: "Adrian Farrel" , "Richard Rabbat" , "Huub van Helvoort" , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" 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: Wed, 31 Aug 2005 19:37:50 +0000 Message-ID: <43160704.3030008@psg.com> Date: Wed, 31 Aug 2005 21:37:40 +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.8) Gecko/20050511 MIME-Version: 1.0 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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Aug 2005 19:00:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Final draft of response to the OIF Date: Wed, 31 Aug 2005 13:55:21 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWtt+nRqt2VKERdSkWGpR8I1f1/oQAosaQg From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" , "Richard Rabbat" Cc: "Huub van Helvoort" , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi Adrian, > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Tuesday, August 30, 2005 6:12 PM > To: Mack-Crane, T. Benjamin; Richard Rabbat > Cc: Huub van Helvoort; ccamp@ops.ietf.org > Subject: Re: Final draft of response to the OIF > > Hi Ben, > > > A long time ago an agreement was reached to unify > > the SDH and SONET encodings, since carriers did not > > want to manage unnecessary differences. > > Good motivation. > > Presume that here you are not really talking about the SDH and SONET > encoding, but rather the control plane encodings. Yup. > > > What implementations have done as a result of the > > bad example in RFC 3946 is unfortunate, and leads to > > interop problems -- and thus the item from the OIF. > > Whether the example is bad or not clearly depends on the > encoding rules > specified in the RFC. > With the clarification from the Editors, it would appear that > the example > is good. Now, you can object to the encoding rules, but that > doesn't mean > that the example is bad. 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. > > I have not heard of any interop problems. Centrainly the > message from the > OIF did not report any such problems. My understanding is > that there were > no interope problems, merely a question about intended > encodings. With the > rule of "liberal in what you receive" I would not expect any interop > problems. The problem was that both encodings were in use and some were not liberal in what they received. That was easily fixed. If only one encoding was specified, there would have been no problem. > > > This is our opportunity to fix the example and > > removed the problem (and then folks can simplify > > their implementations). If the difference remains, > > there will be opportunity for creating more interop > > problems (if implementations behave differently for > > the different encodings). > > I'd like to clarify the extent of the simplification that you are > proposing in people's implementations. You are suggesting > replacing a line > of code that says: > > if ( (rcc==1) && (ncc == 0 || ncc == 1) ) > > with a line of code that says > > if ( (rcc==1) && (ncc == 1) ) > > Why is this a big deal? Your first line of code is incorrect (uh-oh, more interop problems...;-) But, what I am concerned about is the possibility of code like this: if (rcc==1 && ncc==1) {do behavior A} if (rcc==0 && ncc==0) {do behavior B} Which has the potential for creating diversity in behavior where it should not exist. Having only one encoding greatly reduces the chances of this... > > > So, rather than make things more complicated by > > modifying an accepted rule (RCC=1 requires NCC>1), > > retaining two encodings for the same signal, and > > adding notes to attempt to explain the interworking > > options, it is much easier to correct the example. > > Again, I think you are misrepresenting what the authors are doing. In > their view they are not changing the rules, but correcting an > editorial > mistake. In their opinion the example is already correct. Changing the encoding in the example could be considered editorial, as it's just an example in an annex. Changing the rule RCC=1 implies NCC>1 to RCC=1 implies NCC>0 is a semantic change (which in my view doesn't make sense, unless, as Huub suggested, we consider all elementary signals to be contiguous concatenations of 1 element and then RCC=1 always...:-o) > > Now, I don't want to start any voting here, but I see several > people who > are expressing support for the ideas in > draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one > person saying > make the change the other way. If I was to judge consensus > today, it is > pretty clear how I would call it. > > Let's hear some opinions from other people who have an > interest in this > work. > > Thanks, > Adrian > > > > > > This is good engineering practice, in my view. > > > > Regards, > > Ben > > > > > -----Original Message----- > > > From: Richard Rabbat [mailto:richard@us.fujitsu.com] > > > Sent: Tuesday, August 30, 2005 3:58 PM > > > To: Mack-Crane, T. Benjamin > > > Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org > > > Subject: Re: Final draft of response to the OIF > > > > > > Ben, > > > Adrian's final draft of the response is most inclusive. > From what you > > > said earlier, it seems that you've already coded it in one way > > > (whichever) but are accepting both sets of values for NCC & > > > RCC (both 1 or 0). > > > Is there an engineering problem with the text of the > response besides > > > that you would be able to remove those couple of lines of > > > code? if so, > > > we should solve it. > > > Richard. > > > > > > > > > Mack-Crane, T. Benjamin wrote: > > > > > > >Hi Huub, > > > > > > > >See in-line below. > > > > > > > >Regards, > > > >Ben > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > > > >>Sent: Friday, August 26, 2005 10:56 AM > > > >>To: Mack-Crane, T. Benjamin > > > >>Cc: Adrian Farrel; ccamp@ops.ietf.org > > > >>Subject: Re: Final draft of response to the OIF > > > >> > > > >>Hello Ben, > > > >> > > > >>You wrote: > > > >> > > > >> > > > >> > > > >>>I proposed a simple (and I think technically sound) solution to > > > >>>item #1 and saw no objections, however the answer has > not changed. > > > >>> > > > >>>I do not understand the reason for different encodings for > > > >>>VC-4 and STS-3c SPE. I think they should be the same, unless > > > >>>there is a technical need to distinguish them. > > > >>> > > > >>> > > > >>If there is agreement that they should be the same, we should > > > >>also look at higher order contiguous concatenated signals: > > > >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c > == VC-4-64c > > > >>STS-768c == VC-4-256c > > > >> > > > >> > > > > > > > >These signals are already encoded the same way (for instance see > > > >examples 3 and 9 in RFC 3946). > > > > > > > > > > > > > > > >>>I also do not understand the RCC=1 NCC=1 encoding, > since the rule > > > >>>contained in the current RFC actually makes more sense. > > > >>> > > > >>> > > > >>However indicating the number of signals concatenated in NCC > > > >>makes your first objective impossible: STS-3Xc == VC-4-Xc > > > >>so there will always be a difference of a factor 3 between > > > >>STS and VC-4 encoding > > > >> > > > >> > > > > > > > >All the encodings of contiguous concatenated signals use VC-4 > > > >(STS-3c SPE) as the base, so the NCC values are the same. This > > > >was done to align SONET and SDH encodings. > > > > > > > > > > > > > > > >>>If there is > > > >>>only > > > >>>one signal element, there is no contiguous concatenation, > > > >>> > > > >>> > > > >>by definition. > > > >> > > > >>In fact a single signal is always contiguous concatenated ;-) > > > >> > > > >> > > > >> > > > >>>So I fail to see the usefulness of these encodings. > > > >>> > > > >>> > > > >>NCC = 1 would normally not occur, so it could be used for > > > >>this specific case of SONET signals transported in an > > > >>SDH world, or SDH signals transported in SONET land. > > > >>And if these signals would not cross borders the value > > > >>NCC > 1 can be used. > > > >> > > > >> > > > > > > > >The SDH and SONET encodings have been aligned in all cases > > > >except this one (VC-4, STS-3c SPE). So these should also > > > >be aligned. > > > > > > > > > > > > > > > >>>Regards, > > > >>>Ben > > > >>> > > > >>> > > > >>Cheers, Huub. > > > >> > > > >>-- > > > >>================================================================ > > > >> 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 > > > >============================================================ > > > > > > > > > > > > > > > > > ============================================================ > > 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 > > ============================================================ > > > > > ============================================================ 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: Wed, 31 Aug 2005 17:44:18 +0000 Message-ID: <007a01c5ae53$a3141c90$48849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: ID Tracker State Update Notice: draft-ietf-ccamp-gmpls-alarm-spec Date: Wed, 31 Aug 2005 18:39:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, The AD has looked at this draft and made some suggestions. I will work with the Editor to get a new version out quickly. Please look at the AD's comments: - to check that you agree - to learn what you should be doing in your I-Ds. Cheers, Adrian ----- Original Message ----- From: "The IESG" To: ; Sent: Wednesday, August 31, 2005 2:35 AM Subject: ID Tracker State Update Notice: draft-ietf-ccamp-gmpls-alarm-spec > 'State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Alex Zinin' > ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11679&rfc_flag=0 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Aug 2005 15:35:01 +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: Wed, 31 Aug 2005 11:32:00 -0400 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A0112242E@zcarhxm0.corp.nortel.com> Thread-Topic: Final draft of response to the OIF Thread-Index: AcWtuJvkIbjLmQP6T8S0ra1KYZUpkQAhzlpw From: "Stephen Shew" To: I prefer Ben's solution of having one encoding for STS-3c and VC-4. > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, August 30, 2005 19:12 > To: Mack-Crane, T. Benjamin; Richard Rabbat > Cc: Huub van Helvoort; ccamp@ops.ietf.org > Subject: Re: Final draft of response to the OIF >=20 >=20 > Hi Ben, >=20 > > A long time ago an agreement was reached to unify > > the SDH and SONET encodings, since carriers did not > > want to manage unnecessary differences. >=20 > Good motivation. >=20 > Presume that here you are not really talking about the SDH=20 > and SONET encoding, but rather the control plane encodings. >=20 > > What implementations have done as a result of the > > bad example in RFC 3946 is unfortunate, and leads to > > interop problems -- and thus the item from the OIF. >=20 > Whether the example is bad or not clearly depends on the=20 > encoding rules specified in the RFC. With the clarification=20 > from the Editors, it would appear that the example is good.=20 > Now, you can object to the encoding rules, but that doesn't=20 > mean that the example is bad. >=20 > I have not heard of any interop problems. Centrainly the=20 > message from the OIF did not report any such problems. My=20 > understanding is that there were no interope problems, merely=20 > a question about intended encodings. With the rule of=20 > "liberal in what you receive" I would not expect any interop problems. >=20 > > This is our opportunity to fix the example and > > removed the problem (and then folks can simplify > > their implementations). If the difference remains, > > there will be opportunity for creating more interop > > problems (if implementations behave differently for > > the different encodings). >=20 > I'd like to clarify the extent of the simplification that you=20 > are proposing in people's implementations. You are suggesting=20 > replacing a line of code that says: >=20 > if ( (rcc=3D=3D1) && (ncc =3D=3D 0 || ncc =3D=3D 1) ) >=20 > with a line of code that says >=20 > if ( (rcc=3D=3D1) && (ncc =3D=3D 1) ) >=20 > Why is this a big deal? >=20 > > So, rather than make things more complicated by > > modifying an accepted rule (RCC=3D1 requires NCC>1), > > retaining two encodings for the same signal, and > > adding notes to attempt to explain the interworking > > options, it is much easier to correct the example. >=20 > Again, I think you are misrepresenting what the authors are=20 > doing. In their view they are not changing the rules, but=20 > correcting an editorial mistake. In their opinion the example=20 > is already correct. >=20 > Now, I don't want to start any voting here, but I see several=20 > people who are expressing support for the ideas in=20 > draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one=20 > person saying make the change the other way. If I was to=20 > judge consensus today, it is pretty clear how I would call it. >=20 > Let's hear some opinions from other people who have an=20 > interest in this work. >=20 > Thanks, > Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Aug 2005 12:08:36 +0000 Message-ID: <43159CB2.1030900@lucent.com> Date: Wed, 31 Aug 2005 14:04:02 +0200 From: WALTER ROTHKEGEL Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) MIME-Version: 1.0 To: Adrian Farrel CC: "Mack-Crane, T. Benjamin" , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian, I support Ben's arguments. I do not see any reason which would require the two different encodings. Regards Walter On 31.08.2005 01:11, Adrian Farrel wrote: > Hi Ben, > > >>A long time ago an agreement was reached to unify >>the SDH and SONET encodings, since carriers did not >>want to manage unnecessary differences. > > > Good motivation. > > Presume that here you are not really talking about the SDH and SONET > encoding, but rather the control plane encodings. > > >>What implementations have done as a result of the >>bad example in RFC 3946 is unfortunate, and leads to >>interop problems -- and thus the item from the OIF. > > > Whether the example is bad or not clearly depends on the encoding rules > specified in the RFC. > With the clarification from the Editors, it would appear that the example > is good. Now, you can object to the encoding rules, but that doesn't mean > that the example is bad. > > I have not heard of any interop problems. Centrainly the message from the > OIF did not report any such problems. My understanding is that there were > no interope problems, merely a question about intended encodings. With the > rule of "liberal in what you receive" I would not expect any interop > problems. > > > This is our opportunity to fix the example and > >>removed the problem (and then folks can simplify >>their implementations). If the difference remains, >>there will be opportunity for creating more interop >>problems (if implementations behave differently for >>the different encodings). > > > I'd like to clarify the extent of the simplification that you are > proposing in people's implementations. You are suggesting replacing a line > of code that says: > > if ( (rcc==1) && (ncc == 0 || ncc == 1) ) > > with a line of code that says > > if ( (rcc==1) && (ncc == 1) ) > > Why is this a big deal? > > >>So, rather than make things more complicated by >>modifying an accepted rule (RCC=1 requires NCC>1), >>retaining two encodings for the same signal, and >>adding notes to attempt to explain the interworking >>options, it is much easier to correct the example. > > > Again, I think you are misrepresenting what the authors are doing. In > their view they are not changing the rules, but correcting an editorial > mistake. In their opinion the example is already correct. > > Now, I don't want to start any voting here, but I see several people who > are expressing support for the ideas in > draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying > make the change the other way. If I was to judge consensus today, it is > pretty clear how I would call it. > > Let's hear some opinions from other people who have an interest in this > work. > > Thanks, > Adrian > > > >>This is good engineering practice, in my view. >> >>Regards, >>Ben >> >> >>>-----Original Message----- >>>From: Richard Rabbat [mailto:richard@us.fujitsu.com] >>>Sent: Tuesday, August 30, 2005 3:58 PM >>>To: Mack-Crane, T. Benjamin >>>Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org >>>Subject: Re: Final draft of response to the OIF >>> >>>Ben, >>>Adrian's final draft of the response is most inclusive. From what you >>>said earlier, it seems that you've already coded it in one way >>>(whichever) but are accepting both sets of values for NCC & >>>RCC (both 1 or 0). >>>Is there an engineering problem with the text of the response besides >>>that you would be able to remove those couple of lines of >>>code? if so, >>>we should solve it. >>>Richard. >>> >>> >>>Mack-Crane, T. Benjamin wrote: >>> >>> >>>>Hi Huub, >>>> >>>>See in-line below. >>>> >>>>Regards, >>>>Ben >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] >>>>>Sent: Friday, August 26, 2005 10:56 AM >>>>>To: Mack-Crane, T. Benjamin >>>>>Cc: Adrian Farrel; ccamp@ops.ietf.org >>>>>Subject: Re: Final draft of response to the OIF >>>>> >>>>>Hello Ben, >>>>> >>>>>You wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>I proposed a simple (and I think technically sound) solution to >>>>>>item #1 and saw no objections, however the answer has not changed. >>>>>> >>>>>>I do not understand the reason for different encodings for >>>>>>VC-4 and STS-3c SPE. I think they should be the same, unless >>>>>>there is a technical need to distinguish them. >>>>>> >>>>>> >>>>> >>>>>If there is agreement that they should be the same, we should >>>>>also look at higher order contiguous concatenated signals: >>>>>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c >>>>>STS-768c == VC-4-256c >>>>> >>>>> >>>> >>>>These signals are already encoded the same way (for instance see >>>>examples 3 and 9 in RFC 3946). >>>> >>>> >>>> >>>> >>>>>>I also do not understand the RCC=1 NCC=1 encoding, since the rule >>>>>>contained in the current RFC actually makes more sense. >>>>>> >>>>>> >>>>> >>>>>However indicating the number of signals concatenated in NCC >>>>>makes your first objective impossible: STS-3Xc == VC-4-Xc >>>>>so there will always be a difference of a factor 3 between >>>>>STS and VC-4 encoding >>>>> >>>>> >>>> >>>>All the encodings of contiguous concatenated signals use VC-4 >>>>(STS-3c SPE) as the base, so the NCC values are the same. This >>>>was done to align SONET and SDH encodings. >>>> >>>> >>>> >>>> >>>>>>If there is >>>>>>only >>>>>>one signal element, there is no contiguous concatenation, >>>>>> >>>>>> >>>>> >>>>>by definition. >>>>> >>>>>In fact a single signal is always contiguous concatenated ;-) >>>>> >>>>> >>>>> >>>>> >>>>>>So I fail to see the usefulness of these encodings. >>>>>> >>>>>> >>>>> >>>>>NCC = 1 would normally not occur, so it could be used for >>>>>this specific case of SONET signals transported in an >>>>>SDH world, or SDH signals transported in SONET land. >>>>>And if these signals would not cross borders the value >>>>>NCC > 1 can be used. >>>>> >>>>> >>>> >>>>The SDH and SONET encodings have been aligned in all cases >>>>except this one (VC-4, STS-3c SPE). So these should also >>>>be aligned. >>>> >>>> >>>> >>>> >>>>>>Regards, >>>>>>Ben >>>>>> >>>>>> >>>>> >>>>>Cheers, Huub. >>>>> >>>>>-- >>>>>================================================================ >>>>> 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 >>>>============================================================ >>>> >>>> >>>> >>> >>============================================================ >>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 >>============================================================ >> >> > > > -- ________________________________________________________________________ Walter Rothkegel, Lucent Technologies Network Systems GmbH, Dept. O-SE Thurn-und-Taxis-Str. 10-14, 90411 Nuernberg, Germany Phone: +49 911 526-4084 Fax: +49 911 526-6299 mailto:wrothkegel@lucent.com Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Aug 2005 04:51:15 +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: Wed, 31 Aug 2005 00:47:40 -0400 Message-ID: <0901D1988E815341A0103206A834DA07614896@mdmxm02.ciena.com> Thread-Topic: Final draft of response to the OIF thread-index: AcWtuClga8yGbSLuR6uk3RqoONxALAAK8TFw From: "Ong, Lyndon" To: "Adrian Farrel" , "Mack-Crane, T. Benjamin" , "Richard Rabbat" Cc: "Huub van Helvoort" , Hi Adrian, I have some sympathy with Ben's comments, it seems like a single value would simplify configuration the most. We were able to work around the problem at the OIF test, but the number of vendors was limited and it did cause some initial headaches. Short of a single value, maybe a slight rewording of your text would make a stronger recommendation that implementations be able to accept both, e.g.: " Note 3: Following these rules, when requesting a VC-4 signal, the RCC and the NCC values must be set to 0 whereas for an STS-3c SPE signal, the RCC and the NCC values must be set 1. However, if local conditions allow (e.g., no differentiation of VC-4 vs. STS-3c format is required), then the requesting upstream node MAY set the RCC and NCC values to either SDH or SONET settings without impacting the function, and the downstream node SHOULD accept either of the requested values. If the received value cannot be supported, the receiver downstream node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively). " Cheers, Lyndon -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, August 30, 2005 4:12 PM To: Mack-Crane, T. Benjamin; Richard Rabbat Cc: Huub van Helvoort; ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF Hi Ben, > A long time ago an agreement was reached to unify the SDH and SONET=20 > encodings, since carriers did not want to manage unnecessary=20 > differences. Good motivation. Presume that here you are not really talking about the SDH and SONET encoding, but rather the control plane encodings. > What implementations have done as a result of the bad example in RFC=20 > 3946 is unfortunate, and leads to interop problems -- and thus the=20 > item from the OIF. Whether the example is bad or not clearly depends on the encoding rules specified in the RFC. With the clarification from the Editors, it would appear that the example is good. Now, you can object to the encoding rules, but that doesn't mean that the example is bad. I have not heard of any interop problems. Centrainly the message from the OIF did not report any such problems. My understanding is that there were no interope problems, merely a question about intended encodings. With the rule of "liberal in what you receive" I would not expect any interop problems. > This is our opportunity to fix the example and > removed the problem (and then folks can simplify their=20 > implementations). If the difference remains, there will be=20 > opportunity for creating more interop problems (if implementations=20 > behave differently for the different encodings). I'd like to clarify the extent of the simplification that you are proposing in people's implementations. You are suggesting replacing a line of code that says: if ( (rcc=3D=3D1) && (ncc =3D=3D 0 || ncc =3D=3D 1) ) with a line of code that says if ( (rcc=3D=3D1) && (ncc =3D=3D 1) ) Why is this a big deal? > So, rather than make things more complicated by modifying an accepted=20 > rule (RCC=3D1 requires NCC>1), retaining two encodings for the same=20 > signal, and adding notes to attempt to explain the interworking=20 > options, it is much easier to correct the example. Again, I think you are misrepresenting what the authors are doing. In their view they are not changing the rules, but correcting an editorial mistake. In their opinion the example is already correct. Now, I don't want to start any voting here, but I see several people who are expressing support for the ideas in draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying make the change the other way. If I was to judge consensus today, it is pretty clear how I would call it. Let's hear some opinions from other people who have an interest in this work. Thanks, Adrian > > This is good engineering practice, in my view. > > Regards, > Ben > > > -----Original Message----- > > From: Richard Rabbat [mailto:richard@us.fujitsu.com] > > Sent: Tuesday, August 30, 2005 3:58 PM > > To: Mack-Crane, T. Benjamin > > Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org > > Subject: Re: Final draft of response to the OIF > > > > Ben, > > Adrian's final draft of the response is most inclusive. From what=20 > > you said earlier, it seems that you've already coded it in one way > > (whichever) but are accepting both sets of values for NCC & RCC=20 > > (both 1 or 0). > > Is there an engineering problem with the text of the response=20 > > besides that you would be able to remove those couple of lines of=20 > > code? if so, we should solve it. > > Richard. > > > > > > Mack-Crane, T. Benjamin wrote: > > > > >Hi Huub, > > > > > >See in-line below. > > > > > >Regards, > > >Ben > > > > > > > > > > > >>-----Original Message----- > > >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > > >>Sent: Friday, August 26, 2005 10:56 AM > > >>To: Mack-Crane, T. Benjamin > > >>Cc: Adrian Farrel; ccamp@ops.ietf.org > > >>Subject: Re: Final draft of response to the OIF > > >> > > >>Hello Ben, > > >> > > >>You wrote: > > >> > > >> > > >> > > >>>I proposed a simple (and I think technically sound) solution to=20 > > >>>item #1 and saw no objections, however the answer has not changed. > > >>> > > >>>I do not understand the reason for different encodings for > > >>>VC-4 and STS-3c SPE. I think they should be the same, unless=20 > > >>>there is a technical need to distinguish them. > > >>> > > >>> > > >>If there is agreement that they should be the same, we should also > > >>look at higher order contiguous concatenated signals: > > >>i.e. STS-12c =3D=3D VC-4-4c, STS-48c =3D=3D VC-4-16c, STS-192c = =3D=3D VC-4-64c > > >>STS-768c =3D=3D VC-4-256c > > >> > > >> > > > > > >These signals are already encoded the same way (for instance see=20 > > >examples 3 and 9 in RFC 3946). > > > > > > > > > > > >>>I also do not understand the RCC=3D1 NCC=3D1 encoding, since the = rule > > >>>contained in the current RFC actually makes more sense. > > >>> > > >>> > > >>However indicating the number of signals concatenated in NCC makes > > >>your first objective impossible: STS-3Xc =3D=3D VC-4-Xc so there = will=20 > > >>always be a difference of a factor 3 between STS and VC-4 encoding > > >> > > >> > > > > > >All the encodings of contiguous concatenated signals use VC-4=20 > > >(STS-3c SPE) as the base, so the NCC values are the same. This was > > >done to align SONET and SDH encodings. > > > > > > > > > > > >>>If there is > > >>>only > > >>>one signal element, there is no contiguous concatenation, > > >>> > > >>> > > >>by definition. > > >> > > >>In fact a single signal is always contiguous concatenated ;-) > > >> > > >> > > >> > > >>>So I fail to see the usefulness of these encodings. > > >>> > > >>> > > >>NCC =3D 1 would normally not occur, so it could be used for this=20 > > >>specific case of SONET signals transported in an SDH world, or SDH > > >>signals transported in SONET land. > > >>And if these signals would not cross borders the value NCC > 1 can > > >>be used. > > >> > > >> > > > > > >The SDH and SONET encodings have been aligned in all cases except=20 > > >this one (VC-4, STS-3c SPE). So these should also be aligned. > > > > > > > > > > > >>>Regards, > > >>>Ben > > >>> > > >>> > > >>Cheers, Huub. > > >> > > >>-- > > = >>=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=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 > > >> http://members.chello.nl/hhelvoort/ > > = >>=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=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 > > >>Always remember that you are unique...just like everyone else... > > >> > > >> > > >> > > = >=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >The information contained in this message may be privileged and=20 > > >confidential and protected from disclosure. If the reader of this=20 > > >message is not the intended recipient, or an employee or agent=20 > > >responsible for delivering this message to the intended recipient,=20 > > >you are hereby notified that any reproduction, dissemination or=20 > > >distribution of this communication is strictly prohibited. If you=20 > > >have received this communication in error, please notify us=20 > > >immediately by replying to the message and deleting it from your=20 > > >computer. Thank you. Tellabs=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=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=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=3D=3D=3D=3D=3D=3D > The information contained in this message may be privileged and=20 > confidential and protected from disclosure. If the reader of this=20 > message is not the intended recipient, or an employee or agent=20 > responsible for delivering this message to the intended recipient, you > are hereby notified that any reproduction, dissemination or=20 > distribution of this communication is strictly prohibited. If you have > received this communication in error, please notify us immediately by=20 > replying to the message and deleting it from your computer. Thank you. > Tellabs = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 31 Aug 2005 00:49:54 +0000 Message-ID: <4314FE56.4070407@grotto-networking.com> Date: Tue, 30 Aug 2005 17:48:22 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: Adrian Farrel CC: "Mack-Crane, T. Benjamin" , 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 folks, a bit of history. At the time the ID was originally written a number of manufacturers had (and still offer) more flexible forms of concatenation rather than the standard SONET/SDH contiguous concatenation. This and the usual standards related compromises lead to the rather general and possibly confusing rules that appear in RFC 3946. Unknown to us at the time was that none of these proprietary schemes would become standardized. This is mostly due to the greater abilities of Virtual Concatenation (VCAT) which was standardized and since extended beyond SONET/SDH to OTN and PDH. Hence though RFC3946 encoding seems a bit obtuse the intentions were aimed at future proofing (but part of that future didn't happen). I've tried to make ammends by working with Richard and others to clear things up while minimizing the impact to implementations. At this point in time is there any other option since this is already a standards track RFC? Greg B. Adrian Farrel wrote: >Hi Ben, > > > >>A long time ago an agreement was reached to unify >>the SDH and SONET encodings, since carriers did not >>want to manage unnecessary differences. >> >> > >Good motivation. > >Presume that here you are not really talking about the SDH and SONET >encoding, but rather the control plane encodings. > > > >>What implementations have done as a result of the >>bad example in RFC 3946 is unfortunate, and leads to >>interop problems -- and thus the item from the OIF. >> >> > >Whether the example is bad or not clearly depends on the encoding rules >specified in the RFC. >With the clarification from the Editors, it would appear that the example >is good. Now, you can object to the encoding rules, but that doesn't mean >that the example is bad. > >I have not heard of any interop problems. Centrainly the message from the >OIF did not report any such problems. My understanding is that there were >no interope problems, merely a question about intended encodings. With the >rule of "liberal in what you receive" I would not expect any interop >problems. > > > This is our opportunity to fix the example and > > >>removed the problem (and then folks can simplify >>their implementations). If the difference remains, >>there will be opportunity for creating more interop >>problems (if implementations behave differently for >>the different encodings). >> >> > >I'd like to clarify the extent of the simplification that you are >proposing in people's implementations. You are suggesting replacing a line >of code that says: > > if ( (rcc==1) && (ncc == 0 || ncc == 1) ) > >with a line of code that says > > if ( (rcc==1) && (ncc == 1) ) > >Why is this a big deal? > > > >>So, rather than make things more complicated by >>modifying an accepted rule (RCC=1 requires NCC>1), >>retaining two encodings for the same signal, and >>adding notes to attempt to explain the interworking >>options, it is much easier to correct the example. >> >> > >Again, I think you are misrepresenting what the authors are doing. In >their view they are not changing the rules, but correcting an editorial >mistake. In their opinion the example is already correct. > >Now, I don't want to start any voting here, but I see several people who >are expressing support for the ideas in >draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying >make the change the other way. If I was to judge consensus today, it is >pretty clear how I would call it. > >Let's hear some opinions from other people who have an interest in this >work. > >Thanks, >Adrian > > > > >>This is good engineering practice, in my view. >> >>Regards, >>Ben >> >> >> >>>-----Original Message----- >>>From: Richard Rabbat [mailto:richard@us.fujitsu.com] >>>Sent: Tuesday, August 30, 2005 3:58 PM >>>To: Mack-Crane, T. Benjamin >>>Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org >>>Subject: Re: Final draft of response to the OIF >>> >>>Ben, >>>Adrian's final draft of the response is most inclusive. From what you >>>said earlier, it seems that you've already coded it in one way >>>(whichever) but are accepting both sets of values for NCC & >>>RCC (both 1 or 0). >>>Is there an engineering problem with the text of the response besides >>>that you would be able to remove those couple of lines of >>>code? if so, >>>we should solve it. >>>Richard. >>> >>> >>>Mack-Crane, T. Benjamin wrote: >>> >>> >>> >>>>Hi Huub, >>>> >>>>See in-line below. >>>> >>>>Regards, >>>>Ben >>>> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] >>>>>Sent: Friday, August 26, 2005 10:56 AM >>>>>To: Mack-Crane, T. Benjamin >>>>>Cc: Adrian Farrel; ccamp@ops.ietf.org >>>>>Subject: Re: Final draft of response to the OIF >>>>> >>>>>Hello Ben, >>>>> >>>>>You wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>I proposed a simple (and I think technically sound) solution to >>>>>>item #1 and saw no objections, however the answer has not changed. >>>>>> >>>>>>I do not understand the reason for different encodings for >>>>>>VC-4 and STS-3c SPE. I think they should be the same, unless >>>>>>there is a technical need to distinguish them. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>If there is agreement that they should be the same, we should >>>>>also look at higher order contiguous concatenated signals: >>>>>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c >>>>>STS-768c == VC-4-256c >>>>> >>>>> >>>>> >>>>> >>>>These signals are already encoded the same way (for instance see >>>>examples 3 and 9 in RFC 3946). >>>> >>>> >>>> >>>> >>>> >>>>>>I also do not understand the RCC=1 NCC=1 encoding, since the rule >>>>>>contained in the current RFC actually makes more sense. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>However indicating the number of signals concatenated in NCC >>>>>makes your first objective impossible: STS-3Xc == VC-4-Xc >>>>>so there will always be a difference of a factor 3 between >>>>>STS and VC-4 encoding >>>>> >>>>> >>>>> >>>>> >>>>All the encodings of contiguous concatenated signals use VC-4 >>>>(STS-3c SPE) as the base, so the NCC values are the same. This >>>>was done to align SONET and SDH encodings. >>>> >>>> >>>> >>>> >>>> >>>>>>If there is >>>>>>only >>>>>>one signal element, there is no contiguous concatenation, >>>>>> >>>>>> >>>>>> >>>>>> >>>>>by definition. >>>>> >>>>>In fact a single signal is always contiguous concatenated ;-) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>So I fail to see the usefulness of these encodings. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>NCC = 1 would normally not occur, so it could be used for >>>>>this specific case of SONET signals transported in an >>>>>SDH world, or SDH signals transported in SONET land. >>>>>And if these signals would not cross borders the value >>>>>NCC > 1 can be used. >>>>> >>>>> >>>>> >>>>> >>>>The SDH and SONET encodings have been aligned in all cases >>>>except this one (VC-4, STS-3c SPE). So these should also >>>>be aligned. >>>> >>>> >>>> >>>> >>>> >>>>>>Regards, >>>>>>Ben >>>>>> >>>>>> >>>>>> >>>>>> >>>>>Cheers, Huub. >>>>> >>>>>-- >>>>>================================================================ >>>>> 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 >>>>============================================================ >>>> >>>> >>>> >>>> >>>> >>============================================================ >>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: Tue, 30 Aug 2005 23:10:09 +0000 Message-ID: <0f6601c5adb8$3967d160$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Mack-Crane, T. Benjamin" , "Richard Rabbat" Cc: "Huub van Helvoort" , Subject: Re: Final draft of response to the OIF Date: Wed, 31 Aug 2005 00:11:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Ben, > A long time ago an agreement was reached to unify > the SDH and SONET encodings, since carriers did not > want to manage unnecessary differences. Good motivation. Presume that here you are not really talking about the SDH and SONET encoding, but rather the control plane encodings. > What implementations have done as a result of the > bad example in RFC 3946 is unfortunate, and leads to > interop problems -- and thus the item from the OIF. Whether the example is bad or not clearly depends on the encoding rules specified in the RFC. With the clarification from the Editors, it would appear that the example is good. Now, you can object to the encoding rules, but that doesn't mean that the example is bad. I have not heard of any interop problems. Centrainly the message from the OIF did not report any such problems. My understanding is that there were no interope problems, merely a question about intended encodings. With the rule of "liberal in what you receive" I would not expect any interop problems. > This is our opportunity to fix the example and > removed the problem (and then folks can simplify > their implementations). If the difference remains, > there will be opportunity for creating more interop > problems (if implementations behave differently for > the different encodings). I'd like to clarify the extent of the simplification that you are proposing in people's implementations. You are suggesting replacing a line of code that says: if ( (rcc==1) && (ncc == 0 || ncc == 1) ) with a line of code that says if ( (rcc==1) && (ncc == 1) ) Why is this a big deal? > So, rather than make things more complicated by > modifying an accepted rule (RCC=1 requires NCC>1), > retaining two encodings for the same signal, and > adding notes to attempt to explain the interworking > options, it is much easier to correct the example. Again, I think you are misrepresenting what the authors are doing. In their view they are not changing the rules, but correcting an editorial mistake. In their opinion the example is already correct. Now, I don't want to start any voting here, but I see several people who are expressing support for the ideas in draft-papadimitriou-ccamp-rfc3946bis-00.txt, and I see one person saying make the change the other way. If I was to judge consensus today, it is pretty clear how I would call it. Let's hear some opinions from other people who have an interest in this work. Thanks, Adrian > > This is good engineering practice, in my view. > > Regards, > Ben > > > -----Original Message----- > > From: Richard Rabbat [mailto:richard@us.fujitsu.com] > > Sent: Tuesday, August 30, 2005 3:58 PM > > To: Mack-Crane, T. Benjamin > > Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org > > Subject: Re: Final draft of response to the OIF > > > > Ben, > > Adrian's final draft of the response is most inclusive. From what you > > said earlier, it seems that you've already coded it in one way > > (whichever) but are accepting both sets of values for NCC & > > RCC (both 1 or 0). > > Is there an engineering problem with the text of the response besides > > that you would be able to remove those couple of lines of > > code? if so, > > we should solve it. > > Richard. > > > > > > Mack-Crane, T. Benjamin wrote: > > > > >Hi Huub, > > > > > >See in-line below. > > > > > >Regards, > > >Ben > > > > > > > > > > > >>-----Original Message----- > > >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > > >>Sent: Friday, August 26, 2005 10:56 AM > > >>To: Mack-Crane, T. Benjamin > > >>Cc: Adrian Farrel; ccamp@ops.ietf.org > > >>Subject: Re: Final draft of response to the OIF > > >> > > >>Hello Ben, > > >> > > >>You wrote: > > >> > > >> > > >> > > >>>I proposed a simple (and I think technically sound) solution to > > >>>item #1 and saw no objections, however the answer has not changed. > > >>> > > >>>I do not understand the reason for different encodings for > > >>>VC-4 and STS-3c SPE. I think they should be the same, unless > > >>>there is a technical need to distinguish them. > > >>> > > >>> > > >>If there is agreement that they should be the same, we should > > >>also look at higher order contiguous concatenated signals: > > >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c > > >>STS-768c == VC-4-256c > > >> > > >> > > > > > >These signals are already encoded the same way (for instance see > > >examples 3 and 9 in RFC 3946). > > > > > > > > > > > >>>I also do not understand the RCC=1 NCC=1 encoding, since the rule > > >>>contained in the current RFC actually makes more sense. > > >>> > > >>> > > >>However indicating the number of signals concatenated in NCC > > >>makes your first objective impossible: STS-3Xc == VC-4-Xc > > >>so there will always be a difference of a factor 3 between > > >>STS and VC-4 encoding > > >> > > >> > > > > > >All the encodings of contiguous concatenated signals use VC-4 > > >(STS-3c SPE) as the base, so the NCC values are the same. This > > >was done to align SONET and SDH encodings. > > > > > > > > > > > >>>If there is > > >>>only > > >>>one signal element, there is no contiguous concatenation, > > >>> > > >>> > > >>by definition. > > >> > > >>In fact a single signal is always contiguous concatenated ;-) > > >> > > >> > > >> > > >>>So I fail to see the usefulness of these encodings. > > >>> > > >>> > > >>NCC = 1 would normally not occur, so it could be used for > > >>this specific case of SONET signals transported in an > > >>SDH world, or SDH signals transported in SONET land. > > >>And if these signals would not cross borders the value > > >>NCC > 1 can be used. > > >> > > >> > > > > > >The SDH and SONET encodings have been aligned in all cases > > >except this one (VC-4, STS-3c SPE). So these should also > > >be aligned. > > > > > > > > > > > >>>Regards, > > >>>Ben > > >>> > > >>> > > >>Cheers, Huub. > > >> > > >>-- > > >>================================================================ > > >> 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 > > >============================================================ > > > > > > > > > > > > ============================================================ > 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: Tue, 30 Aug 2005 22:35:26 +0000 Message-ID: <0ee701c5ad88$e1c18200$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Clarifying the basis for new work in CCAMP Date: Tue, 30 Aug 2005 18:15:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have had some email seeking clarification of the basis upon which we will construct new CCAMP drafts if/when we have new milestones within our charter. The text accompanying the milestones was intended to fuel the discussion and is not proposed as part of the charter. It included the words... > Existing drafts > are referenced to indicate that work is already in progress - > this is not intended to provide a complete list of existing > drafts. My covering email said... > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. To clarify this still further: The CCAMP WG drafts will be refined and submitted to the IESG by the WG. The milestones are: a. To have a WG draft on the subject b. To submit that draft to the IESG This doesn't prohibit other WG drafts near the subject, but I would assume that we only have one draft that is precisely on target. We will obviously need to select drafts to use as the foundations of the WG drafts. This choice will be made on a case by case basis. In some cases an existing draft will be used; in others we will need to start a new draft because no pre-existing work exists, or because we need to combine two or more existing drafts. The point, however, is to build a WG draft out of the working group, and then refine the draft until it is submitted. All material is taken as input and filtered through WG consensus. I hope this clarifies. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 30 Aug 2005 22:34:01 +0000 Message-ID: <0dde01c5ad62$8c1dca50$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-05.txt Date: Tue, 30 Aug 2005 13:43:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Revision 04 of this document was made by the authors to include updates after WG last call. Revision 05 was made by me to handle purely editorial issues (formatting, section numbering, typos) and includes no technical changes. I will now pass this to the ADs for IESG review. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Monday, August 29, 2005 11:50 PM Subject: I-D ACTION:draft-ietf-ccamp-rsvp-te-exclude-route-05.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 : Exclude Routes - Extension to RSVP-TE > Author(s) : A. Farrel, et al. > Filename : draft-ietf-ccamp-rsvp-te-exclude-route-05.txt > Pages : 26 > Date : 2005-8-29 > > The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP > Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized > Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation > Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow > abstract nodes and resources to be explicitly included in a path > setup, but not to be explicitly excluded. > > In some networks where precise explicit paths are not computed at the > head end it may be useful to specify and signal abstract nodes and > resources that are to be explicitly excluded from routes. These > exclusions may apply to the whole path, or to parts of a path between > two abstract nodes specified in an explicit path. How Shared Risk > Link Groups (SLRGs) can be excluded is also specified in this > document. > > This document specifies ways to communicate route exclusions during > path setup using RSVP-TE. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.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-te-exclude-route-05.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-te-exclude-route-05.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: Tue, 30 Aug 2005 22:13:55 +0000 Message-ID: <0eb701c5ad81$fe3f87d0$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: RFC 3946 bis Date: Tue, 30 Aug 2005 17:43:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, In view of the issues raised on the list in March and more recently by the OIF in their questions, I have asked the editors of RFC 3946 to prepare an I-D that is a bis on the RFC to document what they intended to write. That is, to document the consensus of the WG at the time the I-D was submitted to be an RFC, As such, this I-D is not a change to the procedures that were agreed, and does not reflect any change in the implementation. it is simply a clarification of what was written. In particular, it fixes a typo where "greater than" was written and "greater than or equal to" was meant. I note that Ben has been raising an issue that proposes a change to the procedures documented in RFC 3946. I have not seen any support for this so far, and I do not propose that we should make such a change to RFC 3946 in this I-D. Thanks to Dimitri for moving forward with these editorial changes. If you look through the draft you will see that Dimitri has inserted notes to highlight the changes (to make it easy for you to review and to explain the changes). I would like to move this I-D through the process PDQ so I will give you a short time to read, digest and send mail. Barring any major upsets, we will make this a WG I-D on 7th September, and then look for any other editorial clarifications we should make at the same time, before moving rapidly on to WG last call. Thanks, Adrian ----- Original Message ----- From: To: Sent: Monday, August 29, 2005 11:50 PM Subject: I-D ACTION:draft-papadimitriou-ccamp-rfc3946bis-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Generalized Multi-Protocol Label Switching > (GMPLS) Extensions for Synchronous Optical > Network (SONET) and Synchronous Digital > Hierarchy (SDH) Control > Author(s) : E. Mannie, D. Papadimitriou > Filename : draft-papadimitriou-ccamp-rfc3946bis-00.txt > Pages : 24 > Date : 2005-8-29 > > This document provides minor clarification to RFC 3946. > > This document is a companion to the Generalized Multi-Protocol > Label Switching (GMPLS) signaling. It defines the Synchronous > Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) > technology specific information needed when using GMPLS signaling. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-papadimitriou-ccamp-rfc3946bis-00.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-papadimitriou-ccamp-rfc3946bis-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-papadimitriou-ccamp-rfc3946bis-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------- ------ > _______________________________________________ > 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: Tue, 30 Aug 2005 21:51:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Final draft of response to the OIF Date: Tue, 30 Aug 2005 16:48:39 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWtpbcSdsIcyKOURZS82NqCXAxtoQABMWHQ From: "Mack-Crane, T. Benjamin" To: "Richard Rabbat" Cc: "Huub van Helvoort" , "Adrian Farrel" , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi Richard, A long time ago an agreement was reached to unify the SDH and SONET encodings, since carriers did not want to manage unnecessary differences. What implementations have done as a result of the bad example in RFC 3946 is unfortunate, and leads to interop problems -- and thus the item from the OIF. This is our opportunity to fix the example and removed the problem (and then folks can simplify their implementations). If the difference remains, there will be opportunity for creating more interop problems (if implementations behave differently for the different encodings). So, rather than make things more complicated by modifying an accepted rule (RCC=1 requires NCC>1), retaining two encodings for the same signal, and adding notes to attempt to explain the interworking options, it is much easier to correct the example. This is good engineering practice, in my view. Regards, Ben > -----Original Message----- > From: Richard Rabbat [mailto:richard@us.fujitsu.com] > Sent: Tuesday, August 30, 2005 3:58 PM > To: Mack-Crane, T. Benjamin > Cc: Huub van Helvoort; Adrian Farrel; ccamp@ops.ietf.org > Subject: Re: Final draft of response to the OIF > > Ben, > Adrian's final draft of the response is most inclusive. From what you > said earlier, it seems that you've already coded it in one way > (whichever) but are accepting both sets of values for NCC & > RCC (both 1 > or 0). > Is there an engineering problem with the text of the response besides > that you would be able to remove those couple of lines of > code? if so, > we should solve it. > Richard. > > > Mack-Crane, T. Benjamin wrote: > > >Hi Huub, > > > >See in-line below. > > > >Regards, > >Ben > > > > > > > >>-----Original Message----- > >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > >>Sent: Friday, August 26, 2005 10:56 AM > >>To: Mack-Crane, T. Benjamin > >>Cc: Adrian Farrel; ccamp@ops.ietf.org > >>Subject: Re: Final draft of response to the OIF > >> > >>Hello Ben, > >> > >>You wrote: > >> > >> > >> > >>>I proposed a simple (and I think technically sound) solution to > >>>item #1 and saw no objections, however the answer has not changed. > >>> > >>>I do not understand the reason for different encodings for > >>>VC-4 and STS-3c SPE. I think they should be the same, unless > >>>there is a technical need to distinguish them. > >>> > >>> > >>If there is agreement that they should be the same, we should > >>also look at higher order contiguous concatenated signals: > >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c > >>STS-768c == VC-4-256c > >> > >> > > > >These signals are already encoded the same way (for instance see > >examples 3 and 9 in RFC 3946). > > > > > > > >>>I also do not understand the RCC=1 NCC=1 encoding, since the rule > >>>contained in the current RFC actually makes more sense. > >>> > >>> > >>However indicating the number of signals concatenated in NCC > >>makes your first objective impossible: STS-3Xc == VC-4-Xc > >>so there will always be a difference of a factor 3 between > >>STS and VC-4 encoding > >> > >> > > > >All the encodings of contiguous concatenated signals use VC-4 > >(STS-3c SPE) as the base, so the NCC values are the same. This > >was done to align SONET and SDH encodings. > > > > > > > >>>If there is > >>>only > >>>one signal element, there is no contiguous concatenation, > >>> > >>> > >>by definition. > >> > >>In fact a single signal is always contiguous concatenated ;-) > >> > >> > >> > >>>So I fail to see the usefulness of these encodings. > >>> > >>> > >>NCC = 1 would normally not occur, so it could be used for > >>this specific case of SONET signals transported in an > >>SDH world, or SDH signals transported in SONET land. > >>And if these signals would not cross borders the value > >>NCC > 1 can be used. > >> > >> > > > >The SDH and SONET encodings have been aligned in all cases > >except this one (VC-4, STS-3c SPE). So these should also > >be aligned. > > > > > > > >>>Regards, > >>>Ben > >>> > >>> > >>Cheers, Huub. > >> > >>-- > >>================================================================ > >> 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 > >============================================================ > > > > > > > ============================================================ 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: Tue, 30 Aug 2005 21:00:34 +0000 Message-ID: <4314C857.9050604@us.fujitsu.com> Date: Tue, 30 Aug 2005 13:57:59 -0700 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: "Mack-Crane, T. Benjamin" CC: Huub van Helvoort , Adrian Farrel , ccamp@ops.ietf.org Subject: Re: Final draft of response to the OIF Content-Type: multipart/mixed; boundary="------------010407070100000003070807" This is a multi-part message in MIME format. --------------010407070100000003070807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ben, Adrian's final draft of the response is most inclusive. From what you said earlier, it seems that you've already coded it in one way (whichever) but are accepting both sets of values for NCC & RCC (both 1 or 0). Is there an engineering problem with the text of the response besides that you would be able to remove those couple of lines of code? if so, we should solve it. Richard. Mack-Crane, T. Benjamin wrote: >Hi Huub, > >See in-line below. > >Regards, >Ben > > > >>-----Original Message----- >>From: Huub van Helvoort [mailto:hhelvoort@chello.nl] >>Sent: Friday, August 26, 2005 10:56 AM >>To: Mack-Crane, T. Benjamin >>Cc: Adrian Farrel; ccamp@ops.ietf.org >>Subject: Re: Final draft of response to the OIF >> >>Hello Ben, >> >>You wrote: >> >> >> >>>I proposed a simple (and I think technically sound) solution to >>>item #1 and saw no objections, however the answer has not changed. >>> >>>I do not understand the reason for different encodings for >>>VC-4 and STS-3c SPE. I think they should be the same, unless >>>there is a technical need to distinguish them. >>> >>> >>If there is agreement that they should be the same, we should >>also look at higher order contiguous concatenated signals: >>i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c >>STS-768c == VC-4-256c >> >> > >These signals are already encoded the same way (for instance see >examples 3 and 9 in RFC 3946). > > > >>>I also do not understand the RCC=1 NCC=1 encoding, since the rule >>>contained in the current RFC actually makes more sense. >>> >>> >>However indicating the number of signals concatenated in NCC >>makes your first objective impossible: STS-3Xc == VC-4-Xc >>so there will always be a difference of a factor 3 between >>STS and VC-4 encoding >> >> > >All the encodings of contiguous concatenated signals use VC-4 >(STS-3c SPE) as the base, so the NCC values are the same. This >was done to align SONET and SDH encodings. > > > >>>If there is >>>only >>>one signal element, there is no contiguous concatenation, >>> >>> >>by definition. >> >>In fact a single signal is always contiguous concatenated ;-) >> >> >> >>>So I fail to see the usefulness of these encodings. >>> >>> >>NCC = 1 would normally not occur, so it could be used for >>this specific case of SONET signals transported in an >>SDH world, or SDH signals transported in SONET land. >>And if these signals would not cross borders the value >>NCC > 1 can be used. >> >> > >The SDH and SONET encodings have been aligned in all cases >except this one (VC-4, STS-3c SPE). So these should also >be aligned. > > > >>>Regards, >>>Ben >>> >>> >>Cheers, Huub. >> >>-- >>================================================================ >> 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 >============================================================ > > > --------------010407070100000003070807 Content-Type: text/x-vcard; charset=utf-8; name="richard.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="richard.vcf" begin:vcard fn:Richard Rabbat n:Rabbat;Richard org:Fujitsu Labs of America;IP Networking Research adr:MS 345;;1240 East Arques Ave;Sunnyvale;CA;94085;USA email;internet:richard@us.fujitsu.com title:Senior Project Manager tel;work:1-408-530-4537 tel;fax:1-408-530-4515 tel;cell:1-650-714-7618 x-mozilla-html:TRUE version:2.1 end:vcard --------------010407070100000003070807-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Aug 2005 22:51:51 +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-te-exclude-route-05.txt Message-Id: Date: Mon, 29 Aug 2005 18: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 : Exclude Routes - Extension to RSVP-TE Author(s) : A. Farrel, et al. Filename : draft-ietf-ccamp-rsvp-te-exclude-route-05.txt Pages : 26 Date : 2005-8-29 The RSVP-TE specification, "RSVP-TE: Extensions to RSVP for LSP Tunnels" (RFC 3209) and GMPLS extensions to RSVP-TE, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions" (RFC 3473) allow abstract nodes and resources to be explicitly included in a path setup, but not to be explicitly excluded. In some networks where precise explicit paths are not computed at the head end it may be useful to specify and signal abstract nodes and resources that are to be explicitly excluded from routes. These exclusions may apply to the whole path, or to parts of a path between two abstract nodes specified in an explicit path. How Shared Risk Link Groups (SLRGs) can be excluded is also specified in this document. This document specifies ways to communicate route exclusions during path setup using RSVP-TE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.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-te-exclude-route-05.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-te-exclude-route-05.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-8-29165947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-rsvp-te-exclude-route-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-rsvp-te-exclude-route-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-29165947.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 29 Aug 2005 14:17:17 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Final draft of response to the OIF Date: Mon, 29 Aug 2005 09:11:32 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWqV26XP5LabOwhTMKk34aYghybOwCSkKug From: "Mack-Crane, T. Benjamin" To: "Huub van Helvoort" Cc: "Adrian Farrel" , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi Huub, See in-line below. Regards, Ben > -----Original Message----- > From: Huub van Helvoort [mailto:hhelvoort@chello.nl] > Sent: Friday, August 26, 2005 10:56 AM > To: Mack-Crane, T. Benjamin > Cc: Adrian Farrel; ccamp@ops.ietf.org > Subject: Re: Final draft of response to the OIF > > Hello Ben, > > You wrote: > > > I proposed a simple (and I think technically sound) solution to > > item #1 and saw no objections, however the answer has not changed. > > > > I do not understand the reason for different encodings for > > VC-4 and STS-3c SPE. I think they should be the same, unless > > there is a technical need to distinguish them. > > If there is agreement that they should be the same, we should > also look at higher order contiguous concatenated signals: > i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c > STS-768c == VC-4-256c These signals are already encoded the same way (for instance see examples 3 and 9 in RFC 3946). > > > I also do not understand the RCC=1 NCC=1 encoding, since the rule > > contained in the current RFC actually makes more sense. > > However indicating the number of signals concatenated in NCC > makes your first objective impossible: STS-3Xc == VC-4-Xc > so there will always be a difference of a factor 3 between > STS and VC-4 encoding All the encodings of contiguous concatenated signals use VC-4 (STS-3c SPE) as the base, so the NCC values are the same. This was done to align SONET and SDH encodings. > > > If there is > > only > > one signal element, there is no contiguous concatenation, > by definition. > > In fact a single signal is always contiguous concatenated ;-) > > > So I fail to see the usefulness of these encodings. > > NCC = 1 would normally not occur, so it could be used for > this specific case of SONET signals transported in an > SDH world, or SDH signals transported in SONET land. > And if these signals would not cross borders the value > NCC > 1 can be used. The SDH and SONET encodings have been aligned in all cases except this one (VC-4, STS-3c SPE). So these should also be aligned. > > > Regards, > > Ben > > Cheers, Huub. > > -- > ================================================================ > 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: Fri, 26 Aug 2005 23:41:28 +0000 Message-ID: <430F573F.6020308@chello.nl> Date: Fri, 26 Aug 2005 19:54:07 +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: ccamp Subject: Re: Final draft of response to the OIF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Ben, You wrote: > I proposed a simple (and I think technically sound) solution to > item #1 and saw no objections, however the answer has not changed. > > I do not understand the reason for different encodings for > VC-4 and STS-3c SPE. I think they should be the same, unless > there is a technical need to distinguish them. If there is agreement that they should be the same, we should also look at higher order contiguous concatenated signals: i.e. STS-12c == VC-4-4c, STS-48c == VC-4-16c, STS-192c == VC-4-64c STS-768c == VC-4-256c > I also do not understand the RCC=1 NCC=1 encoding, since the rule > contained in the current RFC actually makes more sense. However indicating the number of signals concatenated in NCC makes your first objective impossible: STS-3Xc == VC-4-Xc so there will always be a difference of a factor 3 between STS and VC-4 encoding > If there is > only > one signal element, there is no contiguous concatenation, by definition. In fact a single signal is always contiguous concatenated ;-) > So I fail to see the usefulness of these encodings. NCC = 1 would normally not occur, so it could be used for this specific case of SONET signals transported in an SDH world, or SDH signals transported in SONET land. And if these signals would not cross borders the value NCC > 1 can be used. > Regards, > Ben Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Aug 2005 17:42:53 +0000 Message-ID: <0c2201c5aa65$e0b4c7d0$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Arthi Ayyangar" , "'Jean Philippe Vasseur'" Cc: Subject: Comments on draft-ietf-ccamp-inter-domain-rsvp-te-01.txt Date: Fri, 26 Aug 2005 18:42:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, In Paris you said that you hoped for comments on this revision soon so that you could do a quick re-spin and request last call. So here are my comments. Cheers, Adrian === Section 2.1 Contiguous - A contiguous TE LSP is a single end-to-end TE LSP that is setup across multiple domains using RSVP-TE signaling procedures described in [RSVP-TE]and [RSVP-GMPLS]. No additional TE LSPs are required to signal a contiguous TE LSP and the same RSVP-TE information for the TE LSP is maintained along the entire LSP path. s/[RSVP-TE]and/[RSVP-TE] and/ ==== Section 2.1 Nesting - Nesting one or more TE LSPs into another TE LSP is described in [LSP-HIERARCHY]. This technique can also be used to nest one or more inter-domain TE LSPs into an intra-domain FA-LSP. While similar to stitching in the control plane, in the data plane, nesting allows for one or more inter-domain LSPs to be transported over a single intra-domain FA-LSP using the label stacking construct. s/technique can also be used/technique can be used/ Not sure that I like you saying "FA-LSP" here. The intra-domain LSP may be an FA-LSP or it may be a TE LSP advertised as a TE link into the other domain. It's a bit odd to compare with stitching which you haven't described yet. Suggest you re-write the paragraph as... Nesting - Nesting one or more TE LSPs into another TE LSP is described in [LSP-HIERARCHY]. This technique can be used to nest one or more inter-domain TE LSPs into an intra-domain TE LSP using the label stacking construct. ==== Section 2.1 Stitching - The concept of LSP stitching as well as the required signaling procedures are described in [LSP-STITCHING]. This technique can be used to stitch an inter-domain TE LSP to an intra-domain LSP segment. A inter-domain stitched TE LSP is a TE LSP made up of different TE LSP segments within each domain which are "stitched" together in the data plane so that an end-to-end LSP is achieved in the data plane. In the control plane, however, the different LSP segments are signaled as distinct RSVP sessions which are independent from the RSVP session for the inter-domain LSP. s/signaling procedures are described/signaling procedures is described/ (yes, really) You could add the comparison with hierarchies here. For example... While stitching is similar to nesting in the control plane, in the data plane stitching allows for only one inter-domain LSPs to be associated with any one intra-domain LSP, but does not require the use of label stacks. ==== Section 2.1 I think this section should say that later in the document you will define signaling extensions that allow the initiator of an inter-domain LSP to request the type of signaling technique used. This will help the flow of section 3. ==== Section 3 and 3.1 Could you format the bullet paragraphs better, please. ==== Section 3 Whether an inter-domain TE LSP is contiguous, nested or stitched is determined mostly by the signaling method supported by or configured on the intermediate nodes, usually the domain boundary nodes that the inter-domain TE LSP traverses through. It may also depend on certain s/traverses through/traverses/ ==== Section 3 inter-domain TE LSP traverses through. It may also depend on certain parameters signaled by the head-end node for the inter-domain TE LSP. s/may also depend/also depends/ s/parameters signaled by/parameters that may be signaled by/ ==== Section 3, second bullet. Is it possible that the policies or capabilities at the boundary node prohibit the support of the mechanism that is signaled? If yes, you should add a note describing rejection. If no, you should add "MUST use the mechanism requested in the signaling message" === Section 3, 4th and 7th bullets "Determine the next hop node" seems to be in conflict with "perform any path computation". I guess that when you say "determine the next hop node" you mean find the next sub-object in the ERO, or determine the destination or next boundary node. ==== Section 3.1 I would prefer you to say hierarchical LSP rather than FA-LSP. ==== Section 3.1 Please avoid using the word "appropriate". For example... then a PathErr with the appropriate error code should be sent back Please supply the actual error code that should be used. (Also use "SHOULD".) ==== Section 3.1 Should you also describe the case where there is no ERO? ==== Section 3.2 The propagation of Path Error upstream may be limited to within the domain or it may be sent all the way upstream to the head-end node of the inter-domain TE LSP. This sounds as though a domain boundary is allowed to silently swallow the PathErr message. I understand that you mean that a domain boundary may attempt re-routing, but that is not what you have said. ==== Section 3.2 Your discussion of crankback is limited to attempting to select another egress boundary node. This would certainly apply when a failure from a downstream domain is reported to the ingress boundary node of an upstream domain. However, you should also cover the case where the failure is within the domain and the ingress boundary node attempts to re-route within the domain. ==== Section 3.2 When a PathErr crosses a domain boundary it may be subject to policy and aggregation of information. I think you should describe this. ==== 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 you having to change your code too often.) ==== Section 4.1 (and section 9.1) Given that you have chosen to place you LSP Attributes bit in the optional (transparent) version of the object, you may want to consider how you will police its use. For example, what would happen if a domain boundary ignored this flag? The LSP Attributes draft suggests the use of the flag in the RRO in order to record whether it has been acted on (if not recorded, then not acted on and it is possible that nesting has been used). You might want to adopt this procedure, too. ==== Section 5.1 <-- AS-1 ---> <--- AS-2 ---> <-- AS-3 --> c Spurious letter "c" ==== Section 5.1 You figure shows R7 connected to the egress CE, but your example says... - A protected inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 in AS3 with following possible paths: ==== Section 5.1 Your example starts to talk about building a protected inter-AS LSP. But it transpires that you propose using FRR to provide protection for the resources used by a single unprotected LSP. I think you need to be careful with your terminology. ==== Section 5.1 - A protected inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 in AS3 with following possible paths: LSP hops: R0-X1-ASBR1-ASBR4-R3-ASBR7-ASBR9-R6 o p1 - a set of loose node hops crossing AS-2 R0-X1-ASBR1(loose)-ASBR4(loose)-ASBR7(loose)-ASBR9(loose)-R6 o p2 - a set of strict interface hops crossing AS-2 R0-X1-ASBR1(loose)-link[ASBR1-ASBR4](strict)-link[ASBR4-R3](strict) -link[R3-ASBR7](strict)-link[ASBR7-ASBR9](strict)-R6 You need to be careful. What do you mean by "LSP hops"? Is this the path of the LSP? In which case why are be bothering with the example? On the other hand, what are p1 and p2? Are they possible paths? In which case how can they have loose or strict hops? They must actually be explicit routes (i.e. EROs). So why have you chosen this set of two EROs when there are so many others possible? ==== Section 5.1 If you must use FRR in an example (although I can't see the value at all) you need to get the example right. B3 as quoted (ASBR1-ASBR2-ASBR3-ASBR6-ASBR7) is impossible on your topology. You probably mean ASBR1-ASBR2-ASBR3-ASBR6-R4-ASBR8-ASBR7 Similarly, B5 is not possible. You probably mean ASBR4-ASBR5-ASBR6-R4-ASBR8-ASBR10-ASBR9 ==== Section 5.2 Let us consider an inter-AS TE LSP setup from R0 to R6, with example paths p1, p2 each. Delete "each" ==== Section 5.2 What was the point of the discussion of the FRR bypass tunnels? They didn't feature in the example at all, and only served to add confusion. It would seem that you should move the discussion of FRR into section 6. ==== Section 6.1.3 For each protected inter-domain TE LSP traversing the boundary node to be protected, a NNHOP backup must be selected by the PLR. This requires the PLR to setup a bypass tunnel terminating at the NNHOP. Finding the NNHOP bypass tunnel of an inter-domain TE LSP can be achieved by analyzing the content of the RRO object received in the RSVP Resv message of both the bypass tunnel and the protected TE LSP(s) (see [NODE-ID]). You need to be clear (as you are for tunneled and stitched cases) that for inter-domain LSPs the RRO may well be masked. That is, in your example, the RRO reaching the PLR ASBR1 will only contain hops ASBR4 and ASBR7 (R3 having been masked as confidential). The AS number may have been inserted. So your tunnel B2 will not do the job and B3 will be needed (even though B2 is functional, you can't use it because you don't know whether it is functional). Further, as you pointed out earlier in the document, local policy may prevent the setup of TE LSPs that terminate within the domain. So B2 might not exist. Same comments do not apply to the use of B4 because it starts within the upstream domain. ==== Section 6.2 This section looks to be a bit pointless. What are you trying to say? Certainly you have not covered the need for disjoint paths (which is out of scope) but doesn't just work without some effort. You also haven't mentioned segment protection that applies signaling control to the positioning of one-to-one protection tunnels. ==== Section 7 The above mechanisms SHOULD be used for a contiguous inter-domain TE LSP to allow the head-end node of the inter-domain TE LSP to initiate make-before-break procedures. You may want to relax this "SHOULD" in the light of [LOOSE-REOPT] being informational, and describe the alternative procedures for reoptimization of contiguous LSPs. ==== Notify messages. You haven't described how Notify messages may be handled with respect to domain boundaries. ==== Section 11.2 I don't think you need to reference RSVP-UNNUM or BUNDLING. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Aug 2005 17:24:59 +0000 Date: Fri, 26 Aug 2005 10:23:44 -0700 From: Alex Zinin Reply-To: Alex Zinin Message-ID: <99619327.20050826102344@psg.com> To: "Adrian Farrel" CC: "Bill Fenner" , ccamp@ops.ietf.org Subject: Re: CCAMP Requests to add new milestones to its charter MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Adrian, Ack. Will review and discuss with the WG chairs. -- Alex http://www.psg.com/~zinin Wednesday, August 24, 2005, 4:50:52 AM, Adrian Farrel wrote: > Hi Alex and Bill, > The CCAMP working group has had further discussions about the potential > work it could do over the next 1.5 to 2 years. This has led us to produce > the following set of milestones with which there appears to be > overwhelming consensual support within the working group. > Therefore, we would like to ask you to arrange for us to have these > milestones added to our charter. > You will notice that the proposed milestones are unusually detailed. At > the moment we feel that this is important to help focus the working group > into the right activities and to ensure that we deliver. We could (of > course) drop the interim milestones from the charter if this would make > people more comfortable - we can still run the detailed milestones for our > own benefit. > At this stage we feel that it is not essential to modify the text of our > charter. Although we could take this opportunity to tidy it up and improve > the focus, we feel that all of the proposed milestones fall within the > existing charter work. > Please let us know your thoughts and what the next steps should be. > Thanks, > Adrian and Kireeti > ==== > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS > and OSPF > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh > membership > Nov 05 Submit ASON Routing evaluation I-D for IESG review > Nov 05 First version of WG I-D on path computation implementation advice > Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS > and OSPF > Nov 05 First version WG I-D MPLS to GMPLS migration strategies > Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS > Nov 05 First version WG I-D Change of LSP ownership between management and > control planes > Dec 05 First version of WG I-D for ASON Routing solutions > Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG > review > Dec 05 Submit Per-domain path computation signaling I-D for IESG review > Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region > Networks > Dec 05 First version WG I-D for Evaluation of existing protocols for > MLN/MRN > Dec 05 First version WG I-D for Protocol solutions for MLN/MRN > Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG > review > Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review > Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module > Jan 06 First version WG Informational I-D for Analysis of inter-domain > issues for disjoint and protected paths > Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF > for IESG review > Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and > solutions > Jan 06 First version WG I-D GMPLS OAM Requirements > Jan 06 First version WG I-D Routing and signaling for link viability > constraints > Feb 06 Submit LSP Stitching I-D for IESG review > Mar 06 First version of WG informational I-D Aligning GMPLS protocols > across the standards bodies > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for > IESG review > Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module > Mar 06 First version of WG I-D for additional MIB module to cover RSVP-TE > signaling extensions > Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for > IESG review > Jun 06 Submit Informational I-D for Analysis of inter-domain issues for > disjoint and protected paths for IESG review > Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review > Jun 06 Submit Change of LSP ownership between management and control > planes I-D for IESG review > Aug 06 Submit path computation implementation advice I-D for IESG review > Oct 06 Submit ASON Routing solutions I-D for IESG review > Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D > for IESG review > Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG review > Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for > IESG review > Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review > Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review > Dec 06 Submit GMPLS OAM Requirements I-D for IESG review > Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review > Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review > Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor > and IESG review > Oct 07 Submit Routing and signaling for link viability constraints I-D for > IESG review > Oct 07 Recharter or close Working Group Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 26 Aug 2005 15:01:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Final draft of response to the OIF Date: Fri, 26 Aug 2005 09:57:07 -0500 Message-ID: Thread-Topic: Final draft of response to the OIF Thread-Index: AcWqMXrRFH6Zn8PbTZ+MdFV9yog1bAAHBWYQ From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi Adrian, I proposed a simple (and I think technically sound) solution to item #1 and saw no objections, however the answer has not changed. I do not understand the reason for different encodings for VC-4 and STS-3c SPE. I think they should be the same, unless there is a technical need to distinguish them. I also do not understand the RCC=1 NCC=1 encoding, since the rule contained in the current RFC actually makes more sense. If there is only one signal element, there is no contiguous concatenation, by definition. So I fail to see the usefulness of these encodings. Regards, Ben > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Friday, August 26, 2005 6:27 AM > To: ccamp@ops.ietf.org > Subject: Final draft of response to the OIF > > Thanks to all who have commented so far. > > Here is an updated draft. I plan to send by the end of > August, so furhter > comments should be made quickly. > > Thanks, > Adrian > > ====== > > 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. > > 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. > > We believe that this final sentence should read "greater than > or equal to > 1," and that this interpretation resolves all of your issues > and makes the > text consistent with the examples. > > We plan to issue a revision to RFC 3946 to make this > clarification. The > text of this clarification still needs to be agreed by the > CCAMP working > group, but the draft revision contains the nodes as updated > below with the > addition of a third note as shown. > > 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 implies a number of contiguous components greater than or > equal to 1. > > Note 3: Following these rules, when requesting a VC-4 signal, the > RCC and the NCC values must be set to 0 whereas for an > STS-3c SPE > signal, the RCC and the NCC values must be set 1. However, if > local conditions allow and since the setting of the RCC and NCC > values is locally driven, the requesting upstream node MAY set > the RCC and NCC values to either SDH or SONET settings without > impacting the function. Moreover, the downstream node SHOULD > accept the requested values if local conditions allow. If these > values can not be supported, the receiver downstream node MUST > generate a PathErr/NOTIFICATION message (see Sections 2.2 and > 2.3, respectively). > > > 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 is currently discussing the use of GMPLS for > control of Ethernet devices. We will respond to this point in > a separate > email. > > Best regards, > Adrian Farrel > Kireeti Kompella > > ============================================================ 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: Fri, 26 Aug 2005 11:29:10 +0000 Message-ID: <0be801c5aa31$73753df0$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Final draft of response to the OIF Date: Fri, 26 Aug 2005 12:27:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks to all who have commented so far. Here is an updated draft. I plan to send by the end of August, so furhter comments should be made quickly. Thanks, Adrian ====== 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. 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. We believe that this final sentence should read "greater than or equal to 1," and that this interpretation resolves all of your issues and makes the text consistent with the examples. We plan to issue a revision to RFC 3946 to make this clarification. The text of this clarification still needs to be agreed by the CCAMP working group, but the draft revision contains the nodes as updated below with the addition of a third note as shown. 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 implies a number of contiguous components greater than or equal to 1. Note 3: Following these rules, when requesting a VC-4 signal, the RCC and the NCC values must be set to 0 whereas for an STS-3c SPE signal, the RCC and the NCC values must be set 1. However, if local conditions allow and since the setting of the RCC and NCC values is locally driven, the requesting upstream node MAY set the RCC and NCC values to either SDH or SONET settings without impacting the function. Moreover, the downstream node SHOULD accept the requested values if local conditions allow. If these values can not be supported, the receiver downstream node MUST generate a PathErr/NOTIFICATION message (see Sections 2.2 and 2.3, respectively). > 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 is currently discussing the use of GMPLS for control of Ethernet devices. We will respond to this point in a separate email. Best regards, Adrian Farrel Kireeti Kompella Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 25 Aug 2005 00:29:10 +0000 Message-ID: <430D108C.80802@kddilabs.jp> Date: Thu, 25 Aug 2005 09:27:56 +0900 From: Tomohiro Otani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511 MIME-Version: 1.0 To: Adrian Farrel Cc: ccamp@ops.ietf.org Subject: Re: Not voting on the charter milestones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello everyone, I agree with the proposed new milestones. Regards, tomo Adrian Farrel wrote: >Hi, > >Of course we don't vote, but Kireeti and I do need evidence of rough >consensus. We have a had a good number of emails picking up on small >points, but nothing of any substance said against the proposed milestones. >We have some evidence of general support. > >Can you please speak up. >Do you broadly support the proposed new CCAMP milestones? > >Thanks, >Adrian > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Aug 2005 19:40:08 +0000 Reply-To: From: "Vishal Sharma" To: "'Adrian Farrel'" , Subject: RE: Not voting on the charter milestones Date: Wed, 24 Aug 2005 12:37:39 -0700 Organization: Metanoia, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcWmbuPlOguWax5UTvebX8Nf64ZezwCdDp4A Message-Id: Adrian, > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, August 21, 2005 9:39 AM > To: ccamp@ops.ietf.org > Subject: Not voting on the charter milestones > > Hi, > > Of course we don't vote, but Kireeti and I do need evidence > of rough consensus. We have a had a good number of emails > picking up on small points, but nothing of any substance said > against the proposed milestones. > We have some evidence of general support. > > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? Yes. (Perhaps a few things will need to be refined as the discussion proceeds further, but I think broadly it is a good set of milestones -- and kudos on taking the time to get them down to such detail.) -Vishal Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Aug 2005 11:50:53 +0000 Message-ID: <045301c5a8a2$46bb8570$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Bill Fenner" Cc: Subject: CCAMP Requests to add new milestones to its charter Date: Wed, 24 Aug 2005 12:50:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Alex and Bill, The CCAMP working group has had further discussions about the potential work it could do over the next 1.5 to 2 years. This has led us to produce the following set of milestones with which there appears to be overwhelming consensual support within the working group. Therefore, we would like to ask you to arrange for us to have these milestones added to our charter. You will notice that the proposed milestones are unusually detailed. At the moment we feel that this is important to help focus the working group into the right activities and to ensure that we deliver. We could (of course) drop the interim milestones from the charter if this would make people more comfortable - we can still run the detailed milestones for our own benefit. At this stage we feel that it is not essential to modify the text of our charter. Although we could take this opportunity to tidy it up and improve the focus, we feel that all of the proposed milestones fall within the existing charter work. Please let us know your thoughts and what the next steps should be. Thanks, Adrian and Kireeti ==== Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh membership Nov 05 Submit ASON Routing evaluation I-D for IESG review Nov 05 First version of WG I-D on path computation implementation advice Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF Nov 05 First version WG I-D MPLS to GMPLS migration strategies Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS Nov 05 First version WG I-D Change of LSP ownership between management and control planes Dec 05 First version of WG I-D for ASON Routing solutions Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review Dec 05 Submit Per-domain path computation signaling I-D for IESG review Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region Networks Dec 05 First version WG I-D for Evaluation of existing protocols for MLN/MRN Dec 05 First version WG I-D for Protocol solutions for MLN/MRN Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG review Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module Jan 06 First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and solutions Jan 06 First version WG I-D GMPLS OAM Requirements Jan 06 First version WG I-D Routing and signaling for link viability constraints Feb 06 Submit LSP Stitching I-D for IESG review Mar 06 First version of WG informational I-D Aligning GMPLS protocols across the standards bodies Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for IESG review Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module Mar 06 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review Jun 06 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review Jun 06 Submit Change of LSP ownership between management and control planes I-D for IESG review Aug 06 Submit path computation implementation advice I-D for IESG review Oct 06 Submit ASON Routing solutions I-D for IESG review Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG review Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Dec 06 Submit GMPLS OAM Requirements I-D for IESG review Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review Oct 07 Submit Routing and signaling for link viability constraints I-D for IESG review Oct 07 Recharter or close Working Group Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Aug 2005 09:16:11 +0000 Thread-Topic: L2SC [Was: Moving forward with the CCAMP charter] thread-index: AcWojHscJFB6MppNR0qz2reOZpx7VQ== Reply-To: "CHO, JAI HYUNG" From: "CHO, JAI HYUNG" To: "Adrian Farrel" , Cc: Bcc: Subject: RE: L2SC [Was: Moving forward with the CCAMP charter] Date: Wed, 24 Aug 2005 18:16:16 +0900 Comment: GQ19@|@ZEk=E?,18?x, BcN1b MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message A bit late in this response, but..... I do support the proposed CCAMP milestone, and, just in case if L2SC work is considered as new WG/BoF, I'd most welcome such idea, and will support the new WG. thanks Dr. Jaihyung Cho ETRI, Korea phone : 042) 860-5514 oversea: +82-42-860-5514 fax: +82-42-861-5550 -----?? ???----- From: "Adrian Farrel" >From Date: 2005-08-17 ?? 6:20:04 To: "CHO, JAI HYUNG" , "ccamp@ops.ietf.org" Cc: Subject: L2SC [Was: Moving forward with the CCAMP charter] Hi Jaihyung, The Ethernet GMPLS work has certainly not been forgotten! The work of the design team is very important and we need more people to read and digest draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt. it is particularly important that folk read this draft rather than relying on scare stories or email threads. Many of the common concerns and issues have been carefully answered by the DT, and many of the other are not actually raised in this draft. For the moment, the CCAMP list remains the correct place to discuss these issues, but it would seem that the work involved is both larger than the scope of the CCAMP charter and larger than can be easily swallowed by the existing working group (you will have noticed that there are plenty of other things to occupy the WG's time). For this reason (and see the CCAMP draft minutes) we are currently investigating whether there could be a better home for this work. The most obvious solution is to create a new WG, but this would obviously require careful scoping and also would need support from the community. More information on this as it becomes available. Thanks, Adrian ----- Original Message ----- From: "CHO, JAI HYUNG" To: "Adrian Farrel" ; Sent: Wednesday, August 17, 2005 9:10 AM Subject: RE: Moving forward with the CCAMP charter > > Hi, Adrian > > Thank you for your milestone work. > However, I can not find L2SC work in your document. > Where does it belong to ? > I believe there's some number of people supporting thie work > and also we see clear industry need for this work. > I think it would be good if we have L2SC milestone > at least for framework and solution document. > > thanks > > Jaihyung > > > Dr. Jaihyung Cho > ETRI, Korea > phone : 042) 860-5514 > oversea: +82-42-860-5514 > fax: +82-42-861-5550 > > > > > -----?? ???----- > From: "Adrian Farrel" > From Date: 2005-08-16 ?? 8:28:11 > To: "ccamp@ops.ietf.org" > Cc: "zinin@psg.com" , "'Kireeti Kompella'" > Subject: Moving forward with the CCAMP charter > > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. > > This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. > > Thanks, > Adrian > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Aug 2005 07:12:26 +0000 Thread-Topic: Not voting on the charter milestones thread-index: AcWoe1Z9+tofRS/4THmCwlpAVSe9/Q== Content-Transfer-Encoding: 7bit Reply-To: =?ks_c_5601-1987?B?sei/tcit?= From: =?ks_c_5601-1987?B?sei/tcit?= To: "Adrian Farrel" , Cc: Bcc: Subject: RE: Not voting on the charter milestones Date: Wed, 24 Aug 2005 16:13:33 +0900 Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBPQU2x4rz6xsAsILTjtOc=?= Message-ID: <851501c5a87b$5681d440$8310fe81@email1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_8510_01C5A8C6.C6673250" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_8510_01C5A8C6.C6673250 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ------=_NextPart_000_8510_01C5A8C6.C6673250 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy Ij4NCjxESVY+PEJSPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+Jmd0OyA8U1RS T05HPkZyb206PC9TVFJPTkc+ICJBZHJpYW4gRmFycmVsIiAmbHQ7YWRyaWFuQG9sZGRvZy5jby51 ayZndDs8QlI+Jmd0OyA8U1RST05HPkZyb20gRGF0ZTo8L1NUUk9ORz4gMjAwNS0wOC0yMiC/wMD8 IDE6Mzk6MDg8QlI+Jmd0OyA8U1RST05HPlRvOjwvU1RST05HPiAiY2NhbXBAb3BzLmlldGYub3Jn IiAmbHQ7Y2NhbXBAb3BzLmlldGYub3JnJmd0OzxCUj4mZ3Q7IDxTVFJPTkc+Q2M6PC9TVFJPTkc+ IDxCUj4mZ3Q7IDxTVFJPTkc+U3ViamVjdDo8L1NUUk9ORz4gTm90IHZvdGluZyBvbiB0aGUgY2hh cnRlciBtaWxlc3RvbmVzPEJSPiZndDsgPEJSPg0KPERJVj48IS0tIENvbnZlcnRlZCBmcm9tIHRl eHQvcGxhaW4gZm9ybWF0IC0tPiZndDsgPEJSPg0KPFA+PEZPTlQgc2l6ZT0yPiZndDsgSGksPEJS PiZndDsgPEJSPiZndDsgT2YgY291cnNlIHdlIGRvbid0IHZvdGUsIGJ1dCBLaXJlZXRpIGFuZCBJ IGRvIG5lZWQgZXZpZGVuY2Ugb2Ygcm91Z2g8QlI+Jmd0OyBjb25zZW5zdXMuIFdlIGhhdmUgYSBo YWQgYSBnb29kIG51bWJlciBvZiBlbWFpbHMgcGlja2luZyB1cCBvbiBzbWFsbDxCUj4mZ3Q7IHBv aW50cywgYnV0IG5vdGhpbmcgb2YgYW55IHN1YnN0YW5jZSBzYWlkIGFnYWluc3QgdGhlIHByb3Bv c2VkIG1pbGVzdG9uZXMuPEJSPiZndDsgV2UgaGF2ZSBzb21lIGV2aWRlbmNlIG9mIGdlbmVyYWwg c3VwcG9ydC48QlI+Jmd0OyA8QlI+Jmd0OyBDYW4geW91IHBsZWFzZSBzcGVhayB1cC48QlI+Jmd0 OyBEbyB5b3UgYnJvYWRseSBzdXBwb3J0IHRoZSBwcm9wb3NlZCBuZXcgQ0NBTVAgbWlsZXN0b25l cz88QlI+PC9GT05UPjwvUD4NCjxQPjxGT05UIHNpemU9Mj5ZZXMsPEJSPjxCUj5UaGFua3M8QlI+ PEJSPlJlZ2FyZHMuLi4gWW91bmc8QlI+PEJSPiZndDsgVGhhbmtzLDxCUj4mZ3Q7IEFkcmlhbjxC Uj4mZ3Q7PEJSPjwvUD48L0ZPTlQ+PC9ESVY+PC9ESVY+PC9ESVY+PGltZyBzdHlsZT0iZGlzcGxh eTpub25lIiB3aWR0aD0wIGhlaWdodD0wIHNyYz0iaHR0cDovL3VtYWlsLmV0cmkucmUua3IvRXh0 ZXJuYWxfUmVhZENoZWNrLmFzcHg/ZW1haWw9Y2NhbXBAb3BzLmlldGYub3JnJm5hbWU9Y2NhbXAl NDBvcHMuaWV0Zi5vcmcmZnJvbWVtYWlsPXlod2tpbUBldHJpLnJlLmtyJm1lc3NhZ2VpZD0lM0My ZDJlYWQ3Ni02YjFjLTRhY2EtOTZkZS1jNzFiZjg5OGFkM2FAZXRyaS5yZS5rciUzRSI+ ------=_NextPart_000_8510_01C5A8C6.C6673250-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Aug 2005 06:27:00 +0000 Message-Id: <6.0.0.20.2.20050824152348.05480d08@imb.m.ecl.ntt.co.jp> Date: Wed, 24 Aug 2005 15:25:29 +0900 To: From: "inoue.ichiro@lab.ntt.co.jp" Subject: RE: Not voting on the charter milestones Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Hi, Yes, I support. Ichiro Inoue -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Sunday, August 21, 2005 12:39 PM To: ccamp@ops.ietf.org Subject: Not voting on the charter milestones Hi, Of course we don't vote, but Kireeti and I do need evidence of rough consensus. We have a had a good number of emails picking up on small points, but nothing of any substance said against the proposed milestones. We have some evidence of general support. Can you please speak up. Do you broadly support the proposed new CCAMP milestones? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 24 Aug 2005 05:13:40 +0000 Message-ID: <430C0187.2030307@psg.com> Date: Wed, 24 Aug 2005 07:11:35 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Arun Satyanarayana CC: Adrian Farrel , Lou Berger , Dimitri Papadimitriou , Reshad Rahman , Anca Zamfir , Junaid Israr , ccamp@ops.ietf.org Subject: Re: Nit in draft-ietf-ccamp-rsvp-restart-ext-03.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi arun, would it be possible to have a small record of the changes to post on the mailing list - thanks, - dimitri. Arun Satyanarayana wrote: > Hi Adrian, > > Thanks for catching the typo. > > There was also another minor comment during last call (addressed to Lou > privately, I believe). We'll re-spin by the end of the week. > > Thanks, > Arun > ============================================================== > Adrian Farrel wrote: > >> Hi, >> >> Looks like the extra last call on this I-D completed without further >> comment. >> >> Unfortunately, scanning through the draft I found a nit. >> So you need to do a quick re-spin. I think this should take you less than >> an hour. Please let me know if you can't do it by the end of the week and >> I will do it myself. >> >> Thanks, >> Adrian >> === >> Section 2 >> Spurious text relating to cross-references >> The reader is assumed to be familiar with the terminology defined in >> xref target="RFC3209" /> and [RFC3473]. > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Aug 2005 19:38:59 +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: Not voting on the charter milestones Date: Tue, 23 Aug 2005 14:38:47 -0500 Message-ID: <449B2580D802A443A923DABF3EAB82AF0A54A77C@OCCLUST04EVS1.ugd.att.com> Thread-Topic: Not voting on the charter milestones Thread-Index: AcWmbt6g16FomRzfTzOiffPJjVl96QBq07nw From: "Brungard, Deborah A, ALABS" To: "Adrian Farrel" , Yes- Deborah=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Sunday, August 21, 2005 12:39 PM To: ccamp@ops.ietf.org Subject: Not voting on the charter milestones Hi, Of course we don't vote, but Kireeti and I do need evidence of rough consensus. We have a had a good number of emails picking up on small points, but nothing of any substance said against the proposed milestones. We have some evidence of general support. Can you please speak up. Do you broadly support the proposed new CCAMP milestones? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Aug 2005 19:35:32 +0000 Message-ID: <03a601c5a819$f3448550$c5919ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: ASON Routing evaluation ready for WG last call? Date: Tue, 23 Aug 2005 20:34:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Just a reminder. Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, August 11, 2005 4:31 PM Subject: ASON Routing evaluation ready for WG last call? > Hi, > > draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt > > The DT said in Paris that this I-D is cooked apart from "some minor > editing". > > I asked the room if anyone would object to a WG last call now, and Alex > (as AD) suggested that more people should read the I-D before we decided > whether it was ready for last call. > > This gives me the odd position of having a last call for a last call :-) > > This email gives notice that you need to read this I-D and make comments > before 11th September 2005. > > Barring unresolved comments we will have a WG last call starting then. > > Thanks, > Adrian > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 23 Aug 2005 10:23:51 +0000 Message-ID: <430AF8C4.6050804@grotto-networking.com> Date: Tue, 23 Aug 2005 03:21:56 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Not voting on the charter milestones Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes. Greg B. Adrian Farrel wrote: >Hi, > >Of course we don't vote, but Kireeti and I do need evidence of rough >consensus. We have a had a good number of emails picking up on small >points, but nothing of any substance said against the proposed milestones. >We have some evidence of general support. > >Can you please speak up. >Do you broadly support the proposed new CCAMP milestones? > >Thanks, >Adrian > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Aug 2005 17:10:06 +0000 Message-ID: <430A0685.4060401@cisco.com> Date: Mon, 22 Aug 2005 10:08:21 -0700 From: Arun Satyanarayana Organization: Cisco Systems User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Adrian Farrel CC: Lou Berger , Dimitri Papadimitriou , Reshad Rahman , Anca Zamfir , Junaid Israr , ccamp@ops.ietf.org, "Arun Satyanarayana (asatyana)" Subject: Re: Nit in draft-ietf-ccamp-rsvp-restart-ext-03.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, Thanks for catching the typo. There was also another minor comment during last call (addressed to Lou privately, I believe). We'll re-spin by the end of the week. Thanks, Arun ============================================================== Adrian Farrel wrote: > Hi, > > Looks like the extra last call on this I-D completed without further > comment. > > Unfortunately, scanning through the draft I found a nit. > So you need to do a quick re-spin. I think this should take you less than > an hour. Please let me know if you can't do it by the end of the week and > I will do it myself. > > Thanks, > Adrian > === > Section 2 > Spurious text relating to cross-references > The reader is assumed to be familiar with the terminology defined in > xref target="RFC3209" /> and [RFC3473]. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Aug 2005 12:27:53 +0000 Subject: Re: Not voting on the charter milestones Sensitivity: To: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Mon, 22 Aug 2005 14:27:46 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Yes Regards Diego "Adrian Farrel" @ops.ietf.org on 21/08/2005 18.39.08 Please respond to "Adrian Farrel" Sent by: owner-ccamp@ops.ietf.org To: cc: Subject: Not voting on the charter milestones Hi, Of course we don't vote, but Kireeti and I do need evidence of rough consensus. We have a had a good number of emails picking up on small points, but nothing of any substance said against the proposed milestones. We have some evidence of general support. Can you please speak up. Do you broadly support the proposed new CCAMP milestones? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Aug 2005 12:03:51 +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: Not voting on the charter milestones Date: Mon, 22 Aug 2005 07:03:22 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA09FA9238@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Not voting on the charter milestones Thread-Index: AcWmbt71a7K6t/X4Th2dtw6VLK2jPQAol0cQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" Hi Adrian, > Do you broadly support the proposed new CCAMP milestones? Looks good, I like the detail.=20 Thanks, Jerry Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Aug 2005 11:49:36 +0000 Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A98A581-3CDF-4A63-8967-3F480C4E65CC@cisco.com> Cc: Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: Not voting on the charter milestones Date: Mon, 22 Aug 2005 07:47:41 -0400 To: "Adrian Farrel" They look okay to me. --Tom > Hi, > > Of course we don't vote, but Kireeti and I do need evidence of rough > consensus. We have a had a good number of emails picking up on small > points, but nothing of any substance said against the proposed > milestones. > We have some evidence of general support. > > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? > > Thanks, > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Aug 2005 08:26:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Not voting on the charter milestones Date: Mon, 22 Aug 2005 10:26:42 +0200 Message-ID: Thread-Topic: Not voting on the charter milestones Thread-Index: AcWmbzUyLYWoln7dQ6yju4/6iFZnkgAg/OSw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , Hi Adrian, all The proposed milestones sound good to me Regards JL=20 > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Adrian Farrel > Envoy=E9 : dimanche 21 ao=FBt 2005 18:39 > =C0 : ccamp@ops.ietf.org > Objet : Not voting on the charter milestones >=20 > Hi, >=20 > Of course we don't vote, but Kireeti and I do need evidence=20 > of rough consensus. We have a had a good number of emails=20 > picking up on small points, but nothing of any substance said=20 > against the proposed milestones. > We have some evidence of general support. >=20 > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? >=20 > Thanks, > Adrian >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 22 Aug 2005 08:04:29 +0000 Message-Id: From: Michael.Dueser@t-systems.com To: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: AW: Not voting on the charter milestones Date: Mon, 22 Aug 2005 10:00:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support the list of CCAMP milestones. Michael=20 -----Urspr=FCngliche Nachricht----- Von: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] Im = Auftrag von Adrian Farrel Gesendet: Sonntag, 21. August 2005 18:39 An: ccamp@ops.ietf.org Betreff: Not voting on the charter milestones Hi, Of course we don't vote, but Kireeti and I do need evidence of rough = consensus. We have a had a good number of emails picking up on small = points, but nothing of any substance said against the proposed = milestones. We have some evidence of general support. Can you please speak up. Do you broadly support the proposed new CCAMP milestones? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Aug 2005 23:26:13 +0000 Message-ID: <43090D56.8080100@kddilabs.jp> Date: Mon, 22 Aug 2005 08:25:10 +0900 From: Tomohiro Otani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511 MIME-Version: 1.0 To: Adrian Farrel Cc: JP Vasseur , ccamp@ops.ietf.org, zinin@psg.com, 'Kireeti Kompella' Subject: Re: Inter-AS GMPLS [Was: Moving forward with the CCAMP charter] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Adrian, Thank you for your e-mail message clarifying my comments. I agree with your proposed milestone. One point is that as you mentioned, our draft covers; 1. TE reachability information exchange 2. Exchange of aggregated TE information for a domain In addition to these, in our draft, I also assume that GMPLS inter-domain routing is required to exchange reachability information. The draft should be short enough to clarify whether we rely on the same (existing) protocol mechanism as IP/MPLS. Regards, tomo Adrian Farrel wrote: >Hi Tomo, > >> Being related with your text and JP's messages, I would ask you >> to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt. >> Is this related with a kind of baseline for (1) Analysis of inter-domain >> issues ? >> >> So far, there is a proposed draft of GMPLS inter-domain signaling >> as we discussed in Paris, but there is no draft of GMPLS inter-domain >> routing definition whether it is with TE extension or not. >> (your framework draft covers these points) > >Good point. > >It seems that your draft is discussing two things: >1. TE reachability information exchange >2. Exchange of aggregated TE information for a domain > >As you point out in section 4.2, the issue of scalability and policy needs >to be carefully considered before we pursue this too much further. > >I think your work, especially the aggregation issues, meshes nicely with >the recent draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt. Therefore, I >propose the following changes to the draft I sent out before... > >1. Delete > Jan 06 First version WG I-D Routing and signaling for complex optical >constraints > Oct 07 Submit Routing and signaling for complex optical constraints I-D >for IESG review >2. Insert > Jan 06 First version WG I-D Routing and signaling for link viability >constraints > Oct 07 Submit Routing and signaling for link viability constraints I-D >for IESG review >3. Delete > More forward-looking > ==================== > Routing and signaling for complex constraints and inter-domain > * first version of WG draft > - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt > * submit for IESG review >4. Add to Inter-domain section > - Analysis and protocol changes for routing and signaling for link >viability constraints > * first version of WG draft > - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt > - material from draft-otani-ccamp-interas-gmpls-te-03.txt > * submit for IESG review > >Cheers, >Adrian > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Aug 2005 20:48:59 +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: Not voting on the charter milestones Date: Sun, 21 Aug 2005 16:48:31 -0400 Message-ID: Thread-Topic: Not voting on the charter milestones Thread-Index: AcWmbud8OjthYAmWQImq+VkWpxd/FwAIiSrw From: "Zafar Ali \(zali\)" To: "Adrian Farrel" , > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, August 21, 2005 12:39 PM > To: ccamp@ops.ietf.org > Subject: Not voting on the charter milestones >=20 > Hi, >=20 > Of course we don't vote, but Kireeti and I do need evidence=20 > of rough consensus. We have a had a good number of emails=20 > picking up on small points, but nothing of any substance said=20 > against the proposed milestones. > We have some evidence of general support. >=20 > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? Yes,=20 Thanks Regards... Zafar=20 >=20 > Thanks, > Adrian >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Aug 2005 19:53:27 +0000 Message-ID: <4308DB4E.3010806@psg.com> Date: Sun, 21 Aug 2005 21:51:42 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Not voting on the charter milestones Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Adrian Farrel wrote: > Hi, > > Of course we don't vote, but Kireeti and I do need evidence of rough > consensus. We have a had a good number of emails picking up on small > points, but nothing of any substance said against the proposed milestones. > We have some evidence of general support. > > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? yes - -d. > Thanks, > Adrian > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Aug 2005 17:35:31 +0000 Message-ID: <4308BB41.9090406@pi.se> Date: Sun, 21 Aug 2005 19:34:57 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Not voting on the charter milestones Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit yes /Loa Adrian Farrel wrote: > Hi, > > Of course we don't vote, but Kireeti and I do need evidence of rough > consensus. We have a had a good number of emails picking up on small > points, but nothing of any substance said against the proposed milestones. > We have some evidence of general support. > > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? > > Thanks, > Adrian > > > -- 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: Sun, 21 Aug 2005 17:17:42 +0000 Message-ID: <4308B716.1080505@us.fujitsu.com> Date: Sun, 21 Aug 2005 10:17:10 -0700 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org Subject: Re: Not voting on the charter milestones Content-Type: multipart/mixed; boundary="------------080106010802050204020304" This is a multi-part message in MIME format. --------------080106010802050204020304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit yes Adrian Farrel wrote: >Hi, > >Of course we don't vote, but Kireeti and I do need evidence of rough >consensus. We have a had a good number of emails picking up on small >points, but nothing of any substance said against the proposed milestones. >We have some evidence of general support. > >Can you please speak up. >Do you broadly support the proposed new CCAMP milestones? > >Thanks, >Adrian > > > > --------------080106010802050204020304 Content-Type: text/x-vcard; charset=utf-8; name="richard.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="richard.vcf" begin:vcard fn:Richard Rabbat n:Rabbat;Richard org:Fujitsu Labs of America;IP Networking Research adr:MS 345;;1240 East Arques Ave;Sunnyvale;CA;94085;USA email;internet:richard@us.fujitsu.com title:Senior Project Manager tel;work:1-408-530-4537 tel;fax:1-408-530-4515 tel;cell:1-650-714-7618 x-mozilla-html:TRUE version:2.1 end:vcard --------------080106010802050204020304-- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Aug 2005 16:44:20 +0000 Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6DFECA70-2C77-403A-90F2-0A958ABB4767@cisco.com> Cc: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: Not voting on the charter milestones Date: Sun, 21 Aug 2005 12:44:34 -0400 To: "Adrian Farrel" On Aug 21, 2005, at 12:39 PM, Adrian Farrel wrote: > Hi, > > Of course we don't vote, but Kireeti and I do need evidence of rough > consensus. We have a had a good number of emails picking up on small > points, but nothing of any substance said against the proposed > milestones. > We have some evidence of general support. > > Can you please speak up. > Do you broadly support the proposed new CCAMP milestones? > Yes, JP. > Thanks, > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Aug 2005 16:39:01 +0000 Message-ID: <012c01c5a66f$1672a540$20849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Not voting on the charter milestones Date: Sun, 21 Aug 2005 17:39:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Of course we don't vote, but Kireeti and I do need evidence of rough consensus. We have a had a good number of emails picking up on small points, but nothing of any substance said against the proposed milestones. We have some evidence of general support. Can you please speak up. Do you broadly support the proposed new CCAMP milestones? Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Aug 2005 15:10:39 +0000 Message-ID: <00e301c5a662$9baba390$20849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lou Berger" , "Dimitri Papadimitriou" , "Reshad Rahman" , "Anca Zamfir" , "Junaid Israr" , "Arun Satyanarayana \(asatyana\)" Cc: Subject: Nit in draft-ietf-ccamp-rsvp-restart-ext-03.txt Date: Sun, 21 Aug 2005 16:11:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Looks like the extra last call on this I-D completed without further comment. Unfortunately, scanning through the draft I found a nit. So you need to do a quick re-spin. I think this should take you less than an hour. Please let me know if you can't do it by the end of the week and I will do it myself. Thanks, Adrian === Section 2 Spurious text relating to cross-references The reader is assumed to be familiar with the terminology defined in xref target="RFC3209" /> and [RFC3473]. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 21 Aug 2005 10:00:19 +0000 Message-ID: <43085065.3080504@chello.nl> Date: Sun, 21 Aug 2005 11:59:01 +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: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be CC: ccamp Subject: Re: MS-SPring Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Dimitri, I agree with you on both points. - no restriction of the scope: linear + ring protection - the fundamentals in Diego's document with references to relevant (standard) documents and articles. Cheers, Huub. > Huub, > > [snip] > >>> ok, btw, is there a reason to restrict to MS/line protection ring ? >> >> >> If you refer to the APS protocol, this can be used in ring >> protection and linear protection, because it operates between >> source and sink of a trail or LSP. >> In its most simple form it provides 1:1 protection, and more >> general N:M protection > > > i was referring to the scope of the document - should it be restricted > to MS/line shared protection ring or include other types (e.g. path > protection ring) - note: in my view not > >>>> The reconfiguration of the ring after this first switch is controlplane >>>> driven and concerns all nodes in the ring. >>> >>> >>> ok with this - like for other linear protection schemes the control >>> plane would be involved in the provisioning >>> >>> also, what about the (informational) notification to maintain the >>> control plane aware about the data plane status after failure >>> detection and/or after the APS operation >> >> >> Maybe it is a good idea to include a description in the document >> Diego is preparing (in the book on functional modeling I need >> six pages to describe this protection mechanism). > > > imho, an overview should be enough to skim the ring protection scheme > and the APS operation (no need to include full details that can be found > elsewhere) > >> Have a nice weekend, Huub. >> > -- ================================================================ 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: Sun, 21 Aug 2005 09:32:44 +0000 Message-ID: <430849C8.5040608@psg.com> Date: Sun, 21 Aug 2005 11:30:48 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Huub van Helvoort CC: dimitri.papadimitriou@alcatel.be, ccamp Subject: Re: MS-SPring Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Huub, [snip] >> ok, btw, is there a reason to restrict to MS/line protection ring ? > > If you refer to the APS protocol, this can be used in ring > protection and linear protection, because it operates between > source and sink of a trail or LSP. > In its most simple form it provides 1:1 protection, and more > general N:M protection i was referring to the scope of the document - should it be restricted to MS/line shared protection ring or include other types (e.g. path protection ring) - note: in my view not >>> The reconfiguration of the ring after this first switch is controlplane >>> driven and concerns all nodes in the ring. >> >> ok with this - like for other linear protection schemes the control >> plane would be involved in the provisioning >> >> also, what about the (informational) notification to maintain the >> control plane aware about the data plane status after failure >> detection and/or after the APS operation > > Maybe it is a good idea to include a description in the document > Diego is preparing (in the book on functional modeling I need > six pages to describe this protection mechanism). imho, an overview should be enough to skim the ring protection scheme and the APS operation (no need to include full details that can be found elsewhere) > Have a nice weekend, Huub. > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 20 Aug 2005 18:00:49 +0000 Message-Id: <5.1.1.9.2.20050821025715.05839b28@mailsv4.y.ecl.ntt.co.jp> Date: Sun, 21 Aug 2005 02:59:12 +0900 To: "Adrian Farrel" , From: Wataru Imajuku Subject: Re: Moving forward with the CCAMP charter Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Hi, Adrian Thanks. I'd like to do so. Best Regards Wataru >Hi, > >Thanks for your comments. > >Do you think it may be premature to apply 803.2ad techniques before we >have done any work to control Ethernet networks with GMPLS? > >You are right that IEEE link aggregation is conceptually very close to >bundling. > >I suggest that you need to separate TDM and Ethernet concepts in your I-D. >Take the TDM issues to Diego, Richard, Greg et alia for inclusion in the >VCAT/LCAS work. Take your LAGR issues to Dimitri and Loa for inclusion in >the "GMPLS control of Ethernet switching" work that they are doing. > >Thanks, >Adrian > >----- Original Message ----- >From: "Wataru Imajuku" >To: "Adrian Farrel" ; >Sent: Thursday, August 18, 2005 9:59 PM >Subject: Re: Moving forward with the CCAMP charter > > > > Hi, Adrian > > > > Thank you for giving your time interim your hard work. > > > > >With regard to your section 5, I note that you consider the VCAT group > > >analogous with a link bundle. I don't think this is correct because the > > >members of a link bundle must be selected and used individually. A >payload > > >data stream cannot be distributed across multiple component links of >the > > >bundle... > > > An LSP with a bandwidth requirement b and > > > setup priority p fits in a bundled link if at least one component > > > link has maximum LSP bandwidth >= b at priority p. > > >However, the whole point of a VCAT group is to produce a single entity > > >(pipe) with maximum LSP bandwidth greater than the capacity of any > > >individual component. A VCAT group, therefore, is not a bundle. > > > > > >Following on from this, I think that the remainder of your section 5.1 > > >will have some value, but needs to be corrected to properly reflect the > > >meaning of a VCAT group. > > > > > >In general, I think your section 5 should generalize from the specific > > >case of the FA to include any TE link that is based on a VCAT group. > > > > > >Section 5.2 seems to confuse "FA" with "FA LSP". > > > > Regarding to VCAT, I agree to your comment. > > But, this draft also covers LAGR (link aggregation) which has some >limitations > > to transmit data-flow exceeding the bandwidth of each comopnent LSP. > > > > This is one of reason why the description wirtten in Section 5 exists, >although > > some terminologies are not proper as you noted. > > --------------------------------- Wataru Imajuku Senior Research Engineer @NTT Network Innovation Labs. TEL +81-46-859-4315 FAX +81-46-859-5541 Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 20 Aug 2005 14:40:08 +0000 Message-ID: <43074099.8090703@chello.nl> Date: Sat, 20 Aug 2005 16:39:21 +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: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be CC: ccamp Subject: Re: MS-SPring Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Dimitri, You asked: > hi huub, > > Huub van Helvoort wrote: > >> Hallo Dimitri, >> >> You responded to Diego: >> >>> Diego Caviglia wrote: >>> >>>> Hi Dimitri, >>>> given the high number of MS-SPRing protected transport >>>> network >>>> already deployed seems reasonable to me, from a Network Operator >>>> point of >>>> view, to use at the same time MS-SPRing protection with GMPLS >>>> restoration. >>> >>> >>> there are already two questions here 1. is there an operational need >>> to control such rings using GMPLS (? for instance is it effective >>> knowing that ring based protection is mainly data plane driven ?) and >>> 2. how to position the ring protection wrt to the LSP recovery >>> segment/end-to-end recovery >> >> >> The first step in MS-Spring is indeed dataplane driven (using APS) >> but that involves only nodes adjacent to the fault. > > > ok, btw, is there a reason to restrict to MS/line protection ring ? If you refer to the APS protocol, this can be used in ring protection and linear protection, because it operates between source and sink of a trail or LSP. In its most simple form it provides 1:1 protection, and more general N:M protection >> The reconfiguration of the ring after this first switch is controlplane >> driven and concerns all nodes in the ring. > > ok with this - like for other linear protection schemes the control > plane would be involved in the provisioning > > also, what about the (informational) notification to maintain the > control plane aware about the data plane status after failure detection > and/or after the APS operation Maybe it is a good idea to include a description in the document Diego is preparing (in the book on functional modeling I need six pages to describe this protection mechanism). Have a nice weekend, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 20 Aug 2005 13:51:41 +0000 Message-ID: <430734E8.4000202@psg.com> Date: Sat, 20 Aug 2005 15:49:28 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Adrian Farrel CC: =?UTF-8?B?6rmA7JiB7ZmU?= , ccamp@ops.ietf.org, zinin@psg.com, 'Kireeti Kompella' Subject: Re: Control Plane Robustness [Was: Moving forward with the CCAMP charter] Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit adrian, Adrian Farrel wrote: [snip] > Thus my feeling at the moment is that Control Plane Robustness should be > an area that CCAMP looks at, but we should not set any specific > milestones. if you mean explicitly listed as part of the wg scope without explicit milestone i would agree, also, a way to avoid having to modify the charter each time a specific work item related to this area would need to be produced by the working group thanks, - dimitri. >>Of course, I think it's possible under the condition that the topic of >>control plane resilience could be handled in the CCAMP charter. > > > -----¢¯©ª¨¬¡í ¢¬¨­¨öAAo----- > From: "Adrian Farrel" >>From Date: 2005-08-16 ¢¯AEA 8:28:11 > To: "ccamp@ops.ietf.org" > Cc: "zinin@psg.com" , "'Kireeti Kompella'" > > Subject: Moving forward with the CCAMP charter > > > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the text on > this issue in the attached file. The bottom line is that this is a product > of micro management where I have tried to identify all of the I-Ds that we > might produce to cover the referenced work, and where I have placed two > (sometimes three) milestones for each I-D. > > This micro-management may be over the top, and represents a full pendulum > swing from the previous style of CCAMP milestones, but in the light of the > hiatus of the last 12 months, i think this may be beneficial and might > achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it wants to > commit to by the end of August. > > Thanks, > Adrian > > ----- Original Message ----- > From: "±è¿µÈ­" > To: "Adrian Farrel" ; > Cc: ; "'Kireeti Kompella'" > Sent: Friday, August 19, 2005 10:32 AM > Subject: RE: Moving forward with the CCAMP charter > > > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 20 Aug 2005 09:39:39 +0000 Message-ID: <001101c5a56b$025202e0$3b849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , Subject: Stability in the proposed CCAMP milestones Date: Sat, 20 Aug 2005 10:38:46 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01C5A573.57FD0930" This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C5A573.57FD0930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Still entertaining more input at this stage. Fairly soon we will need to take this to the ADs for their opinions. Thanks, Adrian ------=_NextPart_000_000D_01C5A573.57FD0930 Content-Type: text/plain; name="ccamp-milestones.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ccamp-milestones.txt" CCAMP Working Group - Rechartering Effort Below you will find - a list of proposed milestones - an explanation of why this is a long list - overview of proposed drafts and work items In reviewing this we should look for: - topics that are irrelevant or unwanted by the WG - topics that have been left out but are wanted by the WG - topics that have been assigned the wrong priority or urgency - topics or collections or topics that are sufficiently large to potentially warrant their own working group. Proposed New milestones ----------------------- Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS = and OSPF Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh = membership Nov 05 Submit ASON Routing evaluation I-D for IESG review Nov 05 First version of WG I-D on path computation implmentation advice Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in = ISIS and OSPF Nov 05 First version WG I-D MPLS to GMPLS migration strategies Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS Nov 05 First version WG I-D Change of LSP ownership between management = and control planes Dec 05 First version of WG I-D for ASON Routing solutions Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG = review Dec 05 Submit Per-domain path computation signaling I-D for IESG review Dec 05 First version WG I-D Requirements for Multi-Layer and = Multi-Region Networks Dec 05 First version WG I-D for Evaluation of existing protocols for = MLN/MRN Dec 05 First version WG I-D for Protocol solutions for MLN/MRN Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG = review Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module Jan 06 First version WG Informational I-D for Analysis of inter-domain = issues for disjoint and protected paths Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF = for IESG review Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and = solutions Jan 06 First version WG I-D GMPLS OAM Requirements Jan 06 First version WG I-D Routing and signaling for link viability = constraints Feb 06 Submit LSP Stitching I-D for IESG review Mar 06 First version of WG informational I-D Aligning GMPLS protocols = across the standards bodies Mar 06 Submit GMPLS routing and signaling interoperability advice I-D = for IESG review Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module Mar 06 First version of WG I-D for additional MIB module to cover = RSVP-TE signaling extensions Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for = IESG review Jun 06 Submit Informational I-D for Analysis of inter-domain issues for = disjoint and protected paths for IESG review Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review Jun 06 Submit Change of LSP ownership between management and control = planes I-D for IESG review Aug 06 Submit path computation implmentation advice I-D for IESG review Oct 06 Submit ASON Routing solutions I-D for IESG review Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D = for IESG review Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG = review Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for = IESG review Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Dec 06 Submit GMPLS OAM Requirements I-D for IESG review Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor = and IESG review Oct 07 Submit Routing and signaling for link viability constraints I-D = for IESG review Oct 07 Recharter or close Working Group Why so many milestons? ---------------------- The number of milestones shown in this proposed list far exceeds anything I have ever seen in a working group charter. This is intentional and while it does indicate a heavy work-load it also indicates a higher level of micro-management than is usual within working groups. Thus two milestones are presented for each I-D (adoption as a WG I-D, and passing to the IESG post-WG-last-call). This can be compared with the "normal" charter milestones which include a single work-related item that may span several I-Ds and refers vaguely only to the "submission" of I-Ds. In other words, reviewers of this list should not panic because of its length, but should see this as beneficial. Explanation of I-Ds and work items ---------------------------------- The following text briefly introduces the work items that are represented by the milestones listed above. In this text an astrix (*) indicates a milestone to be set. The work is divided into several categories according to how core it is and how it should be prioritized. Existing drafts are referenced to indicate that work is already in progress - this is not intended to provide a complete list of existing drafts. Completing existing work = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ASON - ASON Routing evaluation - already have draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt * submit for IESG review - ASON Routing solutions * first version of WG draft * submit for IESG review - GMPLS signaling in support of Call Management - already have draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt * submit for IESG review - GMPLS/ASON lexicography - already have draft-ietf-ccamp-gmpls-ason-lexicography-03.txt * submit for IESG review - Aligning GMPLS protocols across the standards bodies - Information I-D not intended for publication as an RFC * first version of WG draft Interoperability reports and advice - signaling and routing - already have draft-ietf-ccamp-gmpls-addressing-01.txt * submit for IESG review - path computation * first version of WG draft - based on draft-otani-ccamp-gmpls-cspf-constraints-01.txt * submit for IESG review Additional MIB modules - OSPF-TE * first version of WG draft - based on draft-otani-ccamp-gmpls-ospf-mib-00.txt * submit for IESG review - ISIS-TE * first version of WG draft * submit for IESG review - Signaling - Need "living" MIB module under development to catch the minor protocol extensions that have been made * first version of WG draft * submit for IESG review Inter-domain - LSP Stitching - already have draft-ietf-ccamp-lsp-stitching-01.txt * submit for IESG review - RSVP-TE extensions for interdomain - already have draft-ietf-ccamp-inter-domain-rsvp-te-01.txt * submit for IESG review - Per-domain path computation signaling - already have draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt * submit for IESG review - Analysis of inter-domain issues for disjoint and protected paths - Informational I-D to close off the topic and devolve to PCE * first version of WG draft * submit for IESG review - Analysis and protocol changes for routing and signaling for link = viability constraints * first version of WG draft - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt - material from draft-otani-ccamp-interas-gmpls-te-03.txt * submit for IESG review New items already started and within existing charter = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Advertising TE Node Capabilities - ISIS and OSPF in the same I-D * first version of WG draft - based on draft-vasseur-ccamp-te-node-cap-00.txt * review by IGP working groups * submit for IESG review Automatic discovery of MPLS-TE mesh membership - depends on TE Node capabilities I-D * first version of WG draft - based on draft-vasseur-ccamp-automesh-00.txt * submit for IESG review Multi-layer networks (also multi-region networks) - Requirements * first version of WG draft - based on draft-shiomoto-ccamp-gmpls-mrn-reqs-02.txt * submit for IESG review - Evaluation of existing protocols * first version of WG draft - based on draft-leroux-ccamp-gmpls-mrn-eval-01.txt * submit for IESG review - Solutions * first version of WG draft - based on draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt * submit for IESG review MPLS-GMPLS interworking requirements and solutions * first version of WG draft - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt - material from = draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt * submit for IESG review MPLS to GMPLS migration strategies * Informational I-D first version of WG draft - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt - material from = draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt * submit Informational I-D for IESG review Minor items just starting but close to heart of WG = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= GMPLS OAM Requirements - Interesting and worthwhile * first version of WG draft - based on immature = draft-nadeau-ccamp-gmpls-oam-requirements-00.txt * submit for IESG review Minor items just starting and important becuase of inter-SDO = interactions = =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=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 GMPLS coordination of VCAT and LCAS - single requirements and solutions draft almost an applicablity = statement * first version of WG draft - based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt * submit for IESG review Change of LSP ownership between management and control planes - single requirements and solutions draft defines one bit and a = procedure * first version of WG draft - based on draft-caviglia-mp2cpcp2mp-02.txt * submit for IESG review Other work items with no specific milestones identified yet = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Control Plane Robustness - draft-ali-ccamp-mpls-graceful-shutdown-xx.txt Graceful shutdown. - draft-leroux-ccamp-ctrl-saturation-01.txt Control Plane = Saturation - draft-kim-ccamp-cpr-reqts-00.txt Control Plane = Resilience - draft-kim-ccamp-cc-protection-04.txt Control Channel = Protection ------=_NextPart_000_000D_01C5A573.57FD0930-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Aug 2005 11:40:18 +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: Requesting a LSC LSP across a PCS interface Date: Fri, 19 Aug 2005 13:39:54 +0200 Message-ID: <81FEC275650AE14EBD5245E624762B9701ACED66@ds07.tnoase.telecom.tno.nl> Thread-Topic: Requesting a LSC LSP across a PCS interface Thread-Index: AcWkQsg0/RO6ZiiGSbSHPuZYQSJDeQAboLbg From: To: , Cc: =20 >=20 > hi, >=20 > > Consider the following situation: > >=20 > > Domain A <=3D | =3D> Domain B <=3D | =3D> = Domain C > > | | > > [A1]--PSC--[A2]--PSC--[B1]--LSC--[B2]--LSC--[B4]--PSC--[C1] > > | | | | > > |---PSC--[B3]--PSC---| > >=20 > >=20 > > Suppose I want to setup an (PSC) LSP from [A1] to [C1]. In domain B > > there are two options, the PSC route, or the LSC route. Is=20 > there a way > > to request (or hint for) a LSC LSP in domain B for the=20 > A1-C1 LSP? For > > example because the quality of the PSC path is deemed=20 > insufficient from > > the point of view of domains A and C (e.g. A and C are vey=20 > high bw LAN > > enviroments, B a WAN environment). >=20 > base on your diagram and assuming symmetric links both nodes=20 > B1 and B4=20 > must have a PSC and LSC switching capability so here and as=20 > provided in=20 > the diagram i assume the boundary is on the node; however, if=20 > you mean=20 > [B1,B4] and [B2,B4] being [PSC,LSC] and [LSC,PSC] resp. then=20 > B1 and B4=20 > are simple PSC nodes with LSC interfaces and then the=20 > boundary would be=20 > on the interface >=20 I envisioned the boundary on the node indeed. But on the interface could be an option as well. > now, if all domains are in the same routing area > - have strict path all along > - B4 loose hop with explicit indication of incoming interface >=20 Okay. > if all domains not in the same routing area > - make use of constaint passing by including (or excluding) specific=20 > switching capability such as to indicate which resource type to=20 > select/preclude in order to reach the destination B4 (loose hop) > So if I understand correctly, the LSP would be something like this: A1 to C1 via: A2 (strict), B1 (strict), B4 (loose, LSC), C1 (loose) =20 > hope this helps, Yes, thanks. Eduard > - dimitri. >=20 > > Thanks! > >=20 > > cheers, > > Eduard > >=20 > >=20 > >=20 > > . > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Aug 2005 11:25:50 +0000 Message-ID: <061201c5a4b1$10d13580$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Wataru Imajuku" Subject: Re: Moving forward with the CCAMP charter Date: Fri, 19 Aug 2005 12:20:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi, Thanks for your comments. Do you think it may be premature to apply 803.2ad techniques before we have done any work to control Ethernet networks with GMPLS? You are right that IEEE link aggregation is conceptually very close to bundling. I suggest that you need to separate TDM and Ethernet concepts in your I-D. Take the TDM issues to Diego, Richard, Greg et alia for inclusion in the VCAT/LCAS work. Take your LAGR issues to Dimitri and Loa for inclusion in the "GMPLS control of Ethernet switching" work that they are doing. Thanks, Adrian ----- Original Message ----- From: "Wataru Imajuku" To: "Adrian Farrel" ; Sent: Thursday, August 18, 2005 9:59 PM Subject: Re: Moving forward with the CCAMP charter > Hi, Adrian > > Thank you for giving your time interim your hard work. > > >With regard to your section 5, I note that you consider the VCAT group > >analogous with a link bundle. I don't think this is correct because the > >members of a link bundle must be selected and used individually. A payload > >data stream cannot be distributed across multiple component links of the > >bundle... > > An LSP with a bandwidth requirement b and > > setup priority p fits in a bundled link if at least one component > > link has maximum LSP bandwidth >= b at priority p. > >However, the whole point of a VCAT group is to produce a single entity > >(pipe) with maximum LSP bandwidth greater than the capacity of any > >individual component. A VCAT group, therefore, is not a bundle. > > > >Following on from this, I think that the remainder of your section 5.1 > >will have some value, but needs to be corrected to properly reflect the > >meaning of a VCAT group. > > > >In general, I think your section 5 should generalize from the specific > >case of the FA to include any TE link that is based on a VCAT group. > > > >Section 5.2 seems to confuse "FA" with "FA LSP". > > Regarding to VCAT, I agree to your comment. > But, this draft also covers LAGR (link aggregation) which has some limitations > to transmit data-flow exceeding the bandwidth of each comopnent LSP. > > This is one of reason why the description wirtten in Section 5 exists, although > some terminologies are not proper as you noted. > > Thanks > Wataru > > --------------------------------- > Wataru Imajuku > Senior Research Engineer > @NTT Network Innovation Labs. > TEL +81-46-859-4315 > FAX +81-46-859-5541 > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Aug 2005 11:25:42 +0000 Message-ID: <061101c5a4b1$0f829570$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ong, Lyndon" Cc: , , "Kireeti Kompella" Subject: Re: Moving forward with the CCAMP charter Date: Fri, 19 Aug 2005 12:15:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Lyndon, > As with everyone else, I appreciate all of the work that > you put in to create a very detailed workplan for the group. Thanks. > Some follow up questions and suggestions: > > -- On the "aligning GMPLS across standards bodies" item: > > First of all, what standards bodies do you see included under > this effort? Any and every that is or plans to use GMPLS or derive a variant of GMPLS. > Also, are you intending this to be a unilateral document on ccamp's > part? Yes. > If it is, I'm not sure I see what it would say besides "use the RFCs or > bring the requirements back to us", which is what this group has said in > the past. If on the other hand you see this as the basis for joint > discussion with other bodies, it might be a very helpful activity. First, I refuse to be hamstrung by history. Note that alignment requires that we start from where we are now (with non-interoperable variations of the protocols) and try to resolve the problem. Second, doing this work does not preclude discussing with other bodies. In fact, the draft is likely to lead specifically to discussions with other bodies. However, it is not pragmatic or wise to discuss with other bodies the actions which CCAMP thinks it should take. These are CCAMP actions. > -- On the ""routing and signaling for complex optical constraints" item: > > The ashwood draft seems to me to have two components, one being > requirements and considerations of routing across a purely photonic > domain and the second being a particular solution (the matrix > representation), to which there are alternatives such as the virtual link > approach that Igor has identified. > > I think these two should probably be separated, as the solution may be > more widely applied to any situation of advertising a virtualized > topology, such as in enhanced l1vpn. You'll notice that the work item is stated as "Analysis and protocol changes for routing and signaling for link viability constraints" whether this turns into one, two or a hundred I-Ds cannot possibly be determined at this point. I suspect that the issue of routing across a photonic domain as described in the Ashwood I-D is only a special case of a generic multi-domain TE issue. Hence this item appears under the Inter-Domain heading and is described much more generally. You are correct that some of this would feed into (overlap with) the L1VPN enhanced mode. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Aug 2005 11:13:43 +0000 Date: Fri, 19 Aug 2005 20:13:35 +0900 From: Akira NAGATA To: ccamp@ops.ietf.org Subject: Question on Administratively down bit Cc: Akira_NAGATA Message-Id: <20050819200548.46A5.NAGATA.AKIRA@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Mr. Lou Berger and editors of RFC3471 and RFC3473, This is my first time to send e-mail to ccamp. Thanks in advance. I'd like to ask one question about the handling of Administratively down bit in GMPLS RSVP-TE's Admin_Status object. RFC3471 introduces "inhibiting alarm reporting" as an example application of local action to "down" state (that is, A-bit=1) in Section 8. But I can't find any other explicit descriptions about this procedure in RFC3471 or 3473. I understand that actions to be taken by each node receiving Admin_Status object shall be based on local policy. With regard to inhibition of alarm reporting, however, in order to achieve it through end-to-end, I believe that we had better take a unified action as a response to A-bit ("down" or "up"). Operator will expect this feature. (Here I mean alarm report is not reporting via RSVP messages as described in ID-alarm-spec, but one from NE to external system such as network management system.) Are there any considerations, drafts or RFCs to define it? Thanks, --- Akira NAGATA Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Aug 2005 10:07:09 +0000 Message-ID: <4305AF37.2020500@psg.com> Date: Fri, 19 Aug 2005 12:06:47 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Huub van Helvoort CC: ccamp , adrian Subject: Re: MS-SPring Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi huub, Huub van Helvoort wrote: > Hallo Dimitri, > > You responded to Diego: > >> Diego Caviglia wrote: >> >>> Hi Dimitri, >>> given the high number of MS-SPRing protected transport >>> network >>> already deployed seems reasonable to me, from a Network Operator >>> point of >>> view, to use at the same time MS-SPRing protection with GMPLS >>> restoration. >> >> there are already two questions here 1. is there an operational need >> to control such rings using GMPLS (? for instance is it effective >> knowing that ring based protection is mainly data plane driven ?) and >> 2. how to position the ring protection wrt to the LSP recovery >> segment/end-to-end recovery > > The first step in MS-Spring is indeed dataplane driven (using APS) > but that involves only nodes adjacent to the fault. ok, btw, is there a reason to restrict to MS/line protection ring ? > The reconfiguration of the ring after this first switch is controlplane > driven and concerns all nodes in the ring. ok with this - like for other linear protection schemes the control plane would be involved in the provisioning also, what about the (informational) notification to maintain the control plane aware about the data plane status after failure detection and/or after the APS operation thanks, - dimitri. > Cheers, Huub. > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Aug 2005 10:05:07 +0000 Message-ID: <05c701c5a4a5$c17274f0$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: =?ks_c_5601-1987?B?sei/tcit?= , Cc: , "'Kireeti Kompella'" Subject: Control Plane Robustness [Was: Moving forward with the CCAMP charter] Date: Fri, 19 Aug 2005 11:05:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit Hi, I think you are Young Hwa Kim. > I propose that we handle control plane resilience in our CCAMP > charter. Since two other drafts in the same sort of area have also been mentioned (draft-ali-ccamp-mpls-graceful-shutdown and draft-leroux-ccamp-ctrl-saturation) I think we are seeing some support for a work item on control plane robustness. > I think that the CCAMP WG is focussing on the data and control > planes for GMPLS. > Until now we have handled the data plane part for resilience, but > we have no results of control plane resilience. > I had presented my contribution for requirements of control plane > resilience through draft-kim-ccamp-cpr-reqts-00.txt last year. > On the November meeting this year, I will present an updated > document of requirements for control plane resilience , and a > new or extended protocol specification document for control > plane resilience. I hope you will not wait for the November meeting. The intention of the meetings is to meet and discuss technical issues, not to act as a submission deadline for new versions of drafts. It is always helpful to publish drafts in good time and as soon as they are ready so that they can be reviewed and discussed. I am surprised that you do not also mention draft-kim-ccamp-cc-protection-04.txt It would be helpful if the WG could look at your two drafts and comment. As yet there has not been wide support expressed for what you are suggesting, and I need to see a greater degree of consensus before I can bring this into the WG. Thus my feeling at the moment is that Control Plane Robustness should be an area that CCAMP looks at, but we should not set any specific milestones. Regards, Adrian > Of course, I think it's possible under the condition that the topic of control plane > resilience could be handled in the CCAMP charter. -----¢¯©ª¨¬¡í ¢¬¨­¨öAAo----- From: "Adrian Farrel" >From Date: 2005-08-16 ¢¯AEA 8:28:11 To: "ccamp@ops.ietf.org" Cc: "zinin@psg.com" , "'Kireeti Kompella'" Subject: Moving forward with the CCAMP charter Hi, Please find attached a file that contains: - a set of proposed *draft* milestones - a discussion of why there are so many milestones - a high-level explanation of the work items. Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. I would welcome your (constructive!) comments. Notes: - Why isn't my I-D also cited as input material? No insult intended. The current list is simply there to show the ADs that work is already in progress. All I-Ds will be used as input. - Why isn't my pet topic included? Are you sure it is not there between the lines? This list of milestones isn't completely proscriptive. The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. Thanks, Adrian ----- Original Message ----- From: "±è¿µÈ­" To: "Adrian Farrel" ; Cc: ; "'Kireeti Kompella'" Sent: Friday, August 19, 2005 10:32 AM Subject: RE: Moving forward with the CCAMP charter > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Aug 2005 09:31:55 +0000 Thread-Topic: Moving forward with the CCAMP charter thread-index: AcWkoP0mQI0llS9oRE2pPqaplaS5cg== Content-Transfer-Encoding: 7bit Reply-To: =?ks_c_5601-1987?B?sei/tcit?= From: =?ks_c_5601-1987?B?sei/tcit?= To: "Adrian Farrel" , Cc: , "'Kireeti Kompella'" Bcc: Subject: RE: Moving forward with the CCAMP charter Date: Fri, 19 Aug 2005 18:32:59 +0900 Comment: =?ks_c_5601-1987?B?x9GxucD8wNrF673Fv6yxuL/4LCBPQU2x4rz6xsAsILTjtOc=?= Message-ID: <99e101c5a4a0$fd2b4080$8310fe81@email1> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_99DC_01C5A4EC.6D0E0680" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------=_NextPart_000_99DC_01C5A4EC.6D0E0680 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 ------=_NextPart_000_99DC_01C5A4EC.6D0E0680 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PERJViBpZD1tc2dib2R5IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiCxvLiy Ij4NCjxESVY+SGksIDxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDA4MD5BZHJpYW4gYW5kIGNj YW1wZXJzIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDgw PkkgcHJvcG9zZSB0aGF0IHdlIGhhbmRsZSBjb250cm9sIHBsYW5lIHJlc2lsaWVuY2UgaW4gb3Vy IENDQU1QIGNoYXJ0ZXIuPC9GT05UPjwvRElWPg0KPERJVj4NCjxESVY+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMDgwPkkgdGhpbmsgdGhhdCB0aGUgQ0NBTVAgV0cgaXMgZm9jdXNzaW5nIG9u IHRoZSBkYXRhIGFuZCBjb250cm9sIHBsYW5lcyBmb3IgR01QTFMuPC9GT05UPjwvRElWPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwODA+VW50aWwgbm93IHdlIGhhdmUg aGFuZGxlZCB0aGUgZGF0YSBwbGFuZSBwYXJ0IGZvciByZXNpbGllbmNlLCBidXQgd2UgaGF2ZSBu byByZXN1bHRzIG9mIGNvbnRyb2wgcGxhbmUgcmVzaWxpZW5jZS48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDA4MD5JIGhhZCBwcmVzZW50ZWQgbXkgY29udHJp YnV0aW9uIGZvciByZXF1aXJlbWVudHMgb2YgY29udHJvbCBwbGFuZSByZXNpbGllbmNlIHRocm91 Z2ggZHJhZnQta2ltLWNjYW1wLWNwci1yZXF0cy0wMC50eHQgbGFzdCB5ZWFyLjwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDgwPk9uIHRoZSBOb3ZlbWJlciBt ZWV0aW5nIHRoaXMgeWVhciwgSSB3aWxsIHByZXNlbnQgYW4gdXBkYXRlZCBkb2N1bWVudCBvZiBy ZXF1aXJlbWVudHMgZm9yIGNvbnRyb2wgcGxhbmUgcmVzaWxpZW5jZSAsIGFuZCBhIG5ldyBvciBl eHRlbmRlZCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIGRvY3VtZW50IGZvciBjb250cm9sIHBsYW5l IHJlc2lsaWVuY2UuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwODA+T2YgY291cnNlLCBJIHRoaW5rIGl0J3MgcG9zc2libGUgdW5kZXIgdGhlIGNvbmRpdGlv biB0aGF0IHRoZSB0b3BpYyBvZiBjb250cm9sIHBsYW5lIHJlc2lsaWVuY2UgY291bGQgYmUgaGFu ZGxlZCBpbiB0aGUgQ0NBTVAgY2hhcnRlci48L0ZPTlQ+PC9ESVY+DQo8RElWPjxCUj4tLS0tLb/4 ursguN69w8H2LS0tLS08QlI+PEI+RnJvbTo8L0I+ICJBZHJpYW4gRmFycmVsIiAmbHQ7YWRyaWFu QG9sZGRvZy5jby51ayZndDs8QlI+PEI+RnJvbSBEYXRlOjwvQj4gMjAwNS0wOC0xNiC/wMjEIDg6 Mjg6MTE8QlI+PEI+VG86PC9CPiAiY2NhbXBAb3BzLmlldGYub3JnIiAmbHQ7Y2NhbXBAb3BzLmll dGYub3JnJmd0OzxCUj48Qj5DYzo8L0I+ICJ6aW5pbkBwc2cuY29tIiAmbHQ7emluaW5AcHNnLmNv bSZndDssICInS2lyZWV0aSBLb21wZWxsYSciICZsdDtraXJlZXRpQGp1bmlwZXIubmV0Jmd0OzxC Uj48Qj5TdWJqZWN0OjwvQj4gTW92aW5nIGZvcndhcmQgd2l0aCB0aGUgQ0NBTVAgY2hhcnRlcjxC Uj48QlI+PC9ESVY+PCEtLSBzdHlsZT48L3N0eWxlIC0tPg0KPERJViBiZ0NvbG9yPSIjZmZmZmZm IiBiYWNrZ3JvdW5kPSIiPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPkhpLDxCUj48 QlI+UGxlYXNlIGZpbmQgYXR0YWNoZWQgYSBmaWxlIHRoYXQgY29udGFpbnM6PEJSPjxCUj4tIGEg c2V0IG9mIHByb3Bvc2VkICpkcmFmdCogbWlsZXN0b25lczxCUj4tIGEgZGlzY3Vzc2lvbiBvZiB3 aHkgdGhlcmUgYXJlIHNvIG1hbnkgbWlsZXN0b25lczxCUj4tIGEgaGlnaC1sZXZlbCBleHBsYW5h dGlvbiBvZiB0aGUgd29yayBpdGVtcy48QlI+PEJSPk5vdGUgdGhhdCB0aGlzIGxvb2tzIGxpa2Ug YSBsb3Qgb2YgbWlsZXN0b25lcywgYnV0IHBsZWFzZSByZWFkIHRoZSB0ZXh0IG9uIHRoaXMgaXNz dWUgaW4gdGhlIGF0dGFjaGVkIGZpbGUuIFRoZSBib3R0b20gbGluZSBpcyB0aGF0IHRoaXMgaXMg YSBwcm9kdWN0IG9mIG1pY3JvIG1hbmFnZW1lbnQgd2hlcmUgSSBoYXZlIHRyaWVkIHRvIGlkZW50 aWZ5IGFsbCBvZiB0aGUgSS1EcyB0aGF0IHdlIG1pZ2h0IHByb2R1Y2UgdG8gY292ZXIgdGhlIHJl ZmVyZW5jZWQgd29yaywgYW5kIHdoZXJlIEkgaGF2ZSBwbGFjZWQgdHdvIChzb21ldGltZXMgdGhy ZWUpIG1pbGVzdG9uZXMgZm9yIGVhY2ggSS1ELjxCUj48QlI+VGhpcyBtaWNyby1tYW5hZ2VtZW50 IG1heSBiZSBvdmVyIHRoZSB0b3AsIGFuZCByZXByZXNlbnRzIGEgZnVsbCBwZW5kdWx1bSBzd2lu ZyBmcm9tIHRoZSBwcmV2aW91cyBzdHlsZSBvZiBDQ0FNUCBtaWxlc3RvbmVzLCBidXQgaW4gdGhl IGxpZ2h0IG9mIHRoZSBoaWF0dXMgb2YgdGhlIGxhc3QgMTIgbW9udGhzLCBpIHRoaW5rIHRoaXMg bWF5IGJlIGJlbmVmaWNpYWwgYW5kIG1pZ2h0IGFjaGlldmUgcmFwaWQgZm9yd2FyZHMgbW92ZW1l bnQuPEJSPjxCUj5JIHdvdWxkIHdlbGNvbWUgeW91ciAoY29uc3RydWN0aXZlISkgY29tbWVudHMu PEJSPjxCUj5Ob3Rlczo8QlI+LSBXaHkgaXNuJ3QgbXkgSS1EIGFsc28gY2l0ZWQgYXMgaW5wdXQg bWF0ZXJpYWw/PEJSPiZuYnNwOyBObyBpbnN1bHQgaW50ZW5kZWQuIFRoZSBjdXJyZW50IGxpc3Qg aXMgc2ltcGx5IHRoZXJlIHRvPEJSPiZuYnNwOyBzaG93IHRoZSBBRHMgdGhhdCB3b3JrIGlzIGFs cmVhZHkgaW4gcHJvZ3Jlc3MuIEFsbCBJLURzPEJSPiZuYnNwOyB3aWxsIGJlIHVzZWQgYXMgaW5w dXQuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj4tIFdoeSBpc24ndCBteSBwZXQg dG9waWMgaW5jbHVkZWQ/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6 ZT0yPiZuYnNwOyZuYnNwO0FyZSB5b3Ugc3VyZSBpdCBpcyBub3QgdGhlcmUgYmV0d2VlbiB0aGUg bGluZXM/IFRoaXMgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0y PiZuYnNwOyBsaXN0IG9mIG1pbGVzdG9uZXMgaXNuJ3QgY29tcGxldGVseSBwcm9zY3JpcHRpdmUu PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPiZuYnNwOyA8L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Q291cmllciBzaXplPTI+VGhlIG9iamVjdGl2ZSBp cyB0byBoYXZlIHRoZSBXRyBhZ3JlZWQgb24gdGhlIG1pbGVzdG9uZXMgdGhhdCBpdCB3YW50cyB0 byBjb21taXQgdG8gYnkgdGhlIGVuZCBvZiBBdWd1c3QuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUNvdXJpZXIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1Db3VyaWVyIHNpemU9Mj5UaGFua3MsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUNv dXJpZXIgc2l6ZT0yPkFkcmlhbjwvRk9OVD48L0RJVj48L0RJVj48L0RJVj48aW1nIHN0eWxlPSJk aXNwbGF5Om5vbmUiIHdpZHRoPTAgaGVpZ2h0PTAgc3JjPSJodHRwOi8vdW1haWwuZXRyaS5yZS5r ci9FeHRlcm5hbF9SZWFkQ2hlY2suYXNweD9lbWFpbD1jY2FtcEBvcHMuaWV0Zi5vcmcmbmFtZT1j Y2FtcCU0MG9wcy5pZXRmLm9yZyZmcm9tZW1haWw9eWh3a2ltQGV0cmkucmUua3ImbWVzc2FnZWlk PSUzQ2FiOGIzMjQzLTQ5ZGEtNGM4Zi1iZGNhLTBlNGIwNWM5YTNlZEBldHJpLnJlLmtyJTNFIj4= ------=_NextPart_000_99DC_01C5A4EC.6D0E0680-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 19 Aug 2005 08:41:59 +0000 Message-ID: <43059AF0.3030006@chello.nl> Date: Fri, 19 Aug 2005 10:40:16 +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: ccamp CC: adrian Subject: Re: MS-SPring Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hallo Dimitri, You responded to Diego: > Diego Caviglia wrote: > >> Hi Dimitri, >> given the high number of MS-SPRing protected transport >> network >> already deployed seems reasonable to me, from a Network Operator point of >> view, to use at the same time MS-SPRing protection with GMPLS >> restoration. > > there are already two questions here 1. is there an operational need to > control such rings using GMPLS (? for instance is it effective knowing > that ring based protection is mainly data plane driven ?) and 2. how to > position the ring protection wrt to the LSP recovery segment/end-to-end > recovery The first step in MS-Spring is indeed dataplane driven (using APS) but that involves only nodes adjacent to the fault. The reconfiguration of the ring after this first switch is controlplane driven and concerns all nodes in the ring. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 23:10:03 +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: Moving forward with the CCAMP charter Date: Thu, 18 Aug 2005 19:08:55 -0400 Message-ID: <0901D1988E815341A0103206A834DA07613F9A@mdmxm02.ciena.com> Thread-Topic: Moving forward with the CCAMP charter Thread-Index: AcWilg75TdCjxl3eTNOrTkDcUO9BPQBsYjFg From: "Ong, Lyndon" To: "Adrian Farrel" , , Cc: , , "Kireeti Kompella" Hi Adrian, As with everyone else, I appreciate all of the work that you put in to create a very detailed workplan for the group. Some follow up questions and suggestions:=20 -- On the "aligning GMPLS across standards bodies" item: First of all, what standards bodies do you see included under this effort? =20 Also, are you intending this to be a unilateral document on ccamp's part? If it is, I'm not sure I see what it would say besides "use the RFCs or bring the requirements back to us", which is what this group has said in the past. If on the other hand you see this as the basis for joint discussion with other bodies, it might be a very helpful activity. -- On the ""routing and signaling for complex optical constraints" item: The ashwood draft seems to me to have two components, one being=20 requirements and considerations of routing across a purely photonic domain and the second being a particular solution (the matrix representation), to which there are alternatives such as the virtual link approach that Igor has identified. =20 I think these two should probably be separated, as the solution may be=20 more widely applied to any situation of advertising a virtualized=20 topology, such as in enhanced l1vpn. Cheers, Lyndon Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 22:41:29 +0000 Message-ID: <43050E72.7060209@psg.com> Date: Fri, 19 Aug 2005 00:40:50 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Adrian Farrel CC: Evelyne Roch , ccamp@ops.ietf.org Subject: Re: Responding to the OIF Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Adrian Farrel wrote: > Hi Evelyne, > > >>1. From the examples below, STS3c and VC4 have different >> RCC/NCC values. Clarifications on which values should be >>used for SONET/SDH interworking would be useful. > > I have a couple of folks looking at this for me because I can't tell the > difference between a timeslice and a cakeslice. > > Hopefully they will generate a response soon. this may help - "A dedicated signal type is assigned to a SONET STS-3c SPE instead of coding it as a contiguous concatenation of three STS-1 SPEs. This is done in order to provide easy interworking between SONET and SDH signaling." also the RFC explains how the negotiation occurs (RCC/NCC selection is a local decision process depending on the supported capabilities) - not a big deal here, there are 4 cases possible: - symmetric fixed case either SDH or SONET on both sides, there is no interworking issue possible - symmetric configurable case (assumption taken by OIF) where selection is not impacting establishment, there is no interworking issue possible - asymmetric fixed-configurable case: the upstream node drives the selection by indicating the selected values, there is no interworking issue possible - asymmetric configurable-fixed case: an error is generated if the config supported by the fixed side is not selected by the upstream node but signaling just follows result of the selection - however, GMPLS signaling can not correct this in any case - >>5. Is a change in the presence/absence of ResvConf considered a >>trigger message? > > > Yes, it would be a trigger message (that is, it would not be treated as a > simple refresh). But a "trigger message" does not necessarily cause any > action. > > >>My interpretation of the text below is that a refresh resv >>message containing a RESV_CONF object would not >>result in the generation of a RESV_CONF message, >>RESV_CONF messages only being sent on trigger >>resv message. Is that correct? > > > Seems reasonable to me. > That way the ResvConf confirms the receipt of the changed Resv. > > I guess I should have added a note that a ResvConf message is not > necessarily reliably delivered. 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. > > Adrian > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 22:19:13 +0000 Message-ID: <4305092B.2000906@psg.com> Date: Fri, 19 Aug 2005 00:18:19 +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.8) Gecko/20050511 MIME-Version: 1.0 To: E.T.Metz@telecom.tno.nl CC: ccamp@ops.ietf.org Subject: Re: Requesting a LSC LSP across a PCS interface Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi, > Consider the following situation: > > Domain A <= | => Domain B <= | => Domain C > | | > [A1]--PSC--[A2]--PSC--[B1]--LSC--[B2]--LSC--[B4]--PSC--[C1] > | | | | > |---PSC--[B3]--PSC---| > > > Suppose I want to setup an (PSC) LSP from [A1] to [C1]. In domain B > there are two options, the PSC route, or the LSC route. Is there a way > to request (or hint for) a LSC LSP in domain B for the A1-C1 LSP? For > example because the quality of the PSC path is deemed insufficient from > the point of view of domains A and C (e.g. A and C are vey high bw LAN > enviroments, B a WAN environment). base on your diagram and assuming symmetric links both nodes B1 and B4 must have a PSC and LSC switching capability so here and as provided in the diagram i assume the boundary is on the node; however, if you mean [B1,B4] and [B2,B4] being [PSC,LSC] and [LSC,PSC] resp. then B1 and B4 are simple PSC nodes with LSC interfaces and then the boundary would be on the interface now, if all domains are in the same routing area - have strict path all along - B4 loose hop with explicit indication of incoming interface if all domains not in the same routing area - make use of constaint passing by including (or excluding) specific switching capability such as to indicate which resource type to select/preclude in order to reach the destination B4 (loose hop) hope this helps, - dimitri. > Thanks! > > cheers, > Eduard > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 21:44:25 +0000 Message-ID: <055c01c5a43e$43aa2980$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Evelyne Roch" , Subject: Re: Responding to the OIF Date: Thu, 18 Aug 2005 22:43:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Evelyne, > 1. From the examples below, STS3c and VC4 have different > RCC/NCC values. Clarifications on which values should be > used for SONET/SDH interworking would be useful. I have a couple of folks looking at this for me because I can't tell the difference between a timeslice and a cakeslice. Hopefully they will generate a response soon. > 5. Is a change in the presence/absence of ResvConf considered a > trigger message? Yes, it would be a trigger message (that is, it would not be treated as a simple refresh). But a "trigger message" does not necessarily cause any action. > My interpretation of the text below is that a refresh resv > message containing a RESV_CONF object would not > result in the generation of a RESV_CONF message, > RESV_CONF messages only being sent on trigger > resv message. Is that correct? Seems reasonable to me. That way the ResvConf confirms the receipt of the changed Resv. I guess I should have added a note that a ResvConf message is not necessarily reliably delivered. 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. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 20:59:31 +0000 Message-Id: <5.1.1.9.2.20050819055127.05675bc8@mailsv4.y.ecl.ntt.co.jp> Date: Fri, 19 Aug 2005 05:59:21 +0900 To: "Adrian Farrel" , From: Wataru Imajuku Subject: Re: Moving forward with the CCAMP charter Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Hi, Adrian Thank you for giving your time interim your hard work. >With regard to your section 5, I note that you consider the VCAT group >analogous with a link bundle. I don't think this is correct because the >members of a link bundle must be selected and used individually. A payload >data stream cannot be distributed across multiple component links of the >bundle... > An LSP with a bandwidth requirement b and > setup priority p fits in a bundled link if at least one component > link has maximum LSP bandwidth >= b at priority p. >However, the whole point of a VCAT group is to produce a single entity >(pipe) with maximum LSP bandwidth greater than the capacity of any >individual component. A VCAT group, therefore, is not a bundle. > >Following on from this, I think that the remainder of your section 5.1 >will have some value, but needs to be corrected to properly reflect the >meaning of a VCAT group. > >In general, I think your section 5 should generalize from the specific >case of the FA to include any TE link that is based on a VCAT group. > >Section 5.2 seems to confuse "FA" with "FA LSP". Regarding to VCAT, I agree to your comment. But, this draft also covers LAGR (link aggregation) which has some limitations to transmit data-flow exceeding the bandwidth of each comopnent LSP. This is one of reason why the description wirtten in Section 5 exists, although some terminologies are not proper as you noted. Thanks Wataru --------------------------------- Wataru Imajuku Senior Research Engineer @NTT Network Innovation Labs. TEL +81-46-859-4315 FAX +81-46-859-5541 Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 20:09:08 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A430.48FA5368" Subject: RE: Responding to the OIF Date: Thu, 18 Aug 2005 16:06:13 -0400 Message-ID: <29D15BBCA340DA4D8146D38B4924FC7A1713F2@zcarhxm0.corp.nortel.com> Thread-Topic: Responding to the OIF Thread-Index: AcWec2jLWKQ51KG2TrmueCxhk3p2/wFvNy9Q From: "Evelyne Roch" To: "Adrian Farrel" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A430.48FA5368 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Regarding the following points: =20 1. From the examples below, STS3c and VC4 have different RCC/NCC values. Clarifications on which values should be used for SONET/SDH interworking would be useful. 5. Is a change in the presence/absence of ResvConf considered a trigger message? My interpretation of the text below is that a refresh resv message containing a RESV_CONF object would not result in the generation of a RESV_CONF message, RESV_CONF messages only being sent on trigger resv message. Is that correct? =20 =20 Regards, Evelyne Roch=20 Control Plane Software=20 Nortel Networks=20 PO Box 3511 STN C Ottawa ON K1Y 4H7=20 * Phone: (613) 763-6492 (esn 393)=20 * e-mail [mailto:eroch@nortel.com]=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, August 11, 2005 8:43 AM To: ccamp@ops.ietf.org Subject: Responding to the OIF =09 =09 Hi, =09 As Lyndon noted in Paris, the OIF has sent us a communication requesting some guidance on a bunch of questions. =09 This is to start the business of constructing a reply. thanks to Dimitri for supplying some of this text. =09 Please send comments and improvements. =09 Adrian =09 =3D=3D=3D=3D=3D=3D =09 To: Jim Jones, OIF Technical Committee Chair From: Adrian Farrel and Kireeti Kompella,=20 WG Co-Chairs for IETF CCAMP Copy: Alex Zinin and Bill Fenner, IETF Routing Area Directors Subject: Response to your questions about GMPLS parameters. =09 Dear Jim, =09 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. =20 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 >=20 > 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. >=20 > 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). =09 This question about RFC 3946 was raised informally on the CCAMP mailing list at the start of March this year.=20 =09 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. =09 From the examples in the annex we have... =09 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 =09 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 =09 Your question probably arises from the two notes and subsequent paragraph in section 2.1 or RFC 3946. Here it says... =09 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. =09 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. =09 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. =09 We believe that this final sentence should read "greater than or equal to 1," and that this interpretation resolves all of your issues and makes the text consistent with the examples. =09 > 2. Setting of NVC for VCAT connections >=20 > 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. =09 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. =09 > 3. Length of the Interface Switching Capability TLV >=20 > 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. >=20 > 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)." =20 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. =20 > 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. =20 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. =20 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=20 LSP b/w 2 4 bytes=20 LSP b/w 3 4 bytes=20 LSP b/w 4 4 bytes=20 LSP b/w 5 4 bytes=20 LSP b/w 6 4 bytes=20 LSP b/w 7 4 bytes min b/w 4 bytes indication 1 byte =3D=3D 41 bytes =20 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. =20 It is an implicit field, and should not be included in the length of the TLV. =20 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. =20 > 4. Use of ADMIN_STATUS in an initial PATH message >=20 > 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: >=20 > "The absence of the object is equivalent to receiving an object containing > values all set to zero (0)." >=20 > 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. =20 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. =20 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. =20 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. =20 > 5. Handling of multiple received ResvConf Request objects >=20 > 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. >=20 > 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. =20 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. =20 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. =20 Thus, an 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. > 6. Symmetry of Refresh Reduction usage >=20 > 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. >=20 > 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. >=20 > Comment from CCAMP WG on the correct interpretation is requested. =20 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.=20 =20 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. =20 In summary: - An LSR must not send refresh reduction options or messages=20 to an LSR that is not setting the refresh-reduction-capable=20 bit. - An LSR may send refresh reduction options or messages =20 to an LSR that is setting the refresh-reduction-capable bit. - An LSR that wishes to successfully use responded refresh=20 reduction options or messages should set the refresh- reduction-capable bit. =20 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." =09 > 7. Sending of ACKs bundled with the RSVP HELLO >=20 > 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. >=20 > 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. =20 You use of the terms "bundled" and "piggybacked" are contradictory. =20 "Bundled" implies the use of the Bundle message. RFC 2961 states... A sub-message MAY be any message type except for another=20 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.) =20 Further, RFC 3209 states... A Hello message may be included as a sub-message within a bundle message. =20 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. =20 On the other hand, "piggybacked" implies the use of the Ack/Nack objects within a Hello message. =20 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... =20 ::=3D [ ] =20 Since RFC 3209 post-dates RFC 2961, this definition is definitive and the Ack/Nack objects should not be present on the Hello message. =20 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. =20 > 8. TSPEC format to be used for Ethernet connections =20 The CCAMP working group is currently discussing the use of GMPLS for control of Ethernet devices. We will respond to this point in a separate email. Best regards, Adrian Farrel Kireeti Kompella ------_=_NextPart_001_01C5A430.48FA5368 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
Regarding the following = points:
 
1. From the examples below, STS3c and VC4 have different = RCC/NCC=20 values. Clarifications on which values should be used for SONET/SDH = interworking would be useful.
5. Is=20 a change in the presence/absence of ResvConf considered a=20 trigger message?  My interpretation of the text below is that = a=20 refresh resv message containing a RESV_CONF object would not result in = the=20 generation of a RESV_CONF message, RESV_CONF messages only being = sent=20 on trigger resv message. Is that correct?
 
 
Regards,

Evelyne = Roch=20
Control Plane=20 Software
Nortel Networks
PO Box 3511 STN C Ottawa ON K1Y=20 4H7
( Phone: (613) 763-6492 = (esn=20 393)
, e-mail [mailto:eroch@nortel.com]=20

-----Original Message-----
From:=20 owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On = Behalf Of=20 Adrian Farrel
Sent: Thursday, August 11, 2005 8:43=20 AM
To: ccamp@ops.ietf.org
Subject: Responding to = the=20 OIF

Hi,

As Lyndon noted in = Paris, the OIF=20 has sent us a communication requesting some guidance on a bunch of=20 questions.

This is to start the business of constructing a = reply.=20 thanks to Dimitri for supplying some of this text.

Please send = comments=20 and improvements.

Adrian

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

To: = Jim Jones, OIF=20 Technical Committee Chair
From: Adrian Farrel and Kireeti Kompella, =
          WG = Co-Chairs for=20 IETF CCAMP
Copy: Alex Zinin and Bill Fenner, IETF Routing Area=20 Directors
Subject: Response to your questions about GMPLS=20 parameters.

Dear Jim,

Thanks for your correspondence = about the=20 questions with respect to GMPLS parameters that arose before and = during your=20 interoperability testing. CCAMP is pleased to receive such questions = and is=20 glad to have the opportunity to explain the intended operation of the = GMPLS=20 protocols.
 
Much of the material supplied below = can be=20 simply extracted from the relevant RFCs.


> 1. Use of the NCC and RCC fields for STS-3c/VC-4=20 connections
>
> During OIF testing it was noted that some = ambiguity exists in the
> specification of encoding of NCC, RCC = and NVC=20 for certain types of
> connections: NCC and RCC for an = STS-3c/VC-4=20 connection can be set to 0 or
> to 1 depending on which example = of RFC=20 3946 is followed.
>
> Clarification is requested from = IETF CCAMP=20 as to which setting is
> considered correct, or if both settings = should=20 be accepted (this procedure
> was used during testing at=20 Supercomm).

This question about RFC 3946 was raised informally = on the=20 CCAMP mailing list at the start of March this year.

Even when = the=20 signal Type value is the same (i.e. value 6) the NCC, RCC and NVC = values=20 depend on the specific signal being requested.

From the = examples in the=20 annex we have...

   A VC-4 signal is formed by = applying the=20 following
   settings to a VC-4 Elementary=20 Signal.
      RCC =3D=20 0
      NCC =3D = 0
     =20 NVC =3D 0
      MT  =3D=20 1
      T   =3D = 0

   An=20 STS-3c SPE signal is formed by applying the following
   = settings=20 to an STS-3c SPE Elementary Signal.
      = RCC =3D 1=20 (standard contiguous concatenation)
      = NCC =3D=20 1
      NVC =3D = 0
     =20 MT  =3D 1
      T   =3D = 0

Your=20 question probably arises from the two notes and subsequent paragraph = in=20 section 2.1 or RFC 3946. Here it says...

   Note 1: = when=20 requesting a SONET STS-Nc SPE with N=3D3*X,=20 the
      Elementary Signal to use must = always be=20 an STS-3c_SPE signal type
      and the = value of=20 NCC must always be equal to X.  This allows=20 also
      facilitating the interworking = between=20 SONET and SDH.  In
      particular, = it means=20 that the contiguous concatenation of = three
     =20 STS-1 SPEs can not be requested because according to=20 this
      specification, this type of = signal must=20 be coded using the STS-3c
      SPE signal = type.

   Note 2: when requesting a transparent = STS-N/STM-N=20 signal
      limited to a single = contiguously=20 concatenated STS-Nc_SPE/VC-4-Nc,
      the = signal=20 type must be STS-N/STM-N, RCC with flag 1 and NCC=20 set
      to 1.

   The = NCC value=20 must be consistent with the type of contiguous
   = concatenation=20 being requested in the RCC field.  In particular, = this
  =20 field is irrelevant if no contiguous concatenation is requested=20 (RCC
   =3D 0), in that case it must be set to zero when = sent, and=20 should be
   ignored when received.  A RCC value = different=20 from 0 must imply a
   number of contiguous components = greater=20 than 1.

We believe that this final sentence should read = "greater than=20 or equal to 1," and that this interpretation resolves all of your = issues and=20 makes the text consistent with the examples.

> 2. Setting of = NVC for=20 VCAT connections
>
> It was also noted that the setting = of NVC=20 may be somewhat ambiguous for
> the case where diverse = connections are=20 used within a single VCAT group.
> Each individual RSVP session = controls=20 a single connection, but the
> connection is part of a larger = VCAT group=20 and carries VCAT encoding of the
> H4 byte. Clarification is = requested=20 from IETF CCAMP and ITU-T Q.14/15 as
> to the correct setting of = NVC for=20 this case (0 or 1?). It should be noted
> that this case may = occur with=20 a VCAT group with only a single initial
> member, and that the = NVC may=20 provide an indication that VCAT encoding of
> the H4 byte is in = use for=20 the connection.

A VCn-Xv group split into X components requires = each of=20 its component to be signaled with the NVC value set to 1. This setting = is=20 regardless of how the components are established.

> 3. = Length of the=20 Interface Switching Capability TLV
>
> Although the = Interface=20 Switching Capability TLV defined by CCAMP for
> SONET/SDH = connections=20 was not used for the testing, it was noted that the
> text = describing=20 the length of the Interface Switching Capability TLV
> defined = in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly
>=20 ambiguous due to the use of padding bytes.
>
> RFC 3630 = states=20 that "The TLV is padded to four-octet alignment; padding
> is = not=20 included in the length field (so a three octet value would have = a
>=20 length of three, but the total size of the TLV would be eight=20 octets)."
 
Yes. Section 2.3.2 of RFC3630 gives = a=20 definitive statement of the meaning of the length field and the use of = padding, and provides an example.
 
> Reading of the encoding in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
> specifies that = the=20 length of the TLV for TDM is 41 bytes plus 3 bytes of
> padding, = and=20 should be given in the length field as 41 bytes rather than
> = 44. OIF=20 requests verification of this interpretation from the experts = in
> IETF=20 CCAMP group.
 
Note that the Interface Switching Capability Descriptor defined = in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link = TLV.=20 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=20
  LSP b/w 2  4 bytes=20
  LSP b/w 3  4 bytes=20
  LSP b/w 4  4 bytes=20
  LSP b/w 5  4 bytes=20
  LSP b/w 6  4 bytes=20
  LSP b/w 7  4=20 bytes
  min b/w    4 bytes
  indication 1=20 = byte
           = ; =3D=3D
=
           &n= bsp;41=20 bytes
 
We presume that your question relates to whether the 3-byte field = shown=20 as "padding" in the TDM-specific figure on page 6 of=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an = explicit=20 field.
 
It is an implicit field, and should not be included in the length = of the=20 TLV.
 
Nevertheless, we take this = opportunity to=20 remind the OIF that implementations of GMPLS protocols should be = conservative=20 in what they send and liberal in what they receive. Thus, an = implementation=20 that receives a TDM ISCD TLV with length 44 should not reject the TLV = for this=20 reason. It should parse the TLV according to the defined fields and = skip the=20 final three bytes. Thus, it should not affect a receiving = implementation if=20 the sending implementation has treated the "padding" field as implicit = or=20 explicit. In the event that a receiving implementation rejected such a = TLV on=20 grounds of the value contained in the length field being too large, = the fault=20 would lie with the receiving implementation not the sending=20 implementation.
 
> 4. Use of ADMIN_STATUS in an = initial PATH=20 message
>
> Some implementations sent an ADMIN_STATUS = object with=20 no flags set in the
> initial PATH message, i.e., when no status = change=20 was being requested.
> Although this did not serve any = particular=20 function, it was believed that
> this could be accepted as = RFC3473,=20 sect. 7.2 (page 18) states:
>
> "The absence of the = object is=20 equivalent to receiving an object containing
> values all set to = zero=20 (0)."
>
> It was our interpretation based on this text = that a=20 node should accept an
> ADMIN_STATUS object with no flags set in = the=20 same way as if the object was
> missing. Comment on this = interpretation=20 is welcome.
 
The effect of the meaning is as you = state, but=20 the intention of the meaning is reversed. That is, an implementation = should=20 accept the absence of the ADMIN_STATUS object in the same way as if = the object=20 was present with no flags set. That is, the default behavior is to = consider=20 the ADMIN_STATUS object as a standard part of the = processing.
 
We note from your first paragraph = that you=20 assume that the ADMIN_STATUS object is used to change the status of = the LSP.=20 This is a misinterpretation - it is used to control the status of the = LSP.=20 Thus, if there is no change to the status of an LSP, refresh messages = must=20 continue to carry the ADMIN_STATUS object with the same bit=20 setting.
 
In this way, it is not possible to = "drop" the=20 ADMIN_STATUS object without having the same meaning as transmitting = the object=20 with all bits cleared.
 
> 5. Handling of multiple = received ResvConf=20 Request objects
>
> When a connection desires a = confirmation that=20 the service (i.e.
> connection) requested is in place, a = RESV_CONF_REQ=20 object is included in
> the RESV message. As this object is = received by=20 the remote end of the
> reservation, it will send a RESV_CONF = message=20 back to the requester.
>
> However, it is unclear whether = it is=20 necessary to send a RESV_CONF message
> when the RSVP connection = state=20 is refreshed by subsequent RESV. This
> becomes potentially = burdensome,=20 especially when the reservation is being
> rapidly refreshed. = Therefore=20 we ask: should the remote end send a
> RESV_CONF message for = subsequent=20 RESV messages that still include the
> RESV_CONF_REQ object? Or = is it=20 required that the requestor of the
> reservation remove the=20 RESV_CONF_REQ object to prevent the generation of
> further = RESV_CONF=20 messages? Comment on this issue from IETF CCAMP is
>=20 requested.
 
It is fundamental to = the implementation of=20 RSVP-TE that there is a good understanding of the distinction between = a=20 trigger message and a refresh message. This can be achieved by reading = section=20 1.1 of RFC2961.
 
Following this understanding, you = will note=20 that a refresh message does not cause any processing to be performed = at the=20 LSR that receives it (in this case the ingress). You will also note = that=20 refresh processing is not end-to-end as implied in your text, but is=20 hop-by-hop.
 
Thus, an downstream LSR that wishes = to trigger=20 a new ResvConf message must make a specific change to the content of = the Resv=20 message that it sends in order to cause a trigger message to be = propagated=20 through the network to the ingress LSR. Such processing is = implementation=20 specific.

> 6. Symmetry of Refresh Reduction usage
>
> = During=20 interop testing, we ran into a conflict caused by varying
>=20 interpretations of RFC2961, regarding the use of SRefresh messages and = the
> Refresh Reduction capabilities of the two ends of a given = link.=20 One
> interpretation of RFC2961 indicates that setting the = Refresh=20 Reduction
> Capability flag in the RSVP header indicates that = that=20 interface shall be
> capable of receiving messages related to = Refresh=20 Reduction - including the
> SRefresh message. This would be true = even if=20 the other end of the link for
> that interface were NOT = indicating=20 Refresh Reduction Capability, since the
> RFC makes no statement = about=20 symmetry in this matter.
>
> Another interpretation is = that both=20 ends of an interface must indicate
> Refresh Reduction = Capability before=20 either end can use such messages, i.e,
> use of Refresh = Reduction on a=20 link is symmetric.
>
> Comment from CCAMP WG on the = correct=20 interpretation is requested.
 
We are confused by your question.
You correctly state that the use of the refresh-reduction-capable = bit=20 indicates the ability of an LSR to support the receipt of refresh = reduction=20 options and messages. To quote from section 2 of RFC2961...
           When = set,=20 indicates that this node is willing and capable=20 of
           = receiving=20 all the messages and objects described in=20 this
          =20 document.  This includes the Bundle message described=20 in
           = Section 3,=20 the MESSAGE_ID objects and Ack messages=20 = described
          = in=20 Section 4, and the MESSAGE_ID LIST objects and=20 = Srefresh
           = message described in Section 5.  This bit is meaningful=20 only
           = between=20 RSVP neighbors.
This makes no statement about whether the LSR = intends to=20 use these options when communicating with another LSR.
 
However, you will note that some refresh reduction procedures = require=20 that a message is sent and response returned. In order to make use of = the=20 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=20 refresh reduction options and messages to also set the=20 refresh-reduction-capable bit.
 
In summary:
- An LSR must not send refresh reduction options or=20 messages 
  to an LSR that is not setting the = refresh-reduction-capable
  bit.
- An LSR may send refresh reduction options or messages =20
  to an LSR that is setting the = refresh-reduction-capable=20 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=20 not known if a next hop supports the extension, standard Path and Resv = message=20 based refreshes MUST be used."
> 7. Sending of ACKs bundled with the RSVP HELLO
> =
>=20 During interop testing, it was observed that Message Acks were=20 piggybacked
> onto RSVP Hello messages, when the receiving end = was not=20 using the Hello
> protocol. In this situation, the incoming = Hello's were=20 discarded and the
> Acks were lost.
>
> We believe = that=20 Message Acks should only be piggybacked onto mandatory
> = messages, and=20 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=20 another
   Bundle message.
Thus, Ack messages may be bundled with other messages. (Although = one=20 might consider this perverse since the Ack message is only introduced = to=20 handle the case when the Ac/Nack objects have no other message on = which they=20 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=20 together.
The processing rules (RFC 29610 for Bundled messages are such = that each=20 sub-message is processed in its own right, and the non-support/non-use = of=20 Hello messages should not impact the processing of other = messages.
 
On the other hand, "piggybacked" implies the use of the Ack/Nack = objects=20 within a Hello message.
 
Section 4.1 of RFC2961 states that Ack/Nack objects may be = included in=20 the "standard" RSVP messages, and shows where they are placed. = However, RFC=20 3209 defines the Hello message as not including the Ack/Nack = objects...
 
   <Hello Message> ::=3D <Common Header> [=20 <INTEGRITY>=20 = ]
           &n= bsp;           &nb= sp;     =20 <HELLO>
 
Since RFC 3209 post-dates RFC 2961, this definition is definitive = and the=20 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=20 may be
   ignored by nodes which do not wish to = participate in=20 Hello message
   processing.
...it is not particularly important what the message format rules = are. An=20 implementation that chooses to place an Ack/Nack object in a Hello = message=20 knows that the object might be discarded unprocessed.
 
> 8. TSPEC format to be used for Ethernet connections
 
The CCAMP working group is currently discussing the use of GMPLS = for=20 control of Ethernet devices. We will respond to this point in a = separate=20 email.

Best regards,
Adrian Farrel
Kireeti Kompella
=00 ------_=_NextPart_001_01C5A430.48FA5368-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 13:44:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Requesting a LSC LSP across a PCS interface Date: Thu, 18 Aug 2005 15:42:31 +0200 Message-ID: <81FEC275650AE14EBD5245E624762B9701ACED61@ds07.tnoase.telecom.tno.nl> Thread-Topic: Requesting a LSC LSP across a PCS interface Thread-Index: AcWj+q668kf02/19QsCNVkffgXoI2g== From: To: Hi all, Consider the following situation: Domain A <=3D | =3D> Domain B <=3D | =3D> Domain = C | | [A1]--PSC--[A2]--PSC--[B1]--LSC--[B2]--LSC--[B4]--PSC--[C1] | | | | |---PSC--[B3]--PSC---| Suppose I want to setup an (PSC) LSP from [A1] to [C1]. In domain B there are two options, the PSC route, or the LSC route. Is there a way to request (or hint for) a LSC LSP in domain B for the A1-C1 LSP? For example because the quality of the PSC path is deemed insufficient from the point of view of domains A and C (e.g. A and C are vey high bw LAN enviroments, B a WAN environment). Thanks! cheers, Eduard Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 11:23:28 +0000 Message-ID: <048301c5a3e7$74538290$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Wataru Imajuku" Subject: Re: Moving forward with the CCAMP charter Date: Thu, 18 Aug 2005 10:42:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi Wataru, > I believe that my draft includes some issues which have not addressed in > bernsteins draft. > For example, the issue of section 5 in my draft. > This is important issue when LCAS&VCAT will be applied in MRN. > > I understand your proposal is my requirement draft > draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt > will be merged with draft-bernstein-ccamp-.... > or simply discard ? As I said in my original email... >>- Why isn't my I-D also cited as input material? >> No insult intended. The current list is simply there to >> show the ADs that work is already in progress. All I-Ds >> will be used as input. Nothing of value will be thrown away. All input to working group drafts is welcome whether it is supplied as comments on the email list or as a separate I-D. With regard to your section 5, I note that you consider the VCAT group analogous with a link bundle. I don't think this is correct because the members of a link bundle must be selected and used individually. A payload data stream cannot be distributed across multiple component links of the bundle... An LSP with a bandwidth requirement b and setup priority p fits in a bundled link if at least one component link has maximum LSP bandwidth >= b at priority p. However, the whole point of a VCAT group is to produce a single entity (pipe) with maximum LSP bandwidth greater than the capacity of any individual component. A VCAT group, therefore, is not a bundle. Following on from this, I think that the remainder of your section 5.1 will have some value, but needs to be corrected to properly reflect the meaning of a VCAT group. In general, I think your section 5 should generalize from the specific case of the FA to include any TE link that is based on a VCAT group. Section 5.2 seems to confuse "FA" with "FA LSP". Regards, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 10:17:33 +0000 Message-ID: <43046013.6020003@psg.com> Date: Thu, 18 Aug 2005 12:16:51 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Diego Caviglia CC: dimitri.papadimitriou@alcatel.be, " , "adrian , "ccamp Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit diego >>given the high number of MS-SPRing protected transport network >>already deployed seems reasonable to me, from a Network Operator point of >>view, to use at the same time MS-SPRing protection with GMPLS >>restoration. > > there are already two questions here 1. is there an operational need to > control such rings using GMPLS (? for instance is it effective knowing > that ring based protection is mainly data plane driven ?) > [dc] I prefer to hear something from the Operator here even if my > experience tell me that the answer is yes. i don't have the full answer either - the question is to address such considerations and tradeoffs > and 2. how to position the ring protection wrt to the LSP recovery > segment/end-to-end > recovery > [dc] I'm sure I've got the point here sorry, what exatly do you mean with > position? some examples (not exhaustive): will it be seen as link protection for some links used by the end-to-end LSP or LSP segment protection of end-to-end LSP or both ? otoh would it be possible to assume SDH ring protection on top of nodes interconnected by recoverable Lambdas ? >>Let's say the first failure is recovered via MS-SPRing in less than 50 ms >>while subsequent failures can be recovered via GMPLS restoration with >>lower performance. > > is it because it is a "local" protection (i.e. wouldn't a segment > recovery provide the same time efficiency) or because it is ring based > [dc] It is because is performed at the SDH layer, all the SDH protection > scheme I know have the same performance (e.g. SNCP, MSP) so it is the former i.e. "local-(data-plane driven) protection" by the way if you plan to start such document a terminology section inserted w/i an informative appendix would help the IETF reader >>Basically that is the rationale behind my initial question. >> >>What is your view on that? > > my view is that a problem statement should cover such base questions - i > am in agreement with adrian stand here - > [dc] I'm trying to put togheter a requirement doc that briefly illustrates > how MS-SPRing works and what are the information that it needs in order to > work corretly. i don't think there is a need to step into the details of "how it works" in the first phase (an 1-page summary would be enough here, at the end good references are available) but "why/where it makes sense" and "what does it imply" the above discussion is a sample of considerations that such document should address as i wouldn't step in without having an overall picture of the landscape >>Regards >> >>Diego >> >> >> >>dimitri papadimitriou on 17/08/2005 14.43.17 >> >>Please respond to dpapadimitriou@psg.com; Please respond to >> dimitri.papadimitriou@alcatel.be >> >>To: richard.spencer@bt.com >>cc: dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com, >> adrian@olddog.co.uk, ccamp@ops.ietf.org >> >>Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] >> >> >> >>richard, >> >> >> >>>Dimitri, >>> >>>"why (and where) ring topologies are suitable" ? >>> >>>Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will >>>continue to be, widely deployed based on (dual) ring topologies in >>>the access/metro because they provide fast protection and reliability >>>whilst making efficient use of fibre. >>> >>>I do not think this can be disputed so I don't understand where you >>>are coming from with this question? >> >> >>while i do not see why this can't be discussed (e.g. there are dozens of >>studies available on this topic) and i can just point out that one can >>deliver fast (time efficient), resource efficient and reliable >>protection without using rings >> >>therefore, it would worth having some operational feedback and state >>what are the real drivers and rationales if such topic is getting >>started i.e. what is the real appealing rationale behind this mechanism >> >>note: these are just questions that i think where missing from most >>documents produced on this topic since so far and that are important to >>be addressed >> >>last point you are mentioning RPR so what would be the interaction with >>the IPORPR WG ? >> >> >> >>>Regards, Richard >>> >>> >>> >>> >>>. >>> >> >> >> >> >> >> >> >> >> >> >> >>. >> > > > > > > > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 09:28:24 +0000 Sensitivity: Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: "dimitri.papadimitriou" , "\"\"richard.spencer\" , "adrian , "ccamp Message-ID: From: "Diego Caviglia" Date: Thu, 18 Aug 2005 11:26:58 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Dimitri, in line. Regards Diego dimitri papadimitriou on 17/08/2005 17.01.23 Please respond to dpapadimitriou@psg.com; Please respond to dimitri.papadimitriou@alcatel.be To: Diego Caviglia cc: dimitri.papadimitriou@alcatel.be, "richard.spencer" , adrian , ccamp Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] diego Diego Caviglia wrote: > Hi Dimitri, > given the high number of MS-SPRing protected transport network > already deployed seems reasonable to me, from a Network Operator point of > view, to use at the same time MS-SPRing protection with GMPLS restoration. there are already two questions here 1. is there an operational need to control such rings using GMPLS (? for instance is it effective knowing that ring based protection is mainly data plane driven ?) [dc] I prefer to hear something from the Operator here even if my experience tell me that the answer is yes. and 2. how to position the ring protection wrt to the LSP recovery segment/end-to-end recovery [dc] I'm sure I've got the point here sorry, what exatly do you mean with position? > Let's say the first failure is recovered via MS-SPRing in less than 50 ms > while subsequent failures can be recovered via GMPLS restoration with lower > performance. is it because it is a "local" protection (i.e. wouldn't a segment recovery provide the same time efficiency) or because it is ring based [dc] It is because is performed at the SDH layer, all the SDH protection scheme I know have the same performance (e.g. SNCP, MSP) > Basically that is the rationale behind my initial question. > > What is your view on that? my view is that a problem statement should cover such base questions - i am in agreement with adrian stand here - [dc] I'm trying to put togheter a requirement doc that briefly illustrates how MS-SPRing works and what are the information that it needs in order to work corretly. > Regards > > Diego > > > > dimitri papadimitriou on 17/08/2005 14.43.17 > > Please respond to dpapadimitriou@psg.com; Please respond to > dimitri.papadimitriou@alcatel.be > > To: richard.spencer@bt.com > cc: dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com, > adrian@olddog.co.uk, ccamp@ops.ietf.org > > Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] > > > > richard, > > >>Dimitri, >> >>"why (and where) ring topologies are suitable" ? >> >>Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will >>continue to be, widely deployed based on (dual) ring topologies in >>the access/metro because they provide fast protection and reliability >>whilst making efficient use of fibre. >> >>I do not think this can be disputed so I don't understand where you >>are coming from with this question? > > > while i do not see why this can't be discussed (e.g. there are dozens of > studies available on this topic) and i can just point out that one can > deliver fast (time efficient), resource efficient and reliable > protection without using rings > > therefore, it would worth having some operational feedback and state > what are the real drivers and rationales if such topic is getting > started i.e. what is the real appealing rationale behind this mechanism > > note: these are just questions that i think where missing from most > documents produced on this topic since so far and that are important to > be addressed > > last point you are mentioning RPR so what would be the interaction with > the IPORPR WG ? > > >>Regards, Richard >> >> >> >> >>. >> > > > > > > > > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 18 Aug 2005 01:22:35 +0000 Message-Id: <5.1.1.9.2.20050818095638.0692ebe0@mailsv4.y.ecl.ntt.co.jp> Date: Thu, 18 Aug 2005 10:20:13 +0900 To: "Adrian Farrel" , From: Wataru Imajuku Subject: Re: Moving forward with the CCAMP charter Cc: , "'Kireeti Kompella'" Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Hi, Adrian Thank you for sending milestones. I noticed that the issue of coordination with lcas & vcat will be based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt I understand that LCAS/VCAT control draft will be done in single draft which have statements all of requirements, analysis, and solution. I believe that my draft includes some issues which have not addressed in bernsteins draft. For example, the issue of section 5 in my draft. This is important issue when LCAS&VCAT will be applied in MRN. I understand your proposal is my requirement draft draft-imajuku-ccamp-gmpls-vcat&lagr-req-00.txt will be merged with draft-bernstein-ccamp-.... or simply discard ? Best Regards, Wataru >Hi, > >Please find attached a file that contains: > >- a set of proposed *draft* milestones >- a discussion of why there are so many milestones >- a high-level explanation of the work items. > >Note that this looks like a lot of milestones, but please read the text on >this issue in the attached file. The bottom line is that this is a product >of micro management where I have tried to identify all of the I-Ds that we >might produce to cover the referenced work, and where I have placed two >(sometimes three) milestones for each I-D. > >This micro-management may be over the top, and represents a full pendulum >swing from the previous style of CCAMP milestones, but in the light of the >hiatus of the last 12 months, i think this may be beneficial and might >achieve rapid forwards movement. > >I would welcome your (constructive!) comments. > >Notes: >- Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. >- Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > >The objective is to have the WG agreed on the milestones that it wants to >commit to by the end of August. > >Thanks, >Adrian --------------------------------- Wataru Imajuku Senior Research Engineer @NTT Network Innovation Labs. TEL +81-46-859-4315 FAX +81-46-859-5541 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 20:02:01 +0000 Message-ID: <4303975D.9060007@grotto-networking.com> Date: Wed, 17 Aug 2005 13:00:29 -0700 From: Greg Bernstein User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: Diego Caviglia CC: Adrian Farrel , " Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Diego, there is interest on my part on working with other protection schemes. In general I'm interested in the inter-operation and optimal selection of protection/restoration schemes at different layers. I'm busy this week but next week I expect to also get back to the VCAT draft and review the various notes and such from the other SDOs. Greg B. Diego Caviglia wrote: >Adrian, > actually I have a draft on this matter under my pillow ;-)) it is >quite rought but can be interestion to start the discussion. > >I'll post it ASAP, anyway it there any interest from the community on this >subject? > >Regards > >Diego > > > >"Adrian Farrel" on 17/08/2005 11.44.03 > >Please respond to "Adrian Farrel" > >To: , "Diego Caviglia" >cc: > >Subject: MS-SPring [Was: Moving forward with the CCAMP charter] > >Hi Diego, > >I can well believe that this is something that should/could be of interest >to CCAMP. > >It would be premature, however, to put explicit milestones on our charter >without first seeing some work on the subject and support from the >community. > >At the very least we would need to scope the problem and understand >whether there is any work to be done. If anyone wants to write a draft on >this so that we can all understand the problem space, I am sure it would >be welcomed. > >Cheers, >Adrian >----- Original Message ----- >From: "Diego Caviglia" >To: >Sent: Wednesday, August 17, 2005 8:13 AM >Subject: Re: Moving forward with the CCAMP charter > > > > >>Hi Adrian and all, >> I've a question about GMPLS interworking with inherent >>protection scheme. >> >>With inherent protection scheme I mean e.g. MS-SPRing in transport >> >> >network. > > >>MS-SPring is widely deployed and IMHO interworking between that >> >> >protection > > >>scheme and GMPLS should be foreseen. >>Unfortunately there are some constraints to be satisfied (timeslot >>interchange and squelching table) when an LSP is created on a MS-SPRing. >> >>And now the question is this kind of interworking something that should >> >> >be > > >>covered in CCAMP (I know that there are some Study Point in ITU-T to >> >> >cover > > >>this issues)? >> >>IMHO I think the answer is yes but I like to know the feeling of the >> >> >other > > >>guys here. >> >>Regards >> >>Diego >> >> >> >> >> >> >> >> >> > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 17:16:28 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A34E.EC43544D" Subject: RE: Responding to the OIF Date: Wed, 17 Aug 2005 12:11:05 -0500 Message-ID: Thread-Topic: Responding to the OIF Thread-Index: AcWecho8wbE0LxlVRcuVSb1RRGwsbgE2T2sg From: "Mack-Crane, T. Benjamin" To: "Adrian Farrel" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A34E.EC43544D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi, Regarding the first item, we should have only one TSPEC encoding for STS-3c SPE/VC-4 since the intent is to unify signaling for SONET and SDH. Furthermore, contiguous concatenation with one element doesn't make sense. Thus we should change example 8 to match example 1 (in the same way that example 9 matches example 3) and leave the text that indicates RCC != 0 implies NCC>1. Regards, Ben ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, August 11, 2005 7:43 AM To: ccamp@ops.ietf.org Subject: Responding to the OIF Hi, As Lyndon noted in Paris, the OIF has sent us a communication requesting some guidance on a bunch of questions. This is to start the business of constructing a reply. thanks to Dimitri for supplying some of this text. Please send comments and improvements. Adrian ====== 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. 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. We believe that this final sentence should read "greater than or equal to 1," and that this interpretation resolves all of your issues and makes the text consistent with the examples. > 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, an 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. > 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 is currently discussing the use of GMPLS for control of Ethernet devices. We will respond to this point in a separate email. Best regards, Adrian Farrel Kireeti Kompella ============================================================ 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_01C5A34E.EC43544D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="us-ascii"
Hi,
 
Regarding the first item, we should have only one TSPEC encoding for STS-3c SPE/VC-4 since the intent is to unify signaling for SONET and SDH. 
 
Furthermore, contiguous concatenation with one element doesn't make sense.
 
Thus we should change example 8 to match example 1 (in the same way that example 9 matches example 3) and leave the text that indicates RCC != 0 implies NCC>1.
 
Regards,
Ben

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
Sent: Thursday, August 11, 2005 7:43 AM
To: ccamp@ops.ietf.org
Subject: Responding to the OIF

Hi,

As Lyndon noted in Paris, the OIF has sent us a communication requesting some guidance on a bunch of questions.

This is to start the business of constructing a reply. thanks to Dimitri for supplying some of this text.

Please send comments and improvements.

Adrian

======

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.

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.

We believe that this final sentence should read "greater than or equal to 1," and that this interpretation resolves all of your issues and makes the text consistent with the examples.

> 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, an 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.

> 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...
 
   <Hello Message> ::= <Common Header> [ <INTEGRITY> ]
                              <HELLO>
 
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 is currently discussing the use of GMPLS for control of Ethernet devices. We will respond to this point in a separate email.

Best regards,
Adrian Farrel
Kireeti Kompella
============================================================
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_01C5A34E.EC43544D-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 15:02:29 +0000 Message-ID: <43035143.30301@psg.com> Date: Wed, 17 Aug 2005 17:01:23 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Diego Caviglia CC: dimitri.papadimitriou@alcatel.be, "richard.spencer" , adrian , ccamp Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit diego Diego Caviglia wrote: > Hi Dimitri, > given the high number of MS-SPRing protected transport network > already deployed seems reasonable to me, from a Network Operator point of > view, to use at the same time MS-SPRing protection with GMPLS restoration. there are already two questions here 1. is there an operational need to control such rings using GMPLS (? for instance is it effective knowing that ring based protection is mainly data plane driven ?) and 2. how to position the ring protection wrt to the LSP recovery segment/end-to-end recovery > Let's say the first failure is recovered via MS-SPRing in less than 50 ms > while subsequent failures can be recovered via GMPLS restoration with lower > performance. is it because it is a "local" protection (i.e. wouldn't a segment recovery provide the same time efficiency) or because it is ring based > Basically that is the rationale behind my initial question. > > What is your view on that? my view is that a problem statement should cover such base questions - i am in agreement with adrian stand here - > Regards > > Diego > > > > dimitri papadimitriou on 17/08/2005 14.43.17 > > Please respond to dpapadimitriou@psg.com; Please respond to > dimitri.papadimitriou@alcatel.be > > To: richard.spencer@bt.com > cc: dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com, > adrian@olddog.co.uk, ccamp@ops.ietf.org > > Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] > > > > richard, > > >>Dimitri, >> >>"why (and where) ring topologies are suitable" ? >> >>Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will >>continue to be, widely deployed based on (dual) ring topologies in >>the access/metro because they provide fast protection and reliability >>whilst making efficient use of fibre. >> >>I do not think this can be disputed so I don't understand where you >>are coming from with this question? > > > while i do not see why this can't be discussed (e.g. there are dozens of > studies available on this topic) and i can just point out that one can > deliver fast (time efficient), resource efficient and reliable > protection without using rings > > therefore, it would worth having some operational feedback and state > what are the real drivers and rationales if such topic is getting > started i.e. what is the real appealing rationale behind this mechanism > > note: these are just questions that i think where missing from most > documents produced on this topic since so far and that are important to > be addressed > > last point you are mentioning RPR so what would be the interaction with > the IPORPR WG ? > > >>Regards, Richard >> >> >> >> >>. >> > > > > > > > > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 12:55:38 +0000 Sensitivity: Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: "richard.spencer" , "adrian" , "ccamp" Message-ID: From: "Diego Caviglia" Date: Wed, 17 Aug 2005 14:55:09 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Dimitri, given the high number of MS-SPRing protected transport network already deployed seems reasonable to me, from a Network Operator point of view, to use at the same time MS-SPRing protection with GMPLS restoration. Let's say the first failure is recovered via MS-SPRing in less than 50 ms while subsequent failures can be recovered via GMPLS restoration with lower performance. Basically that is the rationale behind my initial question. What is your view on that? Regards Diego dimitri papadimitriou on 17/08/2005 14.43.17 Please respond to dpapadimitriou@psg.com; Please respond to dimitri.papadimitriou@alcatel.be To: richard.spencer@bt.com cc: dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com, adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] richard, > Dimitri, > > "why (and where) ring topologies are suitable" ? > > Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will > continue to be, widely deployed based on (dual) ring topologies in > the access/metro because they provide fast protection and reliability > whilst making efficient use of fibre. > > I do not think this can be disputed so I don't understand where you > are coming from with this question? while i do not see why this can't be discussed (e.g. there are dozens of studies available on this topic) and i can just point out that one can deliver fast (time efficient), resource efficient and reliable protection without using rings therefore, it would worth having some operational feedback and state what are the real drivers and rationales if such topic is getting started i.e. what is the real appealing rationale behind this mechanism note: these are just questions that i think where missing from most documents produced on this topic since so far and that are important to be addressed last point you are mentioning RPR so what would be the interaction with the IPORPR WG ? > Regards, Richard > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 12:44:19 +0000 Message-ID: <430330E5.2010204@psg.com> Date: Wed, 17 Aug 2005 14:43:17 +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.8) Gecko/20050511 MIME-Version: 1.0 To: richard.spencer@bt.com CC: dimitri.papadimitriou@alcatel.be, Diego.Caviglia@marconi.com, adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit richard, > Dimitri, > > "why (and where) ring topologies are suitable" ? > > Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will > continue to be, widely deployed based on (dual) ring topologies in > the access/metro because they provide fast protection and reliability > whilst making efficient use of fibre. > > I do not think this can be disputed so I don't understand where you > are coming from with this question? while i do not see why this can't be discussed (e.g. there are dozens of studies available on this topic) and i can just point out that one can deliver fast (time efficient), resource efficient and reliable protection without using rings therefore, it would worth having some operational feedback and state what are the real drivers and rationales if such topic is getting started i.e. what is the real appealing rationale behind this mechanism note: these are just questions that i think where missing from most documents produced on this topic since so far and that are important to be addressed last point you are mentioning RPR so what would be the interaction with the IPORPR WG ? > Regards, Richard > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 12:05:14 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: MS-SPring [Was: Moving forward with the CCAMP charter] Date: Wed, 17 Aug 2005 13:03:41 +0100 Message-ID: Thread-Topic: MS-SPring [Was: Moving forward with the CCAMP charter] Thread-Index: AcWjH2vMWzPf62cUTzqgbYx2IvS5IAAAaeKA From: To: , , Cc: , Dimitri, "why (and where) ring topologies are suitable" ? Transport networks (e.g. SONET/SDH, WDM, RPR) have been, and will = continue to be, widely deployed based on (dual) ring topologies in the = access/metro because they provide fast protection and reliability whilst = making efficient use of fibre. I do not think this can be disputed so I don't understand where you are = coming from with this question? Regards, Richard =20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 11:32:48 +0000 Message-ID: <43031FEF.2080308@psg.com> Date: Wed, 17 Aug 2005 13:30:55 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Diego Caviglia CC: dimitri.papadimitriou@alcatel.be, "Adrian Farrel , ccamp Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi diego Diego Caviglia wrote: > Hi Dimitri, > of course you're right this is not the first in we discuss > MS-SPRing in CCAMP, anyway given that we are discussing the new charter of > the WG this could be a good moment to decide if interworking between > MS-SPRing and GMPLS is something that we need to cover. > > I'll try to answer to your questions. > >>"why ring topologies" > > Because there is a plenty of ring topology in the transport world. i know but i will clarify the question because the question is to be put in perspective "why (and where) ring topologies are suitable" ? >>and for which kind of switching technology ? > > I was thinking about SDH. and what does prevent a WG like CCAMP to restrict applicability to circuit ? reason for providing an answer to initial question > Regards > > Diego > > > > > > dimitri papadimitriou on 17/08/2005 13.05.26 > > Please respond to dpapadimitriou@psg.com; Please respond to > dimitri.papadimitriou@alcatel.be > > To: Adrian Farrel > cc: ccamp@ops.ietf.org, Diego Caviglia > > Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] > > hi adrian - > > the "ring" topic is part of a set that comes out on a periodic yearly > basis where one sees some interest popping up and then slowing down (it > used also to be a topic of discussion at the former IPO WG) > > however, the first question is "why ring topologies" ? and for which > kind of switching technology ? > > thanks, > - dimitri. > > Adrian Farrel wrote: > > >>Hi Diego, >> >>I can well believe that this is something that should/could be of > > interest > >>to CCAMP. >> >>It would be premature, however, to put explicit milestones on our charter >>without first seeing some work on the subject and support from the >>community. >> >>At the very least we would need to scope the problem and understand >>whether there is any work to be done. If anyone wants to write a draft on >>this so that we can all understand the problem space, I am sure it would >>be welcomed. >> >>Cheers, >>Adrian >>----- Original Message ----- >>From: "Diego Caviglia" >>To: >>Sent: Wednesday, August 17, 2005 8:13 AM >>Subject: Re: Moving forward with the CCAMP charter >> >> >> >> >>>Hi Adrian and all, >>> I've a question about GMPLS interworking with inherent >>>protection scheme. >>> >>>With inherent protection scheme I mean e.g. MS-SPRing in transport >> >>network. >> >> >>>MS-SPring is widely deployed and IMHO interworking between that >> >>protection >> >> >>>scheme and GMPLS should be foreseen. >>>Unfortunately there are some constraints to be satisfied (timeslot >>>interchange and squelching table) when an LSP is created on a MS-SPRing. >>> >>>And now the question is this kind of interworking something that should >> >>be >> >> >>>covered in CCAMP (I know that there are some Study Point in ITU-T to >> >>cover >> >> >>>this issues)? >>> >>>IMHO I think the answer is yes but I like to know the feeling of the >> >>other >> >> >>>guys here. >>> >>>Regards >>> >>>Diego >>> >>> >>> >>> >>> >>> >>> >> >> >> >> >>. >> > > > > > > > > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 11:12:36 +0000 Sensitivity: Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: "Adrian Farrel , "ccamp" Message-ID: From: "Diego Caviglia" Date: Wed, 17 Aug 2005 13:11:44 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Dimitri, of course you're right this is not the first in we discuss MS-SPRing in CCAMP, anyway given that we are discussing the new charter of the WG this could be a good moment to decide if interworking between MS-SPRing and GMPLS is something that we need to cover. I'll try to answer to your questions. >"why ring topologies" Because there is a plenty of ring topology in the transport world. >and for which kind of switching technology ? I was thinking about SDH. Regards Diego dimitri papadimitriou on 17/08/2005 13.05.26 Please respond to dpapadimitriou@psg.com; Please respond to dimitri.papadimitriou@alcatel.be To: Adrian Farrel cc: ccamp@ops.ietf.org, Diego Caviglia Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] hi adrian - the "ring" topic is part of a set that comes out on a periodic yearly basis where one sees some interest popping up and then slowing down (it used also to be a topic of discussion at the former IPO WG) however, the first question is "why ring topologies" ? and for which kind of switching technology ? thanks, - dimitri. Adrian Farrel wrote: > Hi Diego, > > I can well believe that this is something that should/could be of interest > to CCAMP. > > It would be premature, however, to put explicit milestones on our charter > without first seeing some work on the subject and support from the > community. > > At the very least we would need to scope the problem and understand > whether there is any work to be done. If anyone wants to write a draft on > this so that we can all understand the problem space, I am sure it would > be welcomed. > > Cheers, > Adrian > ----- Original Message ----- > From: "Diego Caviglia" > To: > Sent: Wednesday, August 17, 2005 8:13 AM > Subject: Re: Moving forward with the CCAMP charter > > > >>Hi Adrian and all, >> I've a question about GMPLS interworking with inherent >>protection scheme. >> >>With inherent protection scheme I mean e.g. MS-SPRing in transport > > network. > >>MS-SPring is widely deployed and IMHO interworking between that > > protection > >>scheme and GMPLS should be foreseen. >>Unfortunately there are some constraints to be satisfied (timeslot >>interchange and squelching table) when an LSP is created on a MS-SPRing. >> >>And now the question is this kind of interworking something that should > > be > >>covered in CCAMP (I know that there are some Study Point in ITU-T to > > cover > >>this issues)? >> >>IMHO I think the answer is yes but I like to know the feeling of the > > other > >>guys here. >> >>Regards >> >>Diego >> >> >> >> >> >> >> > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 11:06:32 +0000 Message-ID: <430319F6.3050302@psg.com> Date: Wed, 17 Aug 2005 13:05:26 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, Diego Caviglia Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian - the "ring" topic is part of a set that comes out on a periodic yearly basis where one sees some interest popping up and then slowing down (it used also to be a topic of discussion at the former IPO WG) however, the first question is "why ring topologies" ? and for which kind of switching technology ? thanks, - dimitri. Adrian Farrel wrote: > Hi Diego, > > I can well believe that this is something that should/could be of interest > to CCAMP. > > It would be premature, however, to put explicit milestones on our charter > without first seeing some work on the subject and support from the > community. > > At the very least we would need to scope the problem and understand > whether there is any work to be done. If anyone wants to write a draft on > this so that we can all understand the problem space, I am sure it would > be welcomed. > > Cheers, > Adrian > ----- Original Message ----- > From: "Diego Caviglia" > To: > Sent: Wednesday, August 17, 2005 8:13 AM > Subject: Re: Moving forward with the CCAMP charter > > > >>Hi Adrian and all, >> I've a question about GMPLS interworking with inherent >>protection scheme. >> >>With inherent protection scheme I mean e.g. MS-SPRing in transport > > network. > >>MS-SPring is widely deployed and IMHO interworking between that > > protection > >>scheme and GMPLS should be foreseen. >>Unfortunately there are some constraints to be satisfied (timeslot >>interchange and squelching table) when an LSP is created on a MS-SPRing. >> >>And now the question is this kind of interworking something that should > > be > >>covered in CCAMP (I know that there are some Study Point in ITU-T to > > cover > >>this issues)? >> >>IMHO I think the answer is yes but I like to know the feeling of the > > other > >>guys here. >> >>Regards >> >>Diego >> >> >> >> >> >> >> > > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 10:24:44 +0000 Sensitivity: Subject: Re: MS-SPring [Was: Moving forward with the CCAMP charter] To: "Adrian Farrel" Cc: " Message-ID: From: "Diego Caviglia" Date: Wed, 17 Aug 2005 12:24:11 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Adrian, actually I have a draft on this matter under my pillow ;-)) it is quite rought but can be interestion to start the discussion. I'll post it ASAP, anyway it there any interest from the community on this subject? Regards Diego "Adrian Farrel" on 17/08/2005 11.44.03 Please respond to "Adrian Farrel" To: , "Diego Caviglia" cc: Subject: MS-SPring [Was: Moving forward with the CCAMP charter] Hi Diego, I can well believe that this is something that should/could be of interest to CCAMP. It would be premature, however, to put explicit milestones on our charter without first seeing some work on the subject and support from the community. At the very least we would need to scope the problem and understand whether there is any work to be done. If anyone wants to write a draft on this so that we can all understand the problem space, I am sure it would be welcomed. Cheers, Adrian ----- Original Message ----- From: "Diego Caviglia" To: Sent: Wednesday, August 17, 2005 8:13 AM Subject: Re: Moving forward with the CCAMP charter > Hi Adrian and all, > I've a question about GMPLS interworking with inherent > protection scheme. > > With inherent protection scheme I mean e.g. MS-SPRing in transport network. > > MS-SPring is widely deployed and IMHO interworking between that protection > scheme and GMPLS should be foreseen. > Unfortunately there are some constraints to be satisfied (timeslot > interchange and squelching table) when an LSP is created on a MS-SPRing. > > And now the question is this kind of interworking something that should be > covered in CCAMP (I know that there are some Study Point in ITU-T to cover > this issues)? > > IMHO I think the answer is yes but I like to know the feeling of the other > guys here. > > Regards > > Diego > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 10:20:54 +0000 Message-ID: <02cd01c5a315$9f5389e0$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , "Diego Caviglia" Subject: MS-SPring [Was: Moving forward with the CCAMP charter] Date: Wed, 17 Aug 2005 10:44:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Diego, I can well believe that this is something that should/could be of interest to CCAMP. It would be premature, however, to put explicit milestones on our charter without first seeing some work on the subject and support from the community. At the very least we would need to scope the problem and understand whether there is any work to be done. If anyone wants to write a draft on this so that we can all understand the problem space, I am sure it would be welcomed. Cheers, Adrian ----- Original Message ----- From: "Diego Caviglia" To: Sent: Wednesday, August 17, 2005 8:13 AM Subject: Re: Moving forward with the CCAMP charter > Hi Adrian and all, > I've a question about GMPLS interworking with inherent > protection scheme. > > With inherent protection scheme I mean e.g. MS-SPRing in transport network. > > MS-SPring is widely deployed and IMHO interworking between that protection > scheme and GMPLS should be foreseen. > Unfortunately there are some constraints to be satisfied (timeslot > interchange and squelching table) when an LSP is created on a MS-SPRing. > > And now the question is this kind of interworking something that should be > covered in CCAMP (I know that there are some Study Point in ITU-T to cover > this issues)? > > IMHO I think the answer is yes but I like to know the feeling of the other > guys here. > > Regards > > Diego > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 10:20:47 +0000 Message-ID: <02cc01c5a315$9da4a160$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Tomohiro Otani" Cc: "JP Vasseur" , , , "'Kireeti Kompella'" Subject: Inter-AS GMPLS [Was: Moving forward with the CCAMP charter] Date: Wed, 17 Aug 2005 10:41:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tomo, > Being related with your text and JP's messages, I would ask you > to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt. > Is this related with a kind of baseline for (1) Analysis of inter-domain > issues ? > > So far, there is a proposed draft of GMPLS inter-domain signaling > as we discussed in Paris, but there is no draft of GMPLS inter-domain > routing definition whether it is with TE extension or not. > (your framework draft covers these points) Good point. It seems that your draft is discussing two things: 1. TE reachability information exchange 2. Exchange of aggregated TE information for a domain As you point out in section 4.2, the issue of scalability and policy needs to be carefully considered before we pursue this too much further. I think your work, especially the aggregation issues, meshes nicely with the recent draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt. Therefore, I propose the following changes to the draft I sent out before... 1. Delete Jan 06 First version WG I-D Routing and signaling for complex optical constraints Oct 07 Submit Routing and signaling for complex optical constraints I-D for IESG review 2. Insert Jan 06 First version WG I-D Routing and signaling for link viability constraints Oct 07 Submit Routing and signaling for link viability constraints I-D for IESG review 3. Delete More forward-looking ==================== Routing and signaling for complex constraints and inter-domain * first version of WG draft - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt * submit for IESG review 4. Add to Inter-domain section - Analysis and protocol changes for routing and signaling for link viability constraints * first version of WG draft - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt - material from draft-otani-ccamp-interas-gmpls-te-03.txt * submit for IESG review Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 09:22:37 +0000 Message-ID: <02bd01c5a30d$4a573a20$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "CHO, JAI HYUNG" , Subject: L2SC [Was: Moving forward with the CCAMP charter] Date: Wed, 17 Aug 2005 10:20:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Jaihyung, The Ethernet GMPLS work has certainly not been forgotten! The work of the design team is very important and we need more people to read and digest draft-papadimitriou-ccamp-gmpls-ethernet-framework-00.txt. it is particularly important that folk read this draft rather than relying on scare stories or email threads. Many of the common concerns and issues have been carefully answered by the DT, and many of the other are not actually raised in this draft. For the moment, the CCAMP list remains the correct place to discuss these issues, but it would seem that the work involved is both larger than the scope of the CCAMP charter and larger than can be easily swallowed by the existing working group (you will have noticed that there are plenty of other things to occupy the WG's time). For this reason (and see the CCAMP draft minutes) we are currently investigating whether there could be a better home for this work. The most obvious solution is to create a new WG, but this would obviously require careful scoping and also would need support from the community. More information on this as it becomes available. Thanks, Adrian ----- Original Message ----- From: "CHO, JAI HYUNG" To: "Adrian Farrel" ; Sent: Wednesday, August 17, 2005 9:10 AM Subject: RE: Moving forward with the CCAMP charter > > Hi, Adrian > > Thank you for your milestone work. > However, I can not find L2SC work in your document. > Where does it belong to ? > I believe there's some number of people supporting thie work > and also we see clear industry need for this work. > I think it would be good if we have L2SC milestone > at least for framework and solution document. > > thanks > > Jaihyung > > > Dr. Jaihyung Cho > ETRI, Korea > phone : 042) 860-5514 > oversea: +82-42-860-5514 > fax: +82-42-861-5550 > > > > > -----?? ???----- > From: "Adrian Farrel" > From Date: 2005-08-16 ?? 8:28:11 > To: "ccamp@ops.ietf.org" > Cc: "zinin@psg.com" , "'Kireeti Kompella'" > Subject: Moving forward with the CCAMP charter > > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. > > This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. > > Thanks, > Adrian > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 09:22:29 +0000 Message-ID: <02be01c5a30d$4c0add90$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Kenji Kumaki" Cc: , , "'Kireeti Kompella'" Subject: Re: Moving forward with the CCAMP charter Date: Wed, 17 Aug 2005 10:23:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Kenji, > I have some comments on new items. > > >MPLS-GMPLS interworking requirements and solutions > > * first version of WG draft > > - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt > > * submit for IESG review > > draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt includes MPLS/GMPLS > interworking requirements and soultions. > So I think this draft should be put in the first version of WG draft. As I said > > - Why isn't my I-D also cited as input material? > > No insult intended. The current list is simply there to > > show the ADs that work is already in progress. All I-Ds > > will be used as input. > >MPLS to GMPLS migration strategies > > * Informational I-D first version of WG draft > > - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt > > - material from draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt > > * submit Informational I-D for IESG review > > Zafar's draft is merged into draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt. > So I think you should replace Zafar's to mine. Noted. Cheers, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 08:09:07 +0000 Thread-Topic: Moving forward with the CCAMP charter thread-index: AcWjAzLQlIm8Cix3SeGqvAwPJttkLQ== Reply-To: "CHO, JAI HYUNG" From: "CHO, JAI HYUNG" To: "Adrian Farrel" , Cc: Bcc: Subject: RE: Moving forward with the CCAMP charter Date: Wed, 17 Aug 2005 17:10:58 +0900 Comment: GQ19@|@ZEk=E?,18?x, BcN1b MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Hi, Adrian Thank you for your milestone work. However, I can not find L2SC work in your document. Where does it belong to ? I believe there's some number of people supporting thie work and also we see clear industry need for this work. I think it would be good if we have L2SC milestone at least for framework and solution document. thanks Jaihyung Dr. Jaihyung Cho ETRI, Korea phone : 042) 860-5514 oversea: +82-42-860-5514 fax: +82-42-861-5550 -----?? ???----- From: "Adrian Farrel" >From Date: 2005-08-16 ?? 8:28:11 To: "ccamp@ops.ietf.org" Cc: "zinin@psg.com" , "'Kireeti Kompella'" Subject: Moving forward with the CCAMP charter Hi, Please find attached a file that contains: - a set of proposed *draft* milestones - a discussion of why there are so many milestones - a high-level explanation of the work items. Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. I would welcome your (constructive!) comments. Notes: - Why isn't my I-D also cited as input material? No insult intended. The current list is simply there to show the ADs that work is already in progress. All I-Ds will be used as input. - Why isn't my pet topic included? Are you sure it is not there between the lines? This list of milestones isn't completely proscriptive. The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 07:14:41 +0000 Subject: Re: Moving forward with the CCAMP charter Sensitivity: To: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Wed, 17 Aug 2005 09:13:28 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Hi Adrian and all, I've a question about GMPLS interworking with inherent protection scheme. With inherent protection scheme I mean e.g. MS-SPRing in transport network. MS-SPring is widely deployed and IMHO interworking between that protection scheme and GMPLS should be foreseen. Unfortunately there are some constraints to be satisfied (timeslot interchange and squelching table) when an LSP is created on a MS-SPRing. And now the question is this kind of interworking something that should be covered in CCAMP (I know that there are some Study Point in ITU-T to cover this issues)? IMHO I think the answer is yes but I like to know the feeling of the other guys here. Regards Diego Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 02:20:00 +0000 Date: Wed, 17 Aug 2005 11:18:18 +0900 From: Kenji Kumaki To: "Adrian Farrel" Subject: Re: Moving forward with the CCAMP charter Cc: , , "'Kireeti Kompella'" Message-Id: <20050817104106.7E90.KE-KUMAKI@kddi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Adrian, I have some comments on new items. >MPLS-GMPLS interworking requirements and solutions > * first version of WG draft > - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt > * submit for IESG review draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt includes MPLS/GMPLS interworking requirements and soultions. So I think this draft should be put in the first version of WG draft. >MPLS to GMPLS migration strategies > * Informational I-D first version of WG draft > - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt > - material from draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt > * submit Informational I-D for IESG review Zafar's draft is merged into draft-kumaki-ccamp-mpls-gmpls-interworking-01.txt. So I think you should replace Zafar's to mine. Thanks, Kenji On Tue, 16 Aug 2005 12:28:11 +0100 "Adrian Farrel" wrote: > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. > > This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. > > Thanks, > Adrian -- Kenji Kumaki Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 17 Aug 2005 01:05:15 +0000 Message-ID: <43028CCB.2090607@kddilabs.jp> Date: Wed, 17 Aug 2005 10:03:07 +0900 From: Tomohiro Otani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.8) Gecko/20050511 MIME-Version: 1.0 To: Adrian Farrel Cc: JP Vasseur , ccamp@ops.ietf.org, zinin@psg.com, 'Kireeti Kompella' Subject: Re: Moving forward with the CCAMP charter Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Adrian, Being related with your text and JP's messages, I would ask you to touch upon the draft: draft-otani-ccamp-interas-gmpls-te-03.txt. Is this related with a kind of baseline for (1) Analysis of inter-domain issues ? So far, there is a proposed draft of GMPLS inter-domain signaling as we discussed in Paris, but there is no draft of GMPLS inter-domain routing definition whether it is with TE extension or not. (your framework draft covers these points) Regards, tomo JP Vasseur wrote: >Hi Adrian, > >On Aug 16, 2005, at 2:53 PM, Adrian Farrel wrote: > >>> (1) Analysis of inter-domain issues for disjoint and protected paths >>> - Informational I-D to close off the topic and devolve to PCE >>> * first version of WG draft >>> * submit for IESG review >>> >>> Could you briefly elaborate on this item ? >>> >> >> I think we have the need for an informational I-D that is a bit >> like the >> existing inter-domain framework I-D, but that examines the more >> complex >> question of the provisioning of disjoint and protection paths across >> domain boundaries. I am aware that there a lot of ideas out there >> and that >> there has been a lot of research. I think we need to capture an >> overview. >> > >ok fair enough ... I'll be happy to provide my input on the topic (as >you can imagine ;-)) > >> It is my (personal - not WG chair) opinion that this I-D will point >> firmly >> at the PCE WG. But just as for single paths we discovered that >> there are >> some (limited) scenarios for single paths where signaling is >> suitable on >> its own, we may find some solutions for diverse and protected paths. >> >> >>> (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful- >>> shutdown, you may want to add draft-leroux-ccamp-ctrl- >>> saturation-01.txt ? >>> >> >> Yes. I am inclined to add a work item for "control plane robustness". >> > >Thanks. > >JP. > >> Adrian >> > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Aug 2005 23:34:25 +0000 Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <690B6C56-60F8-4F1F-8349-F3931878A0CA@cisco.com> Cc: , , "'Kireeti Kompella'" Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 19:33:13 -0400 To: "Adrian Farrel" Hi Adrian, On Aug 16, 2005, at 2:53 PM, Adrian Farrel wrote: >> (1) Analysis of inter-domain issues for disjoint and protected paths >> - Informational I-D to close off the topic and devolve to PCE >> * first version of WG draft >> * submit for IESG review >> >> Could you briefly elaborate on this item ? >> > > I think we have the need for an informational I-D that is a bit > like the > existing inter-domain framework I-D, but that examines the more > complex > question of the provisioning of disjoint and protection paths across > domain boundaries. I am aware that there a lot of ideas out there > and that > there has been a lot of research. I think we need to capture an > overview. > ok fair enough ... I'll be happy to provide my input on the topic (as you can imagine ;-)) > It is my (personal - not WG chair) opinion that this I-D will point > firmly > at the PCE WG. But just as for single paths we discovered that > there are > some (limited) scenarios for single paths where signaling is > suitable on > its own, we may find some solutions for diverse and protected paths. > > >> (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful- >> shutdown, you may want to add draft-leroux-ccamp-ctrl- >> saturation-01.txt ? >> > > Yes. I am inclined to add a work item for "control plane robustness". > Thanks. JP. > Adrian > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Aug 2005 22:42:55 +0000 Message-ID: <43026B6E.8070903@psg.com> Date: Wed, 17 Aug 2005 00:40:46 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Adrian Farrel CC: dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org, zinin@psg.com, 'Kireeti Kompella' Subject: Re: Moving forward with the CCAMP charter Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Adrian Farrel wrote: >>i would consider the saturarion document and probably cluster it with >>the set of items on "deployment/advices/BCPs/etc." > > Well, the control plane saturation I-D defines new protocol procedures and > encodings so it needs to be standards track if we do it. > > Thus my response to JP. i am fine with a category "control plane robustness" separated from the one mentioned here below note: however, i am not necessarily sure that the type outcome must be driver for classification e.g. the saturation document is an outcome of practicing RSVP-TE with mechanisms such as soft-provisioning > If you are raising a new category of work (and I know you commented on > this in Paris) for deployment/advices/BCPs/etc. I would appreciate it if > you could: > - compare what you want with "Interoperability reports and advice" > - suggest some I-D titles that you might > - want to see > - be willing to work on (note, these two categories do not have to > overlapping) yes, for the time being i think that two major topics are falling in this category: 1) TE link operation(s) and processing practices (which is at the end what makes GMPLS) is a typical topic that would require further development 2) inter-domain relationship(s)/exchanges and admission control policies >>there is an item on "OAM Requirements for GMPLS Networks" with a >>lifetime of around 18 months, while it is difficult to have a detailed >>view on them wouldn't be advisable to think upon starting an item mid of >>next year where details (could be info) would be put together > > I think there is some detail missing from your suggestion. I think you are > saying that we should plan to start developing solutions to meet the OAM > requirements that we will document. This sounds very good, but I am > unwilling to insert a milestone without knowing what we are going to work > on or whether anyone has any intention of doing the work or developing the > software. this is the reason why i did myself tried to position the requirement document (it is the same reasoning at the end) it is also clear that such a topic would benefit from more operational feedback on GMPLS network operation(s) > I would suggest that this is an item that we should monitor and know that > the chairs are likely to look favorably on solutions work that meets the > requirements. ok > In the back of my mind, however, is the tunnel trace I-D which lies in a > coffin with a stake through its heart. Not because there weren't > requirements (we have an RFC documenting the requirements) and not because > no-one wanted to write the I-D (we had several authors), but because > no-one wanted to implement. reason why it may be advisable to have a better view on the "toolset" that would be valuable for operating GMPLS networks (bottom-up) >>several questions >> >> > - ASON Routing solutions >> > * first version of WG draft >> > * submit for IESG review >> >>-> does this mean you envision a single document for IS-IS and OSPF >>(note i hope these can be submitted to the IESG by 2Q'06 instead of >>October 2006) also cross-WG review period should be considered > > Not clear that a BGP draft isn't needed too! a complete response to this question would deserve an I-D by itself ;-) > These are generic milestones (I have already proposed too many > milestones!). > If the changes are tiny and use existing TLVs then a single I-D will > probably do. > Otherwise, one I-D per protocol. ok >> > Mar 06 First version of WG informational I-D Aligning GMPLS protocols >>across the standards bodies >> >>and >> >> > - Aligning GMPLS protocols across the standards bodies >> > - Information I-D not intended for publication as an RFC >> > * first version of WG draft >> >>-> what the first sub-bullet implies ? note that i do not see other >>specific milestone(s) for this document while the second sub-bullet >>refers to a WG I-D ? > > Yes. We need to drive closer alignment between the various uses of GMPLS > protocols across the standard bodies. In order to colate our thoughts and > direct discussions in and out of CCAMP we will need to document our ideas > in an I-D. Because we wish to demonstrate CCAMP community cohesion behind > our thoughts, this will need to be a WG I-D (hence the milestone and > starred bullet). the objective is sensible and i also think valuable to have such common view been written down > However, it is far from clear that the I-D will need to progress to RFC. > After all, once we identify the actions that are needed, we will carry out > the actions. We will then need to update the I-D for further actions etc. > > If, on the other hand, the I-D turns out to document longer-term or > ongoing procedures (like the GMPLS change process) we will certainly need > to progress the I-D. so, this document is meant to be a "process" I-D; therefore, its progress is indeed dependent on action lines that are to be documented >> > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D >>for IESG review >> >>-> do you have more details on this specific work item > > Not completely sure. It seems to me that if we are doing stuff for > signaling, we should also do it for routing. It is possible that this > folds natrually into the existing signaling (addressing) I-D. Hence this > milestone depends on the work item... i see now to what you are referring to note: i would also suggest focusing the below reference i-d on addressing space setting and processing practices (as the name indicates) > Interoperability reports and advice > - signaling and routing > - already have draft-ietf-ccamp-gmpls-addressing-01.txt > * submit for IESG review > >>thanks for the hard work, > > > You're welcome. > Thanks for the support. > > Adrian > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Aug 2005 19:08:15 +0000 Message-ID: <01ed01c5a296$1bde3a30$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: , , "'Kireeti Kompella'" Subject: Re: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 20:08:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > i would consider the saturarion document and probably cluster it with > the set of items on "deployment/advices/BCPs/etc." Well, the control plane saturation I-D defines new protocol procedures and encodings so it needs to be standards track if we do it. Thus my response to JP. If you are raising a new category of work (and I know you commented on this in Paris) for deployment/advices/BCPs/etc. I would appreciate it if you could: - compare what you want with "Interoperability reports and advice" - suggest some I-D titles that you might - want to see - be willing to work on (note, these two categories do not have to overlapping) > there is an item on "OAM Requirements for GMPLS Networks" with a > lifetime of around 18 months, while it is difficult to have a detailed > view on them wouldn't be advisable to think upon starting an item mid of > next year where details (could be info) would be put together I think there is some detail missing from your suggestion. I think you are saying that we should plan to start developing solutions to meet the OAM requirements that we will document. This sounds very good, but I am unwilling to insert a milestone without knowing what we are going to work on or whether anyone has any intention of doing the work or developing the software. I would suggest that this is an item that we should monitor and know that the chairs are likely to look favorably on solutions work that meets the requirements. In the back of my mind, however, is the tunnel trace I-D which lies in a coffin with a stake through its heart. Not because there weren't requirements (we have an RFC documenting the requirements) and not because no-one wanted to write the I-D (we had several authors), but because no-one wanted to implement. > several questions > > > - ASON Routing solutions > > * first version of WG draft > > * submit for IESG review > > -> does this mean you envision a single document for IS-IS and OSPF > (note i hope these can be submitted to the IESG by 2Q'06 instead of > October 2006) also cross-WG review period should be considered Not clear that a BGP draft isn't needed too! These are generic milestones (I have already proposed too many milestones!). If the changes are tiny and use existing TLVs then a single I-D will probably do. Otherwise, one I-D per protocol. > > Mar 06 First version of WG informational I-D Aligning GMPLS protocols > across the standards bodies > > and > > > - Aligning GMPLS protocols across the standards bodies > > - Information I-D not intended for publication as an RFC > > * first version of WG draft > > -> what the first sub-bullet implies ? note that i do not see other > specific milestone(s) for this document while the second sub-bullet > refers to a WG I-D ? Yes. We need to drive closer alignment between the various uses of GMPLS protocols across the standard bodies. In order to colate our thoughts and direct discussions in and out of CCAMP we will need to document our ideas in an I-D. Because we wish to demonstrate CCAMP community cohesion behind our thoughts, this will need to be a WG I-D (hence the milestone and starred bullet). However, it is far from clear that the I-D will need to progress to RFC. After all, once we identify the actions that are needed, we will carry out the actions. We will then need to update the I-D for further actions etc. If, on the other hand, the I-D turns out to document longer-term or ongoing procedures (like the GMPLS change process) we will certainly need to progress the I-D. > > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D > for IESG review > > -> do you have more details on this specific work item Not completely sure. It seems to me that if we are doing stuff for signaling, we should also do it for routing. It is possible that this folds natrually into the existing signaling (addressing) I-D. Hence this milestone depends on the work item... Interoperability reports and advice - signaling and routing - already have draft-ietf-ccamp-gmpls-addressing-01.txt * submit for IESG review > thanks for the hard work, You're welcome. Thanks for the support. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Aug 2005 18:56:01 +0000 Message-ID: <01d501c5a294$48b973a0$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Zafar Ali \(zali\)" , Cc: , "Kireeti Kompella" Subject: Re: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 19:54:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Zafar, See my response to JP. Adrian ----- Original Message ----- From: "Zafar Ali (zali)" To: "Adrian Farrel" ; Cc: ; "Kireeti Kompella" Sent: Tuesday, August 16, 2005 3:34 PM Subject: RE: Moving forward with the CCAMP charter Hi Adrian, Graceful shutdown, a method for explicitly notifying a set of nodes that either a Link or an entire node will remove itself from the network or the protocol is going to be disabled for a link or a node, had good response when kireeti polled for charter updates some times back. We have been waiting for a charter update to move with this ID (draft-ali-ccamp-mpls-graceful-shutdown-xx.txt). I think got missed in your list. can you please include this work item in the milestone list as well. Thanks Regards... Zafar ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, August 16, 2005 7:28 AM To: ccamp@ops.ietf.org Cc: zinin@psg.com; 'Kireeti Kompella' Subject: Moving forward with the CCAMP charter Hi, Please find attached a file that contains: - a set of proposed *draft* milestones - a discussion of why there are so many milestones - a high-level explanation of the work items. Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. I would welcome your (constructive!) comments. Notes: - Why isn't my I-D also cited as input material? No insult intended. The current list is simply there to show the ADs that work is already in progress. All I-Ds will be used as input. - Why isn't my pet topic included? Are you sure it is not there between the lines? This list of milestones isn't completely proscriptive. The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Aug 2005 18:55:54 +0000 Message-ID: <01d401c5a294$477581f0$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "JP Vasseur" Cc: , , "'Kireeti Kompella'" Subject: Re: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 19:53:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > (1) Analysis of inter-domain issues for disjoint and protected paths > - Informational I-D to close off the topic and devolve to PCE > * first version of WG draft > * submit for IESG review > > Could you briefly elaborate on this item ? I think we have the need for an informational I-D that is a bit like the existing inter-domain framework I-D, but that examines the more complex question of the provisioning of disjoint and protection paths across domain boundaries. I am aware that there a lot of ideas out there and that there has been a lot of research. I think we need to capture an overview. It is my (personal - not WG chair) opinion that this I-D will point firmly at the PCE WG. But just as for single paths we discovered that there are some (limited) scenarios for single paths where signaling is suitable on its own, we may find some solutions for diverse and protected paths. > (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful- > shutdown, you may want to add draft-leroux-ccamp-ctrl- > saturation-01.txt ? Yes. I am inclined to add a work item for "control plane robustness". Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Aug 2005 16:49:56 +0000 Message-ID: <430218C9.3070903@psg.com> Date: Tue, 16 Aug 2005 18:48:09 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Adrian Farrel CC: ccamp@ops.ietf.org, zinin@psg.com, 'Kireeti Kompella' Subject: Re: Moving forward with the CCAMP charter Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian i would consider the saturarion document and probably cluster it with the set of items on "deployment/advices/BCPs/etc." there is an item on "OAM Requirements for GMPLS Networks" with a lifetime of around 18 months, while it is difficult to have a detailed view on them wouldn't be advisable to think upon starting an item mid of next year where details (could be info) would be put together several questions > - ASON Routing solutions > * first version of WG draft > * submit for IESG review -> does this mean you envision a single document for IS-IS and OSPF (note i hope these can be submitted to the IESG by 2Q'06 instead of October 2006) also cross-WG review period should be considered > Mar 06 First version of WG informational I-D Aligning GMPLS protocols across the standards bodies and > - Aligning GMPLS protocols across the standards bodies > - Information I-D not intended for publication as an RFC > * first version of WG draft -> what the first sub-bullet implies ? note that i do not see other specific milestone(s) for this document while the second sub-bullet refers to a WG I-D ? > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for IESG review -> do you have more details on this specific work item thanks for the hard work, - dimitri. Adrian Farrel wrote: > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. > > This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. > > Thanks, > Adrian > > > ------------------------------------------------------------------------ > > CCAMP Working Group - Rechartering Effort > > Below you will find > - a list of proposed milestones > - an explanation of why this is a long list > - overview of proposed drafts and work items > > In reviewing this we should look for: > - topics that are irrelevant or unwanted by the WG > - topics that have been left out but are wanted by the WG > - topics that have been assigned the wrong priority or urgency > - topics or collections or topics that are sufficiently large > to potentially warrant their own working group. > > Proposed New milestones > ----------------------- > > Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS and OSPF > Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh membership > Nov 05 Submit ASON Routing evaluation I-D for IESG review > Nov 05 First version of WG I-D on path computation implmentation advice > Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in ISIS and OSPF > Nov 05 First version WG I-D MPLS to GMPLS migration strategies > Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS > Nov 05 First version WG I-D Change of LSP ownership between management and control planes > Dec 05 First version of WG I-D for ASON Routing solutions > Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG review > Dec 05 Submit Per-domain path computation signaling I-D for IESG review > Dec 05 First version WG I-D Requirements for Multi-Layer and Multi-Region Networks > Dec 05 First version WG I-D for Evaluation of existing protocols for MLN/MRN > Dec 05 First version WG I-D for Protocol solutions for MLN/MRN > Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG review > Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review > Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module > Jan 06 First version WG Informational I-D for Analysis of inter-domain issues for disjoint and protected paths > Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF for IESG review > Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and solutions > Jan 06 First version WG I-D GMPLS OAM Requirements > Jan 06 First version WG I-D Routing and signaling for complex optical constraints > Feb 06 Submit LSP Stitching I-D for IESG review > Mar 06 First version of WG informational I-D Aligning GMPLS protocols across the standards bodies > Mar 06 Submit GMPLS routing and signaling interoperability advice I-D for IESG review > Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module > Mar 06 First version of WG I-D for additional MIB module to cover RSVP-TE signaling extensions > Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for IESG review > Jun 06 Submit Informational I-D for Analysis of inter-domain issues for disjoint and protected paths for IESG review > Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review > Jun 06 Submit Change of LSP ownership between management and control planes I-D for IESG review > Aug 06 Submit path computation implmentation advice I-D for IESG review > Oct 06 Submit ASON Routing solutions I-D for IESG review > Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D for IESG review > Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG review > Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for IESG review > Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review > Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review > Dec 06 Submit GMPLS OAM Requirements I-D for IESG review > Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review > Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review > Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor and IESG review > Oct 07 Submit Routing and signaling for complex optical constraints I-D for IESG review > Oct 07 Recharter or close Working Group > > > Why so many milestons? > ---------------------- > The number of milestones shown in this proposed list far exceeds > anything I have ever seen in a working group charter. This is > intentional and while it does indicate a heavy work-load it also > indicates a higher level of micro-management than is usual within > working groups. Thus two milestones are presented for each I-D > (adoption as a WG I-D, and passing to the IESG post-WG-last-call). > > This can be compared with the "normal" charter milestones which > include a single work-related item that may span several I-Ds and > refers vaguely only to the "submission" of I-Ds. > > In other words, reviewers of this list should not panic because > of its length, but should see this as beneficial. > > > Explanation of I-Ds and work items > ---------------------------------- > > The following text briefly introduces the work items that are > represented by the milestones listed above. In this text an > astrix (*) indicates a milestone to be set. > > The work is divided into several categories according to how > core it is and how it should be prioritized. Existing drafts > are referenced to indicate that work is already in progress - > this is not intended to provide a complete list of existing > drafts. > > Completing existing work > ======================== > > ASON > - ASON Routing evaluation > - already have draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt > * submit for IESG review > - ASON Routing solutions > * first version of WG draft > * submit for IESG review > - GMPLS signaling in support of Call Management > - already have draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt > * submit for IESG review > - GMPLS/ASON lexicography > - already have draft-ietf-ccamp-gmpls-ason-lexicography-03.txt > * submit for IESG review > - Aligning GMPLS protocols across the standards bodies > - Information I-D not intended for publication as an RFC > * first version of WG draft > > Interoperability reports and advice > - signaling and routing > - already have draft-ietf-ccamp-gmpls-addressing-01.txt > * submit for IESG review > - path computation > * first version of WG draft > - based on draft-otani-ccamp-gmpls-cspf-constraints-01.txt > * submit for IESG review > > Additional MIB modules > - OSPF-TE > * first version of WG draft > - based on draft-otani-ccamp-gmpls-ospf-mib-00.txt > * submit for IESG review > - ISIS-TE > * first version of WG draft > * submit for IESG review > - Signaling > - Need "living" MIB module under development to catch > the minor protocol extensions that have been made > * first version of WG draft > * submit for IESG review > > Inter-domain > - LSP Stitching > - already have draft-ietf-ccamp-lsp-stitching-01.txt > * submit for IESG review > - RSVP-TE extensions for interdomain > - already have draft-ietf-ccamp-inter-domain-rsvp-te-01.txt > * submit for IESG review > - Per-domain path computation signaling > - already have draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt > * submit for IESG review > - Analysis of inter-domain issues for disjoint and protected paths > - Informational I-D to close off the topic and devolve to PCE > * first version of WG draft > * submit for IESG review > > New items already started and within existing charter > ===================================================== > > Advertising TE Node Capabilities > - ISIS and OSPF in the same I-D > * first version of WG draft > - based on draft-vasseur-ccamp-te-node-cap-00.txt > * review by IGP working groups > * submit for IESG review > > Automatic discovery of MPLS-TE mesh membership > - depends on TE Node capabilities I-D > * first version of WG draft > - based on draft-vasseur-ccamp-automesh-00.txt > * submit for IESG review > > Multi-layer networks (also multi-region networks) > - Requirements > * first version of WG draft > - based on draft-shiomoto-ccamp-gmpls-mrn-reqs-02.txt > * submit for IESG review > - Evaluation of existing protocols > * first version of WG draft > - based on draft-leroux-ccamp-gmpls-mrn-eval-01.txt > * submit for IESG review > - Solutions > * first version of WG draft > - based on draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt > * submit for IESG review > > MPLS-GMPLS interworking requirements and solutions > * first version of WG draft > - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt > * submit for IESG review > > MPLS to GMPLS migration strategies > * Informational I-D first version of WG draft > - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt > - material from draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt > * submit Informational I-D for IESG review > > Minor items just starting but close to heart of WG > ================================================== > > GMPLS OAM Requirements > - Interesting and worthwhile > * first version of WG draft > - based on immature draft-nadeau-ccamp-gmpls-oam-requirements-00.txt > * submit for IESG review > > Minor items just starting and important becuase of inter-SDO interactions > ========================================================================= > > GMPLS coordination of VCAT and LCAS > - single requirements and solutions draft almost an applicablity statement > * first version of WG draft > - based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt > * submit for IESG review > > Change of LSP ownership between management and control planes > - single requirements and solutions draft defines one bit and a procedure > * first version of WG draft > - based on draft-caviglia-mp2cpcp2mp-02.txt > * submit for IESG review > > More forward-looking > ==================== > > Routing and signaling for complex optical constraints > * first version of WG draft > - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt > * submit for IESG review Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Aug 2005 15:38:51 +0000 Mime-Version: 1.0 (Apple Message framework v733) Content-Type: multipart/alternative; boundary=Apple-Mail-54--129477393 Message-Id: <6A0BF8B4-577A-4AFC-8132-B086AC914C64@cisco.com> Cc: , , "'Kireeti Kompella'" From: JP Vasseur Subject: Re: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 11:36:50 -0400 To: "Adrian Farrel" --Apple-Mail-54--129477393 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Adrian, Looks like a detailed, ambitious constructive action plan. Two comments: (1) Analysis of inter-domain issues for disjoint and protected paths - Informational I-D to close off the topic and devolve to PCE * first version of WG draft * submit for IESG review Could you briefly elaborate on this item ? (2) May be in the same bucket as draft-ali-ccamp-mpls-graceful- shutdown, you may want to add draft-leroux-ccamp-ctrl- saturation-01.txt ? thanks. JP. On Aug 16, 2005, at 7:28 AM, Adrian Farrel wrote: > Hi, > > Please find attached a file that contains: > > - a set of proposed *draft* milestones > - a discussion of why there are so many milestones > - a high-level explanation of the work items. > > Note that this looks like a lot of milestones, but please read the > text on this issue in the attached file. The bottom line is that > this is a product of micro management where I have tried to > identify all of the I-Ds that we might produce to cover the > referenced work, and where I have placed two (sometimes three) > milestones for each I-D. > > This micro-management may be over the top, and represents a full > pendulum swing from the previous style of CCAMP milestones, but in > the light of the hiatus of the last 12 months, i think this may be > beneficial and might achieve rapid forwards movement. > > I would welcome your (constructive!) comments. > > Notes: > - Why isn't my I-D also cited as input material? > No insult intended. The current list is simply there to > show the ADs that work is already in progress. All I-Ds > will be used as input. > - Why isn't my pet topic included? > Are you sure it is not there between the lines? This > list of milestones isn't completely proscriptive. > > The objective is to have the WG agreed on the milestones that it > wants to commit to by the end of August. > > Thanks, > Adrian > --Apple-Mail-54--129477393 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Adrian,

Looks like a detailed, = ambitious constructive action plan.

Two = comments:=A0

(1)=A0Analysis of = inter-domain issues for disjoint and protected paths
=A0 =A0 =A0= - Informational I-D to close off the topic and devolve to = PCE
=A0 =A0 =A0 * first version of WG draft
=A0 =A0 = =A0 * submit for IESG review

Could you briefly elaborate = on this item ?

(2)=A0May be in the same = bucket as draft-ali-ccamp-mpls-graceful-shutdown, you may want to = add=A0draft-leroux-ccamp-ctrl-saturation-01.txt ?

thanks.

JP.

O= n Aug 16, 2005, at 7:28 AM, Adrian Farrel wrote:

=
Hi,

Please find attached a = file that contains:

- a set of proposed *draft* milestones
- a = discussion of why there are so many milestones
- a high-level = explanation of the work items.

Note that this looks like a lot of = milestones, but please read the text on this issue in the attached file. = The bottom line is that this is a product of micro management where I = have tried to identify all of the I-Ds that we might produce to cover = the referenced work, and where I have placed two (sometimes three) = milestones for each I-D.

This micro-management may be over the = top, and represents a full pendulum swing from the previous style of = CCAMP milestones, but in the light of the hiatus of the last 12 months, = i think this may be beneficial and might achieve rapid forwards = movement.

I would welcome your (constructive!) = comments.

Notes:
- Why isn't my I-D also cited as input = material?
=A0 No insult intended. The current list is simply there = to
=A0 show the ADs that work is already in progress. All I-Ds
=A0 = will be used as input.=A0=A0=A0=A0=A0
- Why isn't my pet topic = included?
=A0=A0Are = you sure it is not there between the lines? This
=
=A0 list of milestones isn't = completely proscriptive.
=A0
The = objective is to have the WG agreed on the milestones that it wants to = commit to by the end of August.
=A0
Thanks,
Adrian
<ccamp-milestones.txt>

= --Apple-Mail-54--129477393-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Aug 2005 14:37:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A26F.8BA4FA1B" Subject: RE: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 10:34:00 -0400 Message-ID: Thread-Topic: Moving forward with the CCAMP charter Thread-Index: AcWiVstE/f8Ki9VCQe+ORuiO8XQAdgAGLSXQ From: "Zafar Ali \(zali\)" To: "Adrian Farrel" , Cc: , "Kireeti Kompella" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A26F.8BA4FA1B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian,=20 =20 Graceful shutdown, a method for explicitly notifying a set of nodes that either a Link or an entire node will remove itself from the network or the protocol is going to be disabled for a link or a node, had good response when kireeti polled for charter updates some times back. We have been waiting for a charter update to move with this ID (draft-ali-ccamp-mpls-graceful-shutdown-xx.txt). I think got missed in your list. can you please include this work item in the milestone list as well.=20 =20 Thanks =20 Regards... Zafar =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, August 16, 2005 7:28 AM To: ccamp@ops.ietf.org Cc: zinin@psg.com; 'Kireeti Kompella' Subject: Moving forward with the CCAMP charter =09 =09 Hi, =09 Please find attached a file that contains: =09 - a set of proposed *draft* milestones - a discussion of why there are so many milestones - a high-level explanation of the work items. =09 Note that this looks like a lot of milestones, but please read the text on this issue in the attached file. The bottom line is that this is a product of micro management where I have tried to identify all of the I-Ds that we might produce to cover the referenced work, and where I have placed two (sometimes three) milestones for each I-D. =09 This micro-management may be over the top, and represents a full pendulum swing from the previous style of CCAMP milestones, but in the light of the hiatus of the last 12 months, i think this may be beneficial and might achieve rapid forwards movement. =09 I would welcome your (constructive!) comments. =09 Notes: - Why isn't my I-D also cited as input material? No insult intended. The current list is simply there to show the ADs that work is already in progress. All I-Ds will be used as input. =20 - Why isn't my pet topic included? Are you sure it is not there between the lines? This=20 list of milestones isn't completely proscriptive. =20 The objective is to have the WG agreed on the milestones that it wants to commit to by the end of August. =20 Thanks, Adrian ------_=_NextPart_001_01C5A26F.8BA4FA1B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Adrian,
 
Graceful shutdown, a = method for=20 explicitly notifying a set of nodes that either a Link or an entire node = will=20 remove itself from the network or the protocol is going to be disabled = for a=20 link or a node, had good response when kireeti polled for charter updates = some times=20 back. We have been waiting for a charter update to move with this ID=20 (draft-ali-ccamp-mpls-graceful-shutdown-xx.txt). I think got missed=20 in your list. can you please include this work item in=20 the milestone list as well. 
 
Thanks
 
Regards... Zafar=20  

From: owner-ccamp@ops.ietf.org=20 [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian=20 Farrel
Sent: Tuesday, August 16, 2005 7:28 AM
To:=20 ccamp@ops.ietf.org
Cc: zinin@psg.com; 'Kireeti=20 Kompella'
Subject: Moving forward with the CCAMP=20 charter

Hi,

Please find attached a = file that=20 contains:

- a set of proposed *draft* milestones
- a = discussion of=20 why there are so many milestones
- a high-level explanation of the = work=20 items.

Note that this looks like a lot of milestones, but = please read=20 the text on this issue in the attached file. The bottom line is that = this is a=20 product of micro management where I have tried to identify all of the = I-Ds=20 that we might produce to cover the referenced work, and where I have = placed=20 two (sometimes three) milestones for each I-D.

This = micro-management=20 may be over the top, and represents a full pendulum swing from the = previous=20 style of CCAMP milestones, but in the light of the hiatus of the last = 12=20 months, i think this may be beneficial and might achieve rapid = forwards=20 movement.

I would welcome your (constructive!)=20 comments.

Notes:
- Why isn't my I-D also cited as input=20 material?
  No insult intended. The current list is simply = there=20 to
  show the ADs that work is already in progress. All = I-Ds
 =20 will be used as input.     
- Why isn't = my pet=20 topic included?
  Are you sure it is not = there=20 between the lines? This
  list of milestones isn't = completely=20 proscriptive.
 
The objective is to have the WG = agreed on the=20 milestones that it wants to commit to by the end of = August.
 
Thanks,
Adrian
------_=_NextPart_001_01C5A26F.8BA4FA1B-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 16 Aug 2005 11:35:10 +0000 Message-ID: <00db01c5a256$6624ebb0$4f849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "'Kireeti Kompella'" Subject: Moving forward with the CCAMP charter Date: Tue, 16 Aug 2005 12:28:11 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00CE_01C5A25D.F741F3C0" This is a multi-part message in MIME format. ------=_NextPart_000_00CE_01C5A25D.F741F3C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CF_01C5A25D.F741F3C0" ------=_NextPart_001_00CF_01C5A25D.F741F3C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please find attached a file that contains: - a set of proposed *draft* milestones - a discussion of why there are so many milestones - a high-level explanation of the work items. Note that this looks like a lot of milestones, but please read the text = on this issue in the attached file. The bottom line is that this is a = product of micro management where I have tried to identify all of the = I-Ds that we might produce to cover the referenced work, and where I = have placed two (sometimes three) milestones for each I-D. This micro-management may be over the top, and represents a full = pendulum swing from the previous style of CCAMP milestones, but in the = light of the hiatus of the last 12 months, i think this may be = beneficial and might achieve rapid forwards movement. I would welcome your (constructive!) comments. Notes: - Why isn't my I-D also cited as input material? No insult intended. The current list is simply there to show the ADs that work is already in progress. All I-Ds will be used as input. =20 - Why isn't my pet topic included? Are you sure it is not there between the lines? This=20 list of milestones isn't completely proscriptive. =20 The objective is to have the WG agreed on the milestones that it wants = to commit to by the end of August. Thanks, Adrian ------=_NextPart_001_00CF_01C5A25D.F741F3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

Please find attached a = file that=20 contains:

- a set of proposed *draft* milestones
- a = discussion of why=20 there are so many milestones
- a high-level explanation of the work=20 items.

Note that this looks like a lot of milestones, but please = read the=20 text on this issue in the attached file. The bottom line is that this is = a=20 product of micro management where I have tried to identify all of the = I-Ds that=20 we might produce to cover the referenced work, and where I have placed = two=20 (sometimes three) milestones for each I-D.

This micro-management = may be=20 over the top, and represents a full pendulum swing from the previous = style of=20 CCAMP milestones, but in the light of the hiatus of the last 12 months, = i think=20 this may be beneficial and might achieve rapid forwards = movement.

I would=20 welcome your (constructive!) comments.

Notes:
- Why isn't my = I-D also=20 cited as input material?
  No insult intended. The current list = is=20 simply there to
  show the ADs that work is already in progress. = All=20 I-Ds
  will be used as input.      =
- Why=20 isn't my pet topic included?
  Are you sure it is not = there between=20 the lines? This
  list of milestones isn't = completely=20 proscriptive.
 
The objective is to have the WG = agreed on the=20 milestones that it wants to commit to by the end of August.
 
Thanks,
Adrian
------=_NextPart_001_00CF_01C5A25D.F741F3C0-- ------=_NextPart_000_00CE_01C5A25D.F741F3C0 Content-Type: text/plain; name="ccamp-milestones.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ccamp-milestones.txt" CCAMP Working Group - Rechartering Effort Below you will find - a list of proposed milestones - an explanation of why this is a long list - overview of proposed drafts and work items In reviewing this we should look for: - topics that are irrelevant or unwanted by the WG - topics that have been left out but are wanted by the WG - topics that have been assigned the wrong priority or urgency - topics or collections or topics that are sufficiently large to potentially warrant their own working group. Proposed New milestones ----------------------- Oct 05 First version WG I-D for Advertising TE Node Capabilities in ISIS = and OSPF Oct 05 First version WG I-D for Automatic discovery of MPLS-TE mesh = membership Nov 05 Submit ASON Routing evaluation I-D for IESG review Nov 05 First version of WG I-D on path computation implmentation advice Nov 05 Cross-WG review of I-D for Advertising TE Node Capabilities in = ISIS and OSPF Nov 05 First version WG I-D MPLS to GMPLS migration strategies Nov 05 First version WG I-D GMPLS coordination of VCAT and LCAS Nov 05 First version WG I-D Change of LSP ownership between management = and control planes Dec 05 First version of WG I-D for ASON Routing solutions Dec 05 Submit RSVP-TE extensions for inter-domain signaling I-D for IESG = review Dec 05 Submit Per-domain path computation signaling I-D for IESG review Dec 05 First version WG I-D Requirements for Multi-Layer and = Multi-Region Networks Dec 05 First version WG I-D for Evaluation of existing protocols for = MLN/MRN Dec 05 First version WG I-D for Protocol solutions for MLN/MRN Jan 06 Submit GMPLS signaling in support of Call Management I-D for IESG = review Jan 06 Submit GMPLS/ASON lexicography I-D for IESG review Jan 06 First version of WG I-D for OSPF-TE/GMPLS MIB module Jan 06 First version WG Informational I-D for Analysis of inter-domain = issues for disjoint and protected paths Jan 06 Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF = for IESG review Jan 06 First version WG I-D MPLS-GMPLS interworking requirements and = solutions Jan 06 First version WG I-D GMPLS OAM Requirements Jan 06 First version WG I-D Routing and signaling for complex optical = constraints Feb 06 Submit LSP Stitching I-D for IESG review Mar 06 First version of WG informational I-D Aligning GMPLS protocols = across the standards bodies Mar 06 Submit GMPLS routing and signaling interoperability advice I-D = for IESG review Mar 06 First version of WG I-D for ISIS-TE/GMPLS MIB module Mar 06 First version of WG I-D for additional MIB module to cover = RSVP-TE signaling extensions Mar 06 Submit I-D for Automatic discovery of MPLS-TE mesh membership for = IESG review Jun 06 Submit Informational I-D for Analysis of inter-domain issues for = disjoint and protected paths for IESG review Jun 06 Submit GMPLS coordination of VCAT and LCAS I-D for IESG review Jun 06 Submit Change of LSP ownership between management and control = planes I-D for IESG review Aug 06 Submit path computation implmentation advice I-D for IESG review Oct 06 Submit ASON Routing solutions I-D for IESG review Oct 06 Submit Requirements for Multi-Layer and Multi-Region Networks I-D = for IESG review Oct 06 Submit Evaluation of existing protocols for MLN/MRN for IESG = review Oct 06 Submit MPLS-GMPLS interworking requirements and solutions I-D for = IESG review Oct 06 Submit MPLS to GMPLS migration strategies I-D for IESG review Dec 06 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review Dec 06 Submit GMPLS OAM Requirements I-D for IESG review Apr 07 Submit ISIS-TE/GMPLS MIB module for MIB doctor and IESG review Apr 07 Submit Protocol solutions for MLN/MRN I-D for IESG review Oct 07 Submit MIB module for RSVP-TE signaling extensions for MIB doctor = and IESG review Oct 07 Submit Routing and signaling for complex optical constraints I-D = for IESG review Oct 07 Recharter or close Working Group Why so many milestons? ---------------------- The number of milestones shown in this proposed list far exceeds anything I have ever seen in a working group charter. This is intentional and while it does indicate a heavy work-load it also indicates a higher level of micro-management than is usual within working groups. Thus two milestones are presented for each I-D (adoption as a WG I-D, and passing to the IESG post-WG-last-call). This can be compared with the "normal" charter milestones which include a single work-related item that may span several I-Ds and refers vaguely only to the "submission" of I-Ds. In other words, reviewers of this list should not panic because of its length, but should see this as beneficial. Explanation of I-Ds and work items ---------------------------------- The following text briefly introduces the work items that are represented by the milestones listed above. In this text an astrix (*) indicates a milestone to be set. The work is divided into several categories according to how core it is and how it should be prioritized. Existing drafts are referenced to indicate that work is already in progress - this is not intended to provide a complete list of existing drafts. Completing existing work = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ASON - ASON Routing evaluation - already have draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt * submit for IESG review - ASON Routing solutions * first version of WG draft * submit for IESG review - GMPLS signaling in support of Call Management - already have draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt * submit for IESG review - GMPLS/ASON lexicography - already have draft-ietf-ccamp-gmpls-ason-lexicography-03.txt * submit for IESG review - Aligning GMPLS protocols across the standards bodies - Information I-D not intended for publication as an RFC * first version of WG draft Interoperability reports and advice - signaling and routing - already have draft-ietf-ccamp-gmpls-addressing-01.txt * submit for IESG review - path computation * first version of WG draft - based on draft-otani-ccamp-gmpls-cspf-constraints-01.txt * submit for IESG review Additional MIB modules - OSPF-TE * first version of WG draft - based on draft-otani-ccamp-gmpls-ospf-mib-00.txt * submit for IESG review - ISIS-TE * first version of WG draft * submit for IESG review - Signaling - Need "living" MIB module under development to catch the minor protocol extensions that have been made * first version of WG draft * submit for IESG review Inter-domain - LSP Stitching - already have draft-ietf-ccamp-lsp-stitching-01.txt * submit for IESG review - RSVP-TE extensions for interdomain - already have draft-ietf-ccamp-inter-domain-rsvp-te-01.txt * submit for IESG review - Per-domain path computation signaling - already have draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt * submit for IESG review - Analysis of inter-domain issues for disjoint and protected paths - Informational I-D to close off the topic and devolve to PCE * first version of WG draft * submit for IESG review New items already started and within existing charter = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Advertising TE Node Capabilities - ISIS and OSPF in the same I-D * first version of WG draft - based on draft-vasseur-ccamp-te-node-cap-00.txt * review by IGP working groups * submit for IESG review Automatic discovery of MPLS-TE mesh membership - depends on TE Node capabilities I-D * first version of WG draft - based on draft-vasseur-ccamp-automesh-00.txt * submit for IESG review Multi-layer networks (also multi-region networks) - Requirements * first version of WG draft - based on draft-shiomoto-ccamp-gmpls-mrn-reqs-02.txt * submit for IESG review - Evaluation of existing protocols * first version of WG draft - based on draft-leroux-ccamp-gmpls-mrn-eval-01.txt * submit for IESG review - Solutions * first version of WG draft - based on draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt * submit for IESG review MPLS-GMPLS interworking requirements and solutions * first version of WG draft - material from draft-oki-ccamp-gmpls-ip-interworking-06.txt * submit for IESG review MPLS to GMPLS migration strategies * Informational I-D first version of WG draft - based on draft-oki-ccamp-gmpls-ip-interworking-06.txt - material from = draft-ali-ccamp-gmpls-deployment-augmented-model-00.txt * submit Informational I-D for IESG review Minor items just starting but close to heart of WG = =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= GMPLS OAM Requirements - Interesting and worthwhile * first version of WG draft - based on immature = draft-nadeau-ccamp-gmpls-oam-requirements-00.txt * submit for IESG review Minor items just starting and important becuase of inter-SDO = interactions = =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=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 GMPLS coordination of VCAT and LCAS - single requirements and solutions draft almost an applicablity = statement * first version of WG draft - based on draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt * submit for IESG review Change of LSP ownership between management and control planes - single requirements and solutions draft defines one bit and a = procedure * first version of WG draft - based on draft-caviglia-mp2cpcp2mp-02.txt * submit for IESG review More forward-looking =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Routing and signaling for complex optical constraints * first version of WG draft - based on draft-ashwood-ccamp-gmpls-constraint-reqts-00.txt * submit for IESG review ------=_NextPart_000_00CE_01C5A25D.F741F3C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 13 Aug 2005 14:38:54 +0000 Message-ID: <0dd501c5a014$d27d8a40$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: , "JP Vasseur" , , Subject: Re: PCE Requirement in CCAMP Date: Sat, 13 Aug 2005 15:34:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Dimitri, GMPLS and non-packet requirements for PCE are likely to include the specification of protection types, switching types, encoding types, optical constraints, and so forth. While you could argue that CCAMP has best knowledge of these items, it does not seem to me to matter if the corresponding requirements I-D (that describes what constraints PCE must be able to receive and satisfy) is developed in the PCE working group. The question that JP's email asks is: "Is it OK with the CCAMP WG if that requirements I-D is developed in the PCE WG with review from the CCAMP WG?" If we can answer this question in isolation of your other point, this would be helpful. We can then move on to discuss you other point as follows... While I understand your concern (that the computational architecture should not force signaling behavior) I do not believe that it can be addressed by limiting the discussion to the CCAMP working group. It is clear that the PCE working group is responsible for the PCE architecture and should suggest applicability to specific environments including multi-domain MPLS-TE and GMPLS. The questions then arise: if the application of PCE to a specific environment requires additions to the MPLS-TE or GMPLS signaling protocols: 1. which working group should decide that the applicability of PCE in this environment is valid? 2. which working group should identify the requirement for these protocol extensions? 3. which working group should validate the requirements for these protocol extensions? 4. which working group should develop the protocol extensions? 5. which working group should review the protocol extensions? *My* answers to these questions are: 1 PCE and CCAMP 2 PCE 3 CCAMP 4 PCE 5 CCAMP My reasoning is: - the purpose of PCE is to do this work - CCAMP cannot (and should not) do everything - CCAMP must keep "supervision" of protocol extensions I would like to hear other people's opinion on both issues - that raised by JP and that raised by Dimitri. Thanks, Adrian ----- Original Message ----- From: "dimitri papadimitriou" To: "Adrian Farrel" Cc: ; "JP Vasseur" ; ; Sent: Friday, August 12, 2005 7:59 PM Subject: Re: PCE Requirement in CCAMP > hi adrian > > i perfectly understand the need from the PCE perspective but that's not > the real question (even if one might question under which charter item > this work would be initiated - something not clear to me from your reply > here below) > > the real issue is that with such proposal PCE WG would be entering into > a mode where the computational capabilities are going to drive LSP > signaling itself - please note here the difference with the discovery > process through IGP extensions that is going to be put in place - but > the impact of the global PCE architecture on the independence wrt path > computation of the RSVP-TE protocol; hence, i always thought that the > CCAMP WG would have initially provided "guidelines" to the PCE WG before > such work would start in the PCE WG > > i hope you see that the issue is not about the "owning WG" or the > "reviewing WG" or their cooperation but the need to know more about the > acceptable level of integration/cooperation of the PCE architecture with > the operations on signaling LSP before deciding from where the wind will > come from > > hope this clarifies (at least a bit), > - dimitri. > > Adrian Farrel wrote: > > > Hi Dimitri, > > > > > >>it depends on the perspective, as such this document is meant to address > >>the following item of the charter (last part) > >> > >>"- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > >>MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > >>signaling (RSVP-TE) extensions required to support PCE-based path > >>computation models." > > > > > > No, it is not meant to address that part of the charter. That item remains > > unchanged by this discussion. > > > > JP's email is clearly specific to the documentation of requirements for > > PCE placed by the GMPLS protocols and non-packet networks under the > > control of GMPLS protocols. > > > > Our proposal is to develop all requirements for PCE within the PCE working > > group with review by the appropriate external working group. > > > > In practice, this only a small change since it is likely to be the same > > people involved in the work. It is, however, a formal change in CCAMP > > which previously had a commitment to work on these requirements. > > > > > >>therefore, it was my understanding that the PCE WG would be waiting for > >>the need wrt signaling for detailing its applicability; you (and adrian) > >>seems to say we will define the requirement for PCE-based inter-domain > >>path computation and resulting signaling behaviour/mechanisms would then > >>need to be adapted in CCAMP > >> > >>in brief, with your proposal PCE WG would be entering into a mode where > >>the computational capabilities are going to drive LSP signaling itself, > >>as an analogy RSVP-TE operations are decoupled from the routing > >>topology; so here, the same relationship should be kept with respect to > >>the computational scope/capabilities and behaviour of PCE(s) > > > > > > If you are objecting to the specific item on the PCE charter then now may > > be a little late, but let me explain the sort of thing that the charter > > item is intended to cover by giving a couple of examples. > > > > - PCE discovery may be achieved through the presence of > > information withing IGP advertisements. This would require changes > > to the IGPs and such changes MUST be reviewed by the > > appropriate WGs. > > > > - The use of a fully computed path that crosses multiple domains > > raises confidentiality issues. These issues can be solved by > > inserting new sub-objects into an RSVP-TE Explicit Route > > object (for example a cookie and PCE ID, or an encrypted > > hop). > > > > The normal way in which such small protocol changes are made (witness > > GMPLS additions to the IGPs) is either: > > a. An I-D is written and taken to the "owning" WG > > b. An I-D is written in the WG that needs the solutions and > > is reviewed in the "owning" WG. > > This process is usually refered to as "cooperation between WGs". > > The PCE charter proposes business as usual. > > > > Thanks, > > Adrian > > > > > > > >>>Dear WG, > >>> > >>>CCAMP proposed to work on GMPLS requirements for PCE as necessary. > >>> > >>>Considering the work which has been done by the PCE WG on > > > > requirements, it > > > >>>looks now more natural to move this work exclusively to the PCE WG. > >>> > >>>That said, since Inter-domain (G)MPLS TE falls under the scope of > > > > CCAMP, > > > >>>any requirements for PCE-based Inter-domain LSP computation should be > >>>discussed in the PCE WG *with* the review of the CCAMP WG. > >>> > >>>Similarly, non-packet networks may result in specific additional > >>>requirements for PCE. We propose that these requirements are also > > > > raised > > > >>>within the PCE working group and reviewed by CCAMP. > >>> > >>>Let us know if you have any opinion on or objection to these > > > > proposals. > > > >>>JP and Adrian (wearing PCE chair hat) > >>> > >>> > >>>. > >>> > >> > >> > >> > > > > > > > > . > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Aug 2005 19:00:31 +0000 Message-ID: <42FCF19B.2010007@psg.com> Date: Fri, 12 Aug 2005 20:59:39 +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.8) Gecko/20050511 MIME-Version: 1.0 To: Adrian Farrel CC: dimitri.papadimitriou@alcatel.be, JP Vasseur , ccamp@ops.ietf.org, pce@ietf.org Subject: Re: PCE Requirement in CCAMP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi adrian i perfectly understand the need from the PCE perspective but that's not the real question (even if one might question under which charter item this work would be initiated - something not clear to me from your reply here below) the real issue is that with such proposal PCE WG would be entering into a mode where the computational capabilities are going to drive LSP signaling itself - please note here the difference with the discovery process through IGP extensions that is going to be put in place - but the impact of the global PCE architecture on the independence wrt path computation of the RSVP-TE protocol; hence, i always thought that the CCAMP WG would have initially provided "guidelines" to the PCE WG before such work would start in the PCE WG i hope you see that the issue is not about the "owning WG" or the "reviewing WG" or their cooperation but the need to know more about the acceptable level of integration/cooperation of the PCE architecture with the operations on signaling LSP before deciding from where the wind will come from hope this clarifies (at least a bit), - dimitri. Adrian Farrel wrote: > Hi Dimitri, > > >>it depends on the perspective, as such this document is meant to address >>the following item of the charter (last part) >> >>"- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, >>MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP >>signaling (RSVP-TE) extensions required to support PCE-based path >>computation models." > > > No, it is not meant to address that part of the charter. That item remains > unchanged by this discussion. > > JP's email is clearly specific to the documentation of requirements for > PCE placed by the GMPLS protocols and non-packet networks under the > control of GMPLS protocols. > > Our proposal is to develop all requirements for PCE within the PCE working > group with review by the appropriate external working group. > > In practice, this only a small change since it is likely to be the same > people involved in the work. It is, however, a formal change in CCAMP > which previously had a commitment to work on these requirements. > > >>therefore, it was my understanding that the PCE WG would be waiting for >>the need wrt signaling for detailing its applicability; you (and adrian) >>seems to say we will define the requirement for PCE-based inter-domain >>path computation and resulting signaling behaviour/mechanisms would then >>need to be adapted in CCAMP >> >>in brief, with your proposal PCE WG would be entering into a mode where >>the computational capabilities are going to drive LSP signaling itself, >>as an analogy RSVP-TE operations are decoupled from the routing >>topology; so here, the same relationship should be kept with respect to >>the computational scope/capabilities and behaviour of PCE(s) > > > If you are objecting to the specific item on the PCE charter then now may > be a little late, but let me explain the sort of thing that the charter > item is intended to cover by giving a couple of examples. > > - PCE discovery may be achieved through the presence of > information withing IGP advertisements. This would require changes > to the IGPs and such changes MUST be reviewed by the > appropriate WGs. > > - The use of a fully computed path that crosses multiple domains > raises confidentiality issues. These issues can be solved by > inserting new sub-objects into an RSVP-TE Explicit Route > object (for example a cookie and PCE ID, or an encrypted > hop). > > The normal way in which such small protocol changes are made (witness > GMPLS additions to the IGPs) is either: > a. An I-D is written and taken to the "owning" WG > b. An I-D is written in the WG that needs the solutions and > is reviewed in the "owning" WG. > This process is usually refered to as "cooperation between WGs". > The PCE charter proposes business as usual. > > Thanks, > Adrian > > > >>>Dear WG, >>> >>>CCAMP proposed to work on GMPLS requirements for PCE as necessary. >>> >>>Considering the work which has been done by the PCE WG on > > requirements, it > >>>looks now more natural to move this work exclusively to the PCE WG. >>> >>>That said, since Inter-domain (G)MPLS TE falls under the scope of > > CCAMP, > >>>any requirements for PCE-based Inter-domain LSP computation should be >>>discussed in the PCE WG *with* the review of the CCAMP WG. >>> >>>Similarly, non-packet networks may result in specific additional >>>requirements for PCE. We propose that these requirements are also > > raised > >>>within the PCE working group and reviewed by CCAMP. >>> >>>Let us know if you have any opinion on or objection to these > > proposals. > >>>JP and Adrian (wearing PCE chair hat) >>> >>> >>>. >>> >> >> >> > > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Aug 2005 18:07:57 +0000 Message-ID: <0d4c01c59f68$ea4b5d70$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , , "JP Vasseur" Cc: , Subject: Re: PCE Requirement in CCAMP Date: Fri, 12 Aug 2005 19:08:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Dimitri, > it depends on the perspective, as such this document is meant to address > the following item of the charter (last part) > > "- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, > MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP > signaling (RSVP-TE) extensions required to support PCE-based path > computation models." No, it is not meant to address that part of the charter. That item remains unchanged by this discussion. JP's email is clearly specific to the documentation of requirements for PCE placed by the GMPLS protocols and non-packet networks under the control of GMPLS protocols. Our proposal is to develop all requirements for PCE within the PCE working group with review by the appropriate external working group. In practice, this only a small change since it is likely to be the same people involved in the work. It is, however, a formal change in CCAMP which previously had a commitment to work on these requirements. > therefore, it was my understanding that the PCE WG would be waiting for > the need wrt signaling for detailing its applicability; you (and adrian) > seems to say we will define the requirement for PCE-based inter-domain > path computation and resulting signaling behaviour/mechanisms would then > need to be adapted in CCAMP > > in brief, with your proposal PCE WG would be entering into a mode where > the computational capabilities are going to drive LSP signaling itself, > as an analogy RSVP-TE operations are decoupled from the routing > topology; so here, the same relationship should be kept with respect to > the computational scope/capabilities and behaviour of PCE(s) If you are objecting to the specific item on the PCE charter then now may be a little late, but let me explain the sort of thing that the charter item is intended to cover by giving a couple of examples. - PCE discovery may be achieved through the presence of information withing IGP advertisements. This would require changes to the IGPs and such changes MUST be reviewed by the appropriate WGs. - The use of a fully computed path that crosses multiple domains raises confidentiality issues. These issues can be solved by inserting new sub-objects into an RSVP-TE Explicit Route object (for example a cookie and PCE ID, or an encrypted hop). The normal way in which such small protocol changes are made (witness GMPLS additions to the IGPs) is either: a. An I-D is written and taken to the "owning" WG b. An I-D is written in the WG that needs the solutions and is reviewed in the "owning" WG. This process is usually refered to as "cooperation between WGs". The PCE charter proposes business as usual. Thanks, Adrian > > Dear WG, > > > > CCAMP proposed to work on GMPLS requirements for PCE as necessary. > > > > Considering the work which has been done by the PCE WG on requirements, it > > looks now more natural to move this work exclusively to the PCE WG. > > > > That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP, > > any requirements for PCE-based Inter-domain LSP computation should be > > discussed in the PCE WG *with* the review of the CCAMP WG. > > > > Similarly, non-packet networks may result in specific additional > > requirements for PCE. We propose that these requirements are also raised > > within the PCE working group and reviewed by CCAMP. > > > > Let us know if you have any opinion on or objection to these proposals. > > > > JP and Adrian (wearing PCE chair hat) > > > > > > . > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Aug 2005 16:16:04 +0000 Message-ID: <42FCCB29.8060309@psg.com> Date: Fri, 12 Aug 2005 18:15:37 +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.8) Gecko/20050511 MIME-Version: 1.0 To: JP Vasseur CC: ccamp@ops.ietf.org, pce@ietf.org Subject: Re: PCE Requirement in CCAMP Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit hi jp, adrian it depends on the perspective, as such this document is meant to address the following item of the charter (last part) "- In cooperation with protocol specific Working Group (OSPF, ISIS, IDR, MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP signaling (RSVP-TE) extensions required to support PCE-based path computation models." therefore, it was my understanding that the PCE WG would be waiting for the need wrt signaling for detailing its applicability; you (and adrian) seems to say we will define the requirement for PCE-based inter-domain path computation and resulting signaling behaviour/mechanisms would then need to be adapted in CCAMP in brief, with your proposal PCE WG would be entering into a mode where the computational capabilities are going to drive LSP signaling itself, as an analogy RSVP-TE operations are decoupled from the routing topology; so here, the same relationship should be kept with respect to the computational scope/capabilities and behaviour of PCE(s) thanks, - dimitri. JP Vasseur wrote: > Dear WG, > > CCAMP proposed to work on GMPLS requirements for PCE as necessary. > > Considering the work which has been done by the PCE WG on requirements, it > looks now more natural to move this work exclusively to the PCE WG. > > That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP, > any requirements for PCE-based Inter-domain LSP computation should be > discussed in the PCE WG *with* the review of the CCAMP WG. > > Similarly, non-packet networks may result in specific additional > requirements for PCE. We propose that these requirements are also raised > within the PCE working group and reviewed by CCAMP. > > Let us know if you have any opinion on or objection to these proposals. > > JP and Adrian (wearing PCE chair hat) > > > . > Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Aug 2005 15:42:40 +0000 Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: pce@ietf.org Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: PCE Requirement in CCAMP Date: Fri, 12 Aug 2005 11:41:06 -0400 To: ccamp@ops.ietf.org Dear WG, CCAMP proposed to work on GMPLS requirements for PCE as necessary. Considering the work which has been done by the PCE WG on requirements, it looks now more natural to move this work exclusively to the PCE WG. That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP, any requirements for PCE-based Inter-domain LSP computation should be discussed in the PCE WG *with* the review of the CCAMP WG. Similarly, non-packet networks may result in specific additional requirements for PCE. We propose that these requirements are also raised within the PCE working group and reviewed by CCAMP. Let us know if you have any opinion on or objection to these proposals. JP and Adrian (wearing PCE chair hat) Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Aug 2005 11:53:34 +0000 Message-ID: <0cc301c59f34$a11aefa0$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Lou Berger" , "Dimitri Papadimitriou" , "Reshad Rahman" , "Anca Zamfir" , "Junaid Israr" , "Arun Satyanarayana \(asatyana\)" Subject: Short additional working group last call on draft-ietf-ccamp-rsvp-restart-ext-03.txt Date: Fri, 12 Aug 2005 12:29:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, As mentioned by Arun in his email (below), draft-ietf-ccamp-rsvp-restart-ext-03.txt has been marked up after working group last call. At the same time, the authors made a minor functional change to the protocol extensions to handle a potential scaling issue. This email starts a short, additional working group last call on the I-D. Since the draft has already been through last call, I expect you to focus on the new material only. The last call will end on Sunday 21st August at 12 noon GMT. Thanks, Adrian ----- Original Message ----- From: "Arun Satyanarayana" To: ; "Adrian Farrel" ; "Kireeti Kompella" Cc: "Lou Berger" ; "Dimitri Papadimitriou" ; "Reshad Rahman" ; "Anca Zamfir" ; "Junaid Israr" ; "Arun Satyanarayana (asatyana)" Sent: Sunday, July 24, 2005 4:33 AM Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-03.txt > Hi all, > > Version -03 is the updated version resulting from last-call comments. > > A scalability concern was raised, where, the restarting node does not > support the mechanism in this I-D, but, one or more RSVP neighbors do. > This would result in unnecessary generation (and possible > retransmission) of RecoveryPath msgs by the neighbors, and, receive > processing of the RecoveryPath msg until the restarting node has to > decide to drop it. This may be a scalability issue when a large number > of LSPs are active on the restarting node. > > The solution is to indicate the capability to transmit and receive > RecoveryPath msgs with 2 new bits in the Capability object. > > Note: The above solution also addresses a similar concern raised > earlier, where, the restarting node support the extensions but one or > more of its neighbors do not. The restarting node would have to wait > until the end of the Recovery Period to revert to restart processing per > RFC3473. With an explicit advertisement of RecoveryPath capability, this > requirement no longer exists. Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 12 Aug 2005 10:49:14 +0000 Message-ID: <0c8201c59f2b$981350e0$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "'Kireeti Kompella'" , , "Bill Fenner" , , "Lam, Hing-Kam \(Kam\)" Subject: Liaison to SG15 on RFC 4139 Date: Fri, 12 Aug 2005 11:46:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit To: ITU-T Study Group 15 From: IETF CCAMP Working Group Subject: New Request for Comment Published For: Information The CCAMP Working Group of the IETF wishes to inform Study Group 15 of the ITU-T of the publication of a new Request for Comment. RFC 4139 "Requirements for Generalized MPLS (GMPLS) Signaling Usage and Extensions for Automatically Switched Optical Network (ASON)" is available at http://www.ietf.org/rfc/rfc4139.txt The Abstract of this RFC reads as follows. The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies and different applications. These include support for requesting Time Division Multiplexing (TDM) connections, including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the signaling aspects of the GMPLS suite of protocols. It identifies the features to be covered by the GMPLS signaling protocol to support the capabilities of an Automatically Switched Optical Network (ASON). This document provides a problem statement and additional requirements for the GMPLS signaling protocol to support the ASON functionality. The CCAMP Working Group would like to thank the members and Questions of Study Group 15 for the helpful input and review feedback that they provided while this document was being developed. The CCAMP Working Group continues to actively pursue protocol solutions for the ASON model and seeks to harmonise GMPLS and ASON. We will keep you informed of our future progress. Regards, Adrian Farrel and Kireeti Kompella CCAMP Working Group Co-chairs Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Aug 2005 15:34:41 +0000 Message-ID: <093301c59e8a$59137510$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Updated minutes - more comments please Date: Thu, 11 Aug 2005 16:21:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks to Richard and Dimitri for filling some gaps. ====== IETF-63 Paris August 2005 CCAMP Working Group Minutes thanks to Deborah Brungard and Don Fedyk ------------------ 1) Admin Adrian reviewed slides of agenda ------------------ ------------------ 2) WG Status Adrian reviewed draft status and milestones ------------------ ------------------ 3) ITU and OIF liaison report - Lyndon Ong Reviewed slides - Q14 Plan to share g7713 before goes for consent - No signaling activities, routing they are waiting for our DT response, next meeting in Chicago - OIF activities - OIF communication to IETF with identified issues from demo ------------------ Adrian: Understand that there is no urgency for responding Will respond as quickly as possible, will post on mailing list. Lyndon: These are results of the demo so there is no dependence but they are important. Dimitri: Were these issues identified before or after demo? Lyndon: Some before, some after. Dimitri: Why not asked over the list for those before? Lyndon: Some of the issues were, like the encoding. The first issue was on an informal response. So we want a formal response. The other issues we made some implementation decisions so we want to verify the decisions. ------------------ ------------------ 4) Interdomain RSVP - Arthi Ayyangar Reviewed slides - Hope to get comments before do next revision (soon) then hope to go for last call ------------------ Dimitri: Do you plan to keep the examples in the document or as appendix? Arthi: Do you think it affects readability? Dimitri: Prefer as appendix Arthi: OK Adrian: Is this an example or is it normative? Arthi: The example only describes the overall working. ------------------ ------------------ 5) LSP stitching: Arthi Ayyangar Reviewed slides - Summarized discussion on list - First point - Are procedures required for both PSC and non-PSC LSPs? - Discussion on list indicated yes Adrian: Also from a control plane point of view it is better to have a consistent behavior - 2nd point - Should allow stitching while traversing region boundaries? Dimitri: I see no reason for this, why are we still discussing? Adrian: I said yes on the list because of the last bullet on the slide. Why disallow it? Kireeti: I think yes also, why disallow it? Dimitri: Why allow it? Adrian: If we take it out of scope now, we may have to change later, so why remove it now? Yet we don't want to do it speculatively. Igor: Question for kireeti: Can we stitch PSC1 with PSC2 LSP? And we said while we could do this with a label stack, but we shouldn't allow it as these LSPs were provisioned for a reason as two different types (PSC1 and PSC2). In the non-packet world this more clear. Use hierarchy and adaptation. Kireeti: Not so clear for me. PSC1 & PSC2 We understand but Non-PSC we don't understand. For non PSC, we don't know where it will go, e.g. wavelength switching. So why prevent it? Igor: It is not complex but it is pointless. Kireeti: You can always say no when you receive a request to stitch. Arthi and Igor: No, you can't say no Lou: What is the difference between stitching and hierarchical LSP. The LSP on top (inner label) uses all the bandwidth of the one below (outer label). Adrian: The difference is if you add a label for the passenger LSP. Arthi: It's not just label allocation it's resource allocation. I'll address this later. - Bidirectional LSPs and control of labels - Current proposal resolves this by not sending a Label. - 4 options: In Slides: Lou: Minor suggestion; use a different C-type. Call it Option 2 Prime. Arthi: You can, but it is still an issue. Adrian: You have to do special processing when you do stitching anyway. Arthi: You still have to implement the C-type. Kireeti: You don't have to allocate a special label. Adrian: Agree Point 4: Need to provide end-to-end bidirectional service. For example for mpls/gmpls migration. Need to stitch two unidirectional LSPs in the middle. Arthi: Or could do 2nd part of (4). This is not really any changes Just need stronger description on what we are doing Personally like a sending label that is ignored. Adrian: Who likes this 2nd part? - Send any label and have receiver ignore it # Some show of hands Adrian: Anyone prefer one of the other solutions? # (No one?) Adrian: Seems a preference for this 2nd option, will take to list Lou: Clear to make the change. Change the text to Must. Dimitri: Can you make clear on the stitching for bidirectionality Arthi: Should it be required for non PSC? Lou: Anyone that supports stitching MUST support the procedures if they support stitching. Arthi: But if you are not following this document. You could be doing data plane stitching and not control plane stitching. Lou: If it is outside the standard then it is out of scope. If you follow the document you MUST follow the procedures. ------------------ ------------------ 6) Per-Domain-Paths - JP Vasseur Would like to get feedback on last issue on slides. ------------------ Adrian: I think the use of IP reachability information is important. The WG must make a conscious decision. JP: This I-D is only describing reachability outside of domain Adrian: We should say so more clearly Dimitri: I sent feedback. We should cover this question. Not sure if part of this document. This is a problem in several documents. If we have IP reachability, but don't know switching capability, then it's not sure if we can make the connection. This an issue when have a mixture of switching capabilities. Igor: When we compute path, we consider TE resources, not IP reachability. Should not rely on knowing reachability. Once you have a mix of terminating points this is a real issue. Adrian: We need to have a global solution. Igor: You want to compute path consider the resources TE resource reachability of destination. Not to rely on the IP but have static information that you can reach the path. JP: Just want to rely on IP reachability to reach next domain, and then let next domain decide if it can satisfy the request. Igor: OK - maybe could do aggregation rules You can have a static TE entry. JP: But we don't have information on resources Janis ??: Agree that if we are separating data and control plane, this will not work Adrian: Specifying what information to use for path computation is not covered anywhere. It is part of the algorithm, but not part of the protocol. CSPF can use any information including IP reachability or the weather. Arthi: So how do we find next hop? How do you get to the next domain? Adrian: If we don't do this process inside the domain, why do we have to have a way to get out of the domain? JP: So we should remove next hop? Arthi: Does not make sense. How to do crankback? Kireeti: OK - we need to consider further ------------------ ------------------ 7) Addresses in GMPLS networks - Richard Rabbat Reviewed slides ------------------ Arthi: why you are proposing as a std track? Adrian: This decision was a result of a loose poll based on whether this advises, recommends or mandates. Arthi: Can we do again the poll Adrian: We can, who prefers: # BCP - some show of hands # Stds track - less show of hands Arthi: My concern is that it is good to have this document, but it is using items from other docs and making some changes Have to change the Musts and Shoulds. Adrian: If text is repeating the same must/should from another document then it should be deleted. If this is new must/should language then it should be std track Need to clarify definitions. If you are Restating with same values, its BCP. If you change values it is Standards updating an existing RFC or a new Standards track document. Arthi: Then this should be std track as it is already doing it Lou: It is bringing together many items - would suggest informational Could be informational. I did not vote because I was waiting for informational. Adrian: Who wants informational? # almost same show of hands as BCP Lou: If it's implementation then BCP, but if bringing together info, then informational The document is putting recommendations on implementing. Is it just for building and deploying? Or is it Defining a new field or procedure? Adrian: OK we should discuss more Dimitri: I thought the same - it is bringing together experience on using addresses, not saying how to do, and not covering future issues. So I have issue with 9.3 which is not based on experience Adrian: The WG needs to decide how want to do Kireeti: We will discuss with ADs and take to list Arthi: For example, for the FA it says a MUST for how to use, but it doesn't say what to do for static case, so doesn't cover all cases Richard: This is an oversight. we'll correct it in the next revision to say that we're talking about the dynamic case. Yakov: Slide #3. Why the decision on FA LSP, this is a change to the protocol. Richard: You don't know it is a FA LSP. How do you know that it is to be advertised back? John Drake: It is covered in RFC3477. Lou: That is unnumbered interfaces. Adrian: Numbered FA LSPs need a way to indicate to the egress that they will be used as FAs. Compare with unnumbered LSPs that have a special object. Arthi: What is the point of changing it to 0? Kireeti: Let's discuss on the list ------------------ ------------------ 8) GMPLS/ASON Lexicography - Igor Bryskin Reviewed slides ------------------ Igor: If anyone is interested in furthering ason-gmpls convergence, talk to Adrian or myself to help Richard: What is your objective? Igor: Have consensus in the group and expand the dictionary. Richard: Saw in one the drafts on ASON there is an appendix. With ASON terms. Should we integrate the ason-gmpls documents' reference terms into this document? Dimitri: No, that work was for CCAMP people to understand ASON. This is a different purpose Igor: Agree. This is for ITU people to understand GMPLS ------------------ ------------------ 9) ASON routing evaluation - Dimitri Papadimitriou Reviewed slides ------------------ Adrian: Who from DT is in the room? # Dimitri and Lyndon Adrian: Thanks for work. Does the DT think this is ready for last call? Lyndon: Yes. Just some minor editing Adrian: Anyone object to last call # None Alex: Doesn't WG need to read this first Adrian: Yes, need to read it for last call OK take to list for last call ------------------ ------------------ 10) ASON signaling - Dimitri Papadimitriou Reviewed slides ------------------ Dimitri: The community that wants to use this document needs it to be recognized as an RFC, it is important to finish Alex: Any technical issues on this or the last document that need to discuss now? Dimitri: Only this item on simultaneous call/connection signaling Alex: Please summarize the technical issues. Please focus the time in the meeting to raise and discuss open issues Lyndon: Will you liaison to SG15 before last call? Kireeti: Yes Steve Trowbridge: Should also include specific changes against g7713.2 Adrian: What is the intention? Steve: Should be for alignment, should not have two normative versions of ASON signaling Adrian: ITU already has versions .1, .2, .3 Steve: State how it differs from .2 version Adrian: OK. This is GMPLS. 7713.2 is not GMPLS. We can do a comparative analysis. Principal difference is call/connection piggybacking Lyndon: Is this UNI/ENNI/INNI? Dimitri: The document states clearly this if you read it Answer is all three Alex: Are the technical issues complete? It would be much better if we have the technical summary. Not just say this work is ready or work is stable. Adrian: We owe the WG status. Kireeti: Dimitri, can you start the liaison? Dimitri: OK ------------------ ------------------ 11) CCAMP Work Plan Kireeti reviewed the slide on options what to do - We have pretty much cleared the documents in our queue, and we are reviewing the charter to update ------------------ Alex: - I have 12 documents submitted to me, 10 docs in id list. - Documents are done when finished also IESG review, I don't expect to wait for this though before going on to new items. Alex reviewed slide on potential new work - Inter domain OK - Layer 2 switching: where is this? Kireeti: We will have a discussion on where to put it Alex continues: - L1VPN New WG - doesn't seem any objection, should prioritize and timeline - Are these Milestones or Work items? Kireeti: - Could do milestones, but defining work items is easier - For example, MPLS/GMPLS interworking is implicit in the charter but not specifically covered. Alex: Can identify high priority items now Adrian: - We already asked the working group and this is on the first slide. - There are six items shown on the slide Alex: Six items that need some work. Is that too much? Adrian: - Not all things are the same size. - Interoperability issues are already on the plate. - Layer 2 switching Moderate size thing. - MPLS/GMPLS migration moderate size. - Second slide shows recent new topics. Maybe take on new items. - Signaling Issues: - Routing issues - GMPLS OAM requirements. Alex: These items are also important Kireeti: Should look at pipelining work as we already started first slide. It all depends on how long it takes to do charter. We have been waiting now for more than a year Alex: Can prioritize and identify if can spin off work to a new, separate working group. Just like Layer 1 VPN that uses GMPLS. Take out other lumps and put in other WGs? Chairs should identify items. Adrian: We can discuss which could spin off, though we need to decide, and not delay, as many items are already being worked on. Bijan Jabbari: When I look at what is being implemented by vendors there is a mismatch with what this group is doing. Perhaps should look at short term. Alex: Yes my thoughts should look at 1 year to 2 years. Bijan: Not really clear what is being implemented Bijan: I work with Academia and industry, and the answer is not clear. You see implementations but you don't see deployments. Business reasons etc. New way of thinking that takes time. Alex: When go for standard track, do need implementation Kireeti: Also need deployments, and that takes time JP: Regarding the item on "input to PCE requirements". Not sure if need this input Adrian: Explain history is that CCAMP made a commitment to assist PCE Could agree to remove this commitment Alex: Yes we should discuss more in both groups. Don't want to make commitment to remove this before discussing it. If we have consensus maybe we don't need the document. JP: On advertisement of TE/GMPLS capabilities, we have implemented and deployed in 5 large service providers, so would like to expedite this Lou: Slide Back to Slide3: For the item on charter - missing is ASON. What do we do about alignment, and that we have two versions of RSVP? There is only one version of GMPLS, what do we need to do? What steps that we need to take as a WG? Alex: ASON is on our charter Lou: It's on charter - we have completed our documents. We can send to SG15, but what do we do from there to align GMPLS and ASON solutions? Adrian: Added it to slides Richard: On recent new topics - do we know what is in-charter currently? Alex: It is up to chairs: Adrian: If it is in the scope of the charter, we will do milestones There will be discussion on the list. Dimitri: Why is "deployment considerations" considered marginal? If you want feedback, how can this be classified as marginal? Please prioritize and please discuss. Adrian: This is from the community view gathered on the list last year Dimitri: Then how will we have deployment Kireeti: You can do canvassing to get people to discuss. We will take back to the list to do a poll again ------------------ ------------------ 12) GMPLS for Ethernet - Dimitri Papadimitriou Reviewed slides Define a set of scenarios: 4 Scenarios -Aggregation -Metro -Unified? Core -Transport Dimitri asked if interest to do this work ------------------ Don Fedyk: We still don't know what is actually meant by GMPLS Ethernet. The document does not go far enough today with enough detail. The document is too open ended and we don't know what exactly is being specified. I asked for more detailed specification. Dimitri: Ali Sajassi: Ethernet differs from other data planes as it's not point to point. Do you want to keep it as in the perspective of IEEE? Other comments: you want to replace existing Ethernet control plane with GMPLS: again how will you do multipoint? Shortest path may overlap with issues discussed in TRILL. How are you going to coordinate with other WGs? Loa: Not speaking for the DT as we didn't discuss it: I have experience running a medium/large scale Ethernet network as a point-to-point network (unified/core). It would be very applicable to add a gmpls control plane. Note that if we can't do it as a standard we (deployers) will do it ourselves. It is pretty straight forward. Ali: I can see for point to point, it's for multipoint that I see it will have issues Dimitri: OK. Can you input specifics? This said these questions are relevant but the scope (of the document) has been restricted to point-to-point. The issues on how we coordinate and potentially overlap with other working groups must also be addressed (implicitly: if we decide to move forward with this item.) Richard Spencer: Can you confirm that using GMPLS in enterprise is out of scope? Dimitri: As no one has expressed interest I would say it is out of scope Richard S: Will there be any changes to Ethernet control/data plane? What would be the potential difficulties? Have a discussion with the IEEE and see where they would be impacted. Dimitri: I can not say what will be the solution chosen, we already suggested we work with IEEE to assess impact Richard S: I see little value for aggregation. I don't see in metro why a provider would want to use this instead of VPLS Dimitri: I have replied to some of the issues you are currently raising on the list. If further clarification required we should discuss them on the list. Kireeti: We will not change the Ethernet data plane here. If we conclude it may need to be changed, we will liaise to IEEE and get their agreement. CCAMP is focused on core tunneling technologies, though we don't say how you will use them - metro or core - I would like us to continue not to be specific for access or core. If there is anything specifically different for access, then need to add to charter. Lyndon: There is a lot of interest in other groups (ITU, OIF, MEF). I think there is interest. Where people are uncertain is how. Need to look at more on supporting pt to pt or multipt. Don O'Conner: How does this differ from l2vpn? Dimitri: As explained in the introduction of the problem statement document it differs from the forwarding which is not based on packet header (as in MPLS) but based on the Layer-2 frame header. Kireeti: L2VPON charter is different. L2VPN sets up vpns. This work is on signaling and routing in Ethernet networks. Tom Nadeau: Is this in the scope of CCAMP today? Adrian: Yes this is in the scope as a core network. GMPLS handles packet transport networks. Maybe this is could be a new working group. Note, however, that changes to the data plane are not in scope for CCAMP and would require action by other SDOs, in this case IEEE. Tom: Seems similar to TRILL. Adrian: Yes. Need to determine if there is overlap. Perhaps this work should go there. Alternatively, perhaps this work goes in a new WG. Dimitri: Some of these items such as the difference with TRILL have been discussed on the mailing list. Loa: Trill is in campus networks. Alex: For structuring this work, we need to be very clear what data path modifications need to be done. Should communicate with IEEE liaison, preferably before BOF. TRILL working group is a specific example. Dimitri: What would be the way to contact the IEEE to do this? Is there a liaison with IEEE that we can make use of? Alex: We have an established liaison relationship with IEEE. Dimitri: OK, we will enter in contact with the liaison representative. Kireeti: First need to decide if we need a change in the data plane. Then talk to the IEEE. Adrian: Also need to tell IEEE what we plan to do, no matter how we do it. Smith: There are limits to the use of VLAN-ID. There are only 4K of them. Will you use this as the label? Adrian: We haven't decided anything about how forwarding will occur yet Dinesh Mohan: I haven't heard yet that there is planned a change to the data plane. Need to understand better. Should look at this as a new control plane using existing data plane. It would be nice to have the GMPLS Control plane but is there no intent to change the control plane? The basic assumption is that you have a different control plane then that should be the assumption. This is fine to explore, but the starting point is not to modify the data plane. Adrian: When we control SDH we did not mess with the data plane. We should not be modifying the transport technology. Monique Morrow: Echo what Alex said, any modification we need to talk to the IEEE. Dimitri: OK, but we are not talking in the context that there is a change to data plane. Ali: Trill and this are using ISIS. Trill plan to change the data plane. Kireeti: Please stop, take to list. Ali: Several vendors offer Ethernet switches that offer point to point using MPLS control plane supporting millions of connections. Yakov: How? Could you tell me whether they carry a label? Ali: Yes. They are MPLS switches Yakov: So it is a router, an LSR , that you can call an Ethernet switch and you are done? Adrian: That is indeed a suggestion. Don O'C: Ethernet is connectionless and now GMPLS is connection- oriented, so this is different. This is redefining Ethernet to make it connection oriented. Is that the intent? Is this making VLAN tags look like GMPLS labels? Adrian: Again, this has not been discussed Loa: From experience, we don't want to remove VLAN tags. Need something else. And the chairs said to the design team not to do that, yet 80% of CCAMP are already assuming this is what we want to do. Adrian: Design team job is done - Thanks. We need now for the WG to discuss. ------------------ Time is over. Other drafts that we didn't get to discuss, take to list. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Aug 2005 15:34:33 +0000 Message-ID: <093501c59e8a$626f8b80$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: ASON Routing evaluation ready for WG last call? Date: Thu, 11 Aug 2005 16:31:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt The DT said in Paris that this I-D is cooked apart from "some minor editing". I asked the room if anyone would object to a WG last call now, and Alex (as AD) suggested that more people should read the I-D before we decided whether it was ready for last call. This gives me the odd position of having a last call for a last call :-) This email gives notice that you need to read this I-D and make comments before 11th September 2005. Barring unresolved comments we will have a WG last call starting then. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Aug 2005 12:41:54 +0000 Message-ID: <08c901c59e72$56e425e0$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Responding to the OIF Date: Thu, 11 Aug 2005 13:42:56 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_08C6_01C59E7A.94425120" This is a multi-part message in MIME format. ------=_NextPart_000_08C6_01C59E7A.94425120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As Lyndon noted in Paris, the OIF has sent us a communication requesting = some guidance on a bunch of questions. This is to start the business of constructing a reply. thanks to Dimitri = for supplying some of this text. Please send comments and improvements. Adrian =3D=3D=3D=3D=3D=3D To: Jim Jones, OIF Technical Committee Chair From: Adrian Farrel and Kireeti Kompella,=20 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 >=20 > 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. >=20 > 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.=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. >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 =3D 0 NCC =3D 0 NVC =3D 0 MT =3D 1 T =3D 0 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 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=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. 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 =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. We believe that this final sentence should read "greater than or equal = to 1," and that this interpretation resolves all of your issues and = makes the text consistent with the examples. > 2. Setting of NVC for VCAT connections >=20 > 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 >=20 > 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. >=20 > 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=20 LSP b/w 2 4 bytes=20 LSP b/w 3 4 bytes=20 LSP b/w 4 4 bytes=20 LSP b/w 5 4 bytes=20 LSP b/w 6 4 bytes=20 LSP b/w 7 4 bytes min b/w 4 bytes indication 1 byte =3D=3D 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 >=20 > 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: >=20 > "The absence of the object is equivalent to receiving an object = containing > values all set to zero (0)." >=20 > 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 >=20 > 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. >=20 > 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, an 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. > 6. Symmetry of Refresh Reduction usage >=20 > 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. >=20 > 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. >=20 > 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.=20 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=20 to an LSR that is not setting the refresh-reduction-capable=20 bit. - An LSR may send refresh reduction options or messages =20 to an LSR that is setting the refresh-reduction-capable bit. - An LSR that wishes to successfully use responded refresh=20 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 >=20 > 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. >=20 > 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=20 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... ::=3D [ ] 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 is currently discussing the use of GMPLS for = control of Ethernet devices. We will respond to this point in a separate = email. Best regards, Adrian Farrel Kireeti Kompella ------=_NextPart_000_08C6_01C59E7A.94425120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

As Lyndon noted in Paris, = the OIF has=20 sent us a communication requesting some guidance on a bunch of=20 questions.

This is to start the business of constructing a reply. = thanks=20 to Dimitri for supplying some of this text.

Please send comments = and=20 improvements.

Adrian

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

To: Jim = Jones, OIF Technical=20 Committee Chair
From: Adrian Farrel and Kireeti Kompella,=20
          WG Co-Chairs = for IETF=20 CCAMP
Copy: Alex Zinin and Bill Fenner, IETF Routing Area=20 Directors
Subject: Response to your questions about GMPLS=20 parameters.

Dear Jim,

Thanks for your correspondence about = the=20 questions with respect to GMPLS parameters that arose before and during = your=20 interoperability testing. CCAMP is pleased to receive such questions and = is glad=20 to have the opportunity to explain the intended operation of the GMPLS=20 protocols.
 
Much of the material supplied below = can be simply=20 extracted from the relevant RFCs.


> 1. Use of the NCC and RCC fields for STS-3c/VC-4=20 connections
>
> During OIF testing it was noted that some = ambiguity=20 exists in the
> specification of encoding of NCC, RCC and NVC for = certain=20 types of
> connections: NCC and RCC for an STS-3c/VC-4 connection = can be=20 set to 0 or
> to 1 depending on which example of RFC 3946 is=20 followed.
>
> Clarification is requested from IETF CCAMP as = to=20 which setting is
> considered correct, or if both settings should = be=20 accepted (this procedure
> was used during testing at=20 Supercomm).

This question about RFC 3946 was raised informally on = the=20 CCAMP mailing list at the start of March this year.

Even when = the signal=20 Type value is the same (i.e. value 6) the NCC, RCC and NVC values depend = on the=20 specific signal being requested.

From the examples in the annex = we=20 have...

   A VC-4 signal is formed by applying the=20 following
   settings to a VC-4 Elementary=20 Signal.
      RCC =3D=20 0
      NCC =3D = 0
     =20 NVC =3D 0
      MT  =3D=20 1
      T   =3D = 0

   An=20 STS-3c SPE signal is formed by applying the following
   = settings=20 to an STS-3c SPE Elementary Signal.
      = RCC =3D 1=20 (standard contiguous concatenation)
      = NCC =3D=20 1
      NVC =3D = 0
     =20 MT  =3D 1
      T   =3D = 0

Your=20 question probably arises from the two notes and subsequent paragraph in = section=20 2.1 or RFC 3946. Here it says...

   Note 1: when = requesting a=20 SONET STS-Nc SPE with N=3D3*X, the
      = Elementary=20 Signal to use must always be an STS-3c_SPE signal=20 type
      and the value of NCC must always = be equal=20 to X.  This allows also
      = facilitating the=20 interworking between SONET and SDH.  = In
     =20 particular, it means that the contiguous concatenation of=20 three
      STS-1 SPEs can not be requested = because=20 according to this
      specification, this = type of=20 signal must be coded using the STS-3c
      = SPE=20 signal type.

   Note 2: when requesting a transparent=20 STS-N/STM-N signal
      limited to a single = contiguously concatenated = STS-Nc_SPE/VC-4-Nc,
     =20 the signal type must be STS-N/STM-N, RCC with flag 1 and NCC=20 set
      to 1.

   The NCC = value=20 must be consistent with the type of contiguous
   = concatenation=20 being requested in the RCC field.  In particular, = this
  =20 field is irrelevant if no contiguous concatenation is requested=20 (RCC
   =3D 0), in that case it must be set to zero when = sent, and=20 should be
   ignored when received.  A RCC value = different=20 from 0 must imply a
   number of contiguous components = greater than=20 1.

We believe that this final sentence should read "greater than = or equal=20 to 1," and that this interpretation resolves all of your issues and = makes the=20 text consistent with the examples.

> 2. Setting of NVC for = VCAT=20 connections
>
> It was also noted that the setting of NVC = may be=20 somewhat ambiguous for
> the case where diverse connections are = used=20 within a single VCAT group.
> Each individual RSVP session = controls a=20 single connection, but the
> connection is part of a larger VCAT = group and=20 carries VCAT encoding of the
> H4 byte. Clarification is requested = from=20 IETF CCAMP and ITU-T Q.14/15 as
> to the correct setting of NVC = for this=20 case (0 or 1?). It should be noted
> that this case may occur with = a VCAT=20 group with only a single initial
> member, and that the NVC may = provide an=20 indication that VCAT encoding of
> the H4 byte is in use for the=20 connection.

A VCn-Xv group split into X components requires each = of its=20 component to be signaled with the NVC value set to 1. This setting is = regardless=20 of how the components are established.

> 3. Length of the = Interface=20 Switching Capability TLV
>
> Although the Interface = Switching=20 Capability TLV defined by CCAMP for
> SONET/SDH connections was = not used=20 for the testing, it was noted that the
> text describing the = length of the=20 Interface Switching Capability TLV
> defined in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt may be slightly
> = ambiguous=20 due to the use of padding bytes.
>
> RFC 3630 states that = "The TLV=20 is padded to four-octet alignment; padding
> is not included in = the length=20 field (so a three octet value would have a
> length of three, but = the=20 total size of the TLV would be eight octets)."
 
Yes. Section 2.3.2 of RFC3630 gives a = definitive=20 statement of the meaning of the length field and the use of padding, and = provides an example.
 
> Reading of the encoding in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt
> specifies that the = length=20 of the TLV for TDM is 41 bytes plus 3 bytes of
> padding, and = should be=20 given in the length field as 41 bytes rather than
> 44. OIF = requests=20 verification of this interpretation from the experts in
> IETF = CCAMP=20 group.
 
Note that the Interface Switching Capability Descriptor defined in=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is a sub-TLV of the Link = TLV.=20 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=20
  LSP b/w 2  4 bytes=20
  LSP b/w 3  4 bytes=20
  LSP b/w 4  4 bytes=20
  LSP b/w 5  4 bytes=20
  LSP b/w 6  4 bytes=20
  LSP b/w 7  4=20 bytes
  min b/w    4 bytes
  indication 1=20 byte
           = ; =3D=3D
           &n= bsp;41=20 bytes
 
We presume that your question relates to whether the 3-byte field = shown as=20 "padding" in the TDM-specific figure on page 6 of=20 draft-ietf-ccamp-ospf-gmpls-extensions-12.txt is an implicit or an = explicit=20 field.
 
It is an implicit field, and should not be included in the length = of the=20 TLV.
 
Nevertheless, we take this = opportunity to remind=20 the OIF that implementations of GMPLS protocols should be conservative = in what=20 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=20 reason. It should parse the TLV according to the defined fields and skip = the=20 final three bytes. Thus, it should not affect a receiving implementation = if the=20 sending implementation has treated the "padding" field as implicit or = explicit.=20 In the event that a receiving implementation rejected such a TLV on = grounds of=20 the value contained in the length field being too large, the fault would = lie=20 with the receiving implementation not the sending = implementation.
 
> 4. Use of ADMIN_STATUS in an = initial PATH=20 message
>
> Some implementations sent an ADMIN_STATUS = object with=20 no flags set in the
> initial PATH message, i.e., when no status = change=20 was being requested.
> Although this did not serve any particular=20 function, it was believed that
> this could be accepted as = RFC3473, sect.=20 7.2 (page 18) states:
>
> "The absence of the object is = equivalent=20 to receiving an object containing
> values all set to zero = (0)."
>=20
> It was our interpretation based on this text that a node should = accept=20 an
> ADMIN_STATUS object with no flags set in the same way as if = the=20 object was
> missing. Comment on this interpretation is=20 welcome.
 
The effect of the meaning is as you = state, but=20 the intention of the meaning is reversed. That is, an implementation = should=20 accept the absence of the ADMIN_STATUS object in the same way as if the = object=20 was present with no flags set. That is, the default behavior is to = consider the=20 ADMIN_STATUS object as a standard part of the processing.
 
We note from your first paragraph = that you assume=20 that the ADMIN_STATUS object is used to change the status of the LSP. = This is a=20 misinterpretation - it is used to control the status of the LSP. Thus, = if there=20 is no change to the status of an LSP, refresh messages must continue to = carry=20 the ADMIN_STATUS object with the same bit setting.
 
In this way, it is not possible to = "drop" the=20 ADMIN_STATUS object without having the same meaning as transmitting the = object=20 with all bits cleared.
 
> 5. Handling of multiple received = ResvConf=20 Request objects
>
> When a connection desires a = confirmation that=20 the service (i.e.
> connection) requested is in place, a = RESV_CONF_REQ=20 object is included in
> the RESV message. As this object is = received by=20 the remote end of the
> reservation, it will send a RESV_CONF = message back=20 to the requester.
>
> However, it is unclear whether it is=20 necessary to send a RESV_CONF message
> when the RSVP connection = state is=20 refreshed by subsequent RESV. This
> becomes potentially = burdensome,=20 especially when the reservation is being
> rapidly refreshed. = Therefore we=20 ask: should the remote end send a
> RESV_CONF message for = subsequent RESV=20 messages that still include the
> RESV_CONF_REQ object? Or is it = required=20 that the requestor of the
> reservation remove the RESV_CONF_REQ = object to=20 prevent the generation of
> further RESV_CONF messages? Comment on = this=20 issue from IETF CCAMP is
> requested.
 
It is fundamental to = the implementation of=20 RSVP-TE that there is a good understanding of the distinction between a = trigger=20 message and a refresh message. This can be achieved by reading section = 1.1 of=20 RFC2961.
 
Following this understanding, you = will note that=20 a refresh message does not cause any processing to be performed at the = LSR that=20 receives it (in this case the ingress). You will also note that refresh=20 processing is not end-to-end as implied in your text, but is=20 hop-by-hop.
 
Thus, an downstream LSR that wishes = to trigger a=20 new ResvConf message must make a specific change to the content of the = Resv=20 message that it sends in order to cause a trigger message to be = propagated=20 through the network to the ingress LSR. Such processing is = implementation=20 specific.

> 6. Symmetry of Refresh Reduction usage
>
> = During=20 interop testing, we ran into a conflict caused by varying
>=20 interpretations of RFC2961, regarding the use of SRefresh messages and=20 the
> Refresh Reduction capabilities of the two ends of a given = link.=20 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=20 Reduction - including the
> SRefresh message. This would be true = even if=20 the other end of the link for
> that interface were NOT indicating = Refresh=20 Reduction Capability, since the
> RFC makes no statement about = symmetry in=20 this matter.
>
> Another interpretation is that both ends = of an=20 interface must indicate
> Refresh Reduction Capability before = either end=20 can use such messages, i.e,
> use of Refresh Reduction on a link = is=20 symmetric.
>
> Comment from CCAMP WG on the correct = interpretation=20 is requested.
 
We are confused by your question.
You correctly state that the use of the refresh-reduction-capable = bit=20 indicates the ability of an LSR to support the receipt of refresh = reduction=20 options and messages. To quote from section 2 of RFC2961...
           When = set,=20 indicates that this node is willing and capable=20 of
           = receiving all=20 the messages and objects described in=20 this
          =20 document.  This includes the Bundle message described=20 in
           = Section 3,=20 the MESSAGE_ID objects and Ack messages=20 described
          = in=20 Section 4, and the MESSAGE_ID LIST objects and=20 Srefresh
           = message=20 described in Section 5.  This bit is meaningful=20 only
           = between=20 RSVP neighbors.
This makes no statement about whether the LSR intends = to use=20 these options when communicating with another LSR.
 
However, you will note that some refresh reduction procedures = require that=20 a message is sent and response returned. In order to make use of the = response,=20 the receiver must be capable of receiving and processing the response. = Thus, it=20 would be usual for an LSR that is capable of sending refresh reduction = options=20 and messages to also set the refresh-reduction-capable bit.
 
In summary:
- An LSR must not send refresh reduction options or=20 messages 
  to an LSR that is not setting the refresh-reduction-capable =
  bit.
- An LSR may send refresh reduction options or messages =20
  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=20 known if a next hop supports the extension, standard Path and Resv = message based=20 refreshes MUST be used."
> 7. Sending of ACKs bundled with the RSVP HELLO
> =
> During=20 interop testing, it was observed that Message Acks were = piggybacked
> onto=20 RSVP Hello messages, when the receiving end was not using the = Hello
>=20 protocol. In this situation, the incoming Hello's were discarded and = the
>=20 Acks were lost.
>
> We believe that Message Acks should = only be=20 piggybacked onto mandatory
> messages, and not on Hello messages = because=20 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=20
   Bundle message.
Thus, Ack messages may be bundled with other messages. (Although = one might=20 consider this perverse since the Ack message is only introduced to = handle the=20 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=20 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=20 sub-message is processed in its own right, and the non-support/non-use = of Hello=20 messages should not impact the processing of other messages.
 
On the other hand, "piggybacked" implies the use of the Ack/Nack = objects=20 within a Hello message.
 
Section 4.1 of RFC2961 states that Ack/Nack objects may be included = in the=20 "standard" RSVP messages, and shows where they are placed. However, RFC = 3209=20 defines the Hello message as not including the Ack/Nack objects...
 
   <Hello Message> ::=3D <Common Header> [=20 <INTEGRITY>=20 ]
           &n= bsp;           &nb= sp;     =20 <HELLO>
 
Since RFC 3209 post-dates RFC 2961, this definition is definitive = and the=20 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=20 may be
   ignored by nodes which do not wish to participate = in=20 Hello message
   processing.
...it is not particularly important what the message format rules = are. An=20 implementation that chooses to place an Ack/Nack object in a Hello = message knows=20 that the object might be discarded unprocessed.
 
> 8. TSPEC format to be used for Ethernet connections
 
The CCAMP working group is currently discussing the use of GMPLS = for=20 control of Ethernet devices. We will respond to this point in a separate = email.

Best regards,
Adrian Farrel
Kireeti Kompella
------=_NextPart_000_08C6_01C59E7A.94425120-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 11 Aug 2005 12:31:49 +0000 Content-class: urn:content-classes:message Subject: RE: draft-ashwood-ccamp-gmpls-constraints Date: Thu, 11 Aug 2005 08:29:20 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA403846FC8@zrtphxm2> Thread-Topic: draft-ashwood-ccamp-gmpls-constraints Thread-Index: AcWcUaICAhsxzeXeQB2k63l/OCm87QArBlFQ From: "Don Fedyk" To: "Igor Bryskin" Cc: Hi Igor Thanks for this text. We will incorporate some this text into the next version of the draft. Hamid had asked me to involve the L1VPN list in this activity going forward. Regards, Don > -----Original Message----- > From: Igor Bryskin [mailto:ibryskin@movaz.com] > Sent: Monday, August 08, 2005 3:44 PM > > Don, > > You can find a detailed description of the Virtual Link mode in the > Layer 1 VPN WG documents. > > In brief, in this mode a domain is represented to the outside routing > domain not as a single node (as in case of the Virtual Node mode), but > as a set of PEs interconnected by virtual (more correctly, abstract) > links. The Virtual Link mode has some serious advantages compared to > the Virtual Node mode. Here is some of them: > > 1. In the Virtual Node mode there is some synchronization required > between > PEs: in order for the outside routing domain to perceive the > hidden domain as a single node all PEs need either to > generate exactly the same advertisings ( specifically, they > need to agree on the Virtual Node Router ID, learn about > every other PE and the links interconnecting the PE with the > outside routing domain, etc.) or identify the outside routing > domain segments interconnected exclusively by the means of > the hidden domain and elect for each of them a single PE that > would generate the Virtual Node advertisings. Neither of > these approaches is trivial to implement. On the contrary, > PEs in the Virtual Link mode advertise information into the > outside routing domain completely independently. > > 2. In order to advertise a matrix of acceptable input-output link > combinations a PE must periodically solve ALL PEs -TO-ALL PEs > constraint based path computation problem. It is far more difficult > problem to solve compared to a single PE -TO-ALL PEs constraint based > path computation (which is as complex as a single source - single > destination path > computation) required in the Virtual Link mode; > > 3. The constraints used during the computation of the input-output > link matrix is not advertised and not available for the external path > computer, which diminishes the value of the matrix advertising. In > other words, even when the external path computer uses the matrix as a > constraint, there is still a significant blocking probability of the > LSP setup using the computed path because there is no guarantee that > the sets of the "external" and "internal" path computation > constraints match. There is no such problem in the Virtual > Link mode where the internal path computation constraints > could be advertised as abstract TE link attributes and hence > could be considered explicitly by the external path computer > > 4. The matrix of input-output link combinations does not provide > information about the cost of a particular input-output binding across > the hidden domain. This means that suboptimal path selection is quite > possible. On the contrary, each abstract TE link advertising has a TE > metric sub-TLV; > > 5. It is not trivial to use the matrix of input-output link > combinations as a constraint, and some modifications of the external > path computation engine algorithms are required. There is no such a > requirement for the Virtual Link mode. > > The major disadvantage of the Virtual Link mode, of course, is > scalability: the number of the abstract links grows proportionally to > the square of number of PEs. Because of that the Virtual Node mode > could be the only choice to hide a domain with large number of PEs. > > Hope this helps. > Igor > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Aug 2005 18:39:24 +0000 Message-ID: <076101c59dda$f00c0c80$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Liaison to ITU-T Q3/15 about your Liaison "Reply on GMPLS/ASON Lexicography" Date: Wed, 10 Aug 2005 19:32:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, This response from Hiroshi Ohta rapporteur of ITU-T Q3/15 indicates that no specific action was required to their liaison, but that we should keep them informed of our progress on the lexicography I-D. Adrian ----- Original Message ----- From: "Hiroshi Ohta" To: "Adrian Farrel" ; Cc: ; ; ; ; ; ; ; ; Sent: Thursday, August 04, 2005 8:45 AM Subject: Re: Liaison to ITU-T Q3/15 about your Liaison "Reply on GMPLS/ASON Lexicography" > Dear Adrian, > > As we talked after the ccamp session yesterday, Q.3/15 expects > a response to our liaison from ccamp in some form and hopes to > continue this on-going dialog between ccamp and some Questions > within SG15. This is the reason for the mark "For: Action". > > Best regards, > > Hiroshi Ohta > Q.3/15 rapporteur > > > At 17:09 05/06/03 +0100, Adrian Farrel wrote: > >Title: Liaison to ITU-T Q3/15 about your Liaison "Reply on GMPLS/ASON > >Lexicography" > >To: ITU-T Study Group 15 Question 3 > >From: IETF CCAMP Working Group > >For: Action > >Deadline: August 1, 2005 > > > >CCAMP would like to thank Q3/15 for their liaison and the useful > >explanatory information it contains. > > > >The liaison is marked "For: Action" with a deadline of August 31,2005. > >However, there are no obvious requests for action within the liaison. > > > >Can you please clarify whether there was an intent to request specific > >action. > > > >Thank you. > > > >Adrian Farrel and Kireeti Kompella > >CCAMP Working Group Co-Chairs > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 10 Aug 2005 09:37:08 +0000 Message-ID: <000f01c59d86$306c2760$0601a8c0@pc6> Reply-To: "Tom Petch" From: "Tom Petch" To: "Adrian Farrel" , Subject: Re: Last call complete on GMPLS MIBs Date: Wed, 10 Aug 2005 10:30:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Adrian I finally got to look at the new versions of the GMPLS MIBs that came out in June and am pleased to see my previous comments in use:-). Some follow up thoughts. In draft-ietf-ccamp-gmpls-te-mib-09, I see that IANAGmplsSwitchingType ::= TEXTUAL-CONVENTION still references "1. Kompella, K., Rekhter, Y. (Editors), Routing Extensions in Support of Generalized Multi-Protocol Label Switching draft-ietf-ccamp-gmpls-routing, work in progress. which I think should be draft-ietf-ccamp-ospf-gmpls-extensions for l2sc (51). The former introduces the concept but does not give a value; the latter assigns the value 51. IANAGmplsLSPEncoding has a reference to D. Papadimitriou (Editor), Generalized MPLS Signalling Extensions for G.709 Optical Transport Networks Control, draft-ietf-ccamp-gmpls-g709, work in progress which I think should make that a normative reference. And, more generally with these references to I-Ds which are normative, should we add a note to tell the RFC editor to replace this with a reference to the RFC when it emerges? That would be business as usual in the References section but might need a little encouragement buried in a MIB module DESCRIPTION. IANAGmplsAdminStatusFlags defines BITS as delInProgress (0), adminDown (1), testing (2), reflect (31) while RFC3471 has reflect as bit 0 and delInProgress as bit 31. Is that correct? (I assume that the intent is to keep them in line and I don't know which way round BITS go; I assumed bit 0 came first and was MSB. If ITU and IETF part company over this, we should be using IETF nomenclature:-) In draft-ietf-ccamp-gmpls-lsr-mib-08.txt, I would like you to give the RFC Editor a little more help in resolving GMPLSTCMIB by explicitly stating that it is the RFC produced from draft-ietf-ccamp-gmpls-tc-mib-07.txt Somewhat bigger issue; I am concerned that no constraint is placed on the allocation by IANA of new values in the IANA MIB module, where the base documents call for more stringent action (although there is some disagreement as to what that is). As it stands, it seems to me that anyone in the world can e-mail IANA and get a new value assigned in the IANA MIB module, whereas I think it should be the appearance of an RFC, eg draft-ietf-ccamp-gmpls-routing or draft-ietf-ccamp-ospf-gmpls-extensions, which triggers that action, perhaps by Expert Review ie the existence of a new name/number mapping is documented in an RFC or I-D and Expert Review allows that mapping to be added to IANA MIB module. We could require the RFC that introduces a new mapping to have an IANA section that updates the MIB module but I fear that most editors would forget to include it, so Expert Review seems best. Finally, I would prefer the IANA MIB modules to be retained in the published RFC with a note that the authoritative source is IANA; this gives us an audit trail of how we got to where we are, or not as the case may be. There has been a case just recently elsewhere where the RFC and IANA are different and it is valuable to see just what it was that was last called and approved by all concerned. As and when the RFC containing the IANA MIB module is reissued, then there would be no need to replicate it. Tom Petch Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 09 Aug 2005 13:54:35 +0000 Message-ID: <043401c59ce9$d17647f0$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft minutes - comments please Date: Tue, 9 Aug 2005 13:09:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit IETF-63 Paris August 2005 CCAMP Working Group Minutes thanks to Deborah Brungard and Don Fedyk Admin Adrian reviewed slides of agenda WG Status Adrian reviewed draft status and milestones ITU and OIF liaison report - Lyndon Ong Reviewed slides - Q14 Plan to share g7713 before goes for consent - No signaling activities, routing they are waiting for our DT response, next meeting in Chicago - OIF activities - OIF communication to IETF with identified issues from demo Adrian: Understand that there is no urgency for responding Will respond as quickly as possible, will post on mailing list. Lyndon: These are results of the demo so there is no dependence but they are important. Dimitri: Were these issues identified before or after demo? Lyndon: Some before, some after. Dimitri: Why not asked over the list for those before? Lyndon: Some of the issues were, like the encoding. The first issue was on an informal response. So we want a formal response. The other issues we made some implementation decisions so we want to verify the decisions. Interdomain RSVP - Arthi Ayyangar - Reviewed slides - Hope to get comments before do next revision (soon) then hope to go for last call Dimitri: Do you plan to keep the examples in the document or as appendix? Arthi: Do you think it affects readability? Dimitri: Prefer as appendix Arthi: OK Adrian: Is this an example or is it normative? Arthi: The example only describes the overall working. LSP stitching: Arthi Ayyangar - Reviewed slides - Summarized discussion on list - First point - Are procedures required for both PSC and non-PSC LSPs? - Discussion on list indicated yes Adrian: Also from a control plane point of view it is better to have a consistent behavior - 2nd point - Should allow stitching while traversing region boundaries? Dimitri: I see no reason for this, why are we still discussing? Adrian: I said yes on the list because of the last bullet on the slide. Why disallow it? Kireeti: I think yes also, why disallow it? Dimitri: Why allow it? Adrian: If we take it out of scope now, we may have to change later, so why remove it now? Yet we don't want to do it speculatively. Igor: Question for kireeti: Can we stitch PSC1 with PSC2 LSP? And we said while we could do this with a label stack, but we shouldn't allow it as these LSPs were provisioned for a reason as two different types (PSC1 and PSC2). In the non-packet world this more clear. Use hierarchy and adaptation. Kireeti: Not so clear for me. PSC1 & PSC2 We understand but Non-PSC we don't understand. For non PSC, we don't know where it will go, e.g. wavelength switching. So why prevent it? Igor: It is not complex but it is pointless. Kireeti: You can always say no when you receive a request to stitch. Arthi and Igor: No, you can't say no Lou: What is the difference between stitching and hierarchical LSP. The LSP on top (inner label) uses all the bandwidth of the one below (outer label). Adrian: The difference is if you add a label for the passenger LSP. Arthi: It's not just label allocation it's resource allocation. I'll address this later. - Bidirectional LSPs and control of labels - Current proposal resolves this by not sending a Label. - 4 options: In Slides: Lou: Minor suggestion; use a different C-type. Call it Option 2 Prime. Arthi: You can, but it is still an issue. Adrian: You have to do special processing when you do stitching anyway. Arthi: You still have to implement the C-type. Kireeti: You don't have to allocate a special label. Adrian: Agree Point 4: Need to provide end-to-end bidirectional service. For example for mpls/gmpls migration. Need to stitch two unidirectional LSPs in the middle. Arthi: Or could do 2nd part of (4). This is not really any changes Just need stronger description on what we are doing Personally like a sending label that is ignored. Adrian: Who likes this 2nd part? - Send any label and have receiver ignore it # Some show of hands Adrian: Anyone prefer one of the other solutions? # (No one?) Adrian: Seems a preference for this 2nd option, will take to list Lou: Clear to make the change. Change the text to Must. Dimitri: Can you make clear on the stitching for bidirectionality Arthi: Should it be required for non PSC? Lou: Anyone that supports stitching MUST support the procedures if they support stitching. Arthi: But if you are not following this document. You could be doing data plane stitching and not control plane stitching. Lou: If it is outside the standard then it is out of scope. If you follow the document you MUST follow the procedures. Per-Domain-Paths - JP Vasseur Would like to get feedback on last issue on slides. Adrian: I think the use of IP reachability information is important. The WG must make a conscious decision. JP: This I-D is only describing reachability outside of domain Adrian: We should say so more clearly Dimitri: I sent feedback. We should cover this question. Not sure if part of this document. This is a problem in several documents. If we have IP reachability, but don't know switching capability, then it's not sure if we can make the connection. This an issue when have a mixture of switching capabilities. Igor: When we compute path, we consider TE resources, not IP reachability. Should not rely on knowing reachability. Once you have a mix of terminating points this is a real issue. Adrian: We need to have a global solution. Igor: You want to compute path consider the resources TE resource reachability of destination. Not to rely on the IP but have static information that you can reach the path. JP: Just want to rely on IP reachability to reach next domain, and then let next domain decide if it can satisfy the request. Igor: OK - maybe could do aggregation rules You can have a static TE entry. JP: But we don't have information on resources Janis ??: Agree that if we are separating data and control plane, this will not work Adrian: Specifying what information to use for path computation is not covered anywhere. It is part of the algorithm, but not part of the protocol. CSPF can use any information including IP reachability or the weather. Arthi: So how do we find next hop? How do you get to the next domain? Adrian: If we don't do this process inside the domain, why do we have to have a way to get out of the domain? JP: So we should remove next hop? Arthi: Does not make sense. How to do crankback? Kireeti: OK - we need to consider further Addresses in GMPLS networks - Richard Rabbat Reviewed slides Arthi: why you are proposing as a std track? Adrian: This decision was a result of a loose poll based on whether this advises, recommends or mandates. Arthi: Can we do again the poll Adrian: We can, who prefers: # BCP - some show of hands # Stds track - less show of hands Arthi: My concern is that it is good to have this document, but it is using items from other docs and making some changes Have to change the Musts and Shoulds. Adrian: If text is repeating the same must/should from another document then it should be deleted. If this is new must/should language then it should be std track Need to clarify definitions. If you are Restating with same values, its BCP. If you change values it is Standards updating an existing RFC or a new Standards track document. Arthi: Then this should be std track as it is already doing it Lou: It is bringing together many items - would suggest informational Could be informational. I did not vote because I was waiting for informational. Adrian: Who wants informational? # almost same show of hands as BCP Lou: If it's implementation then BCP, but if bringing together info, then informational The document is putting recommendations on implementing. Is it just for building and deploying? Or is it Defining a new field or procedure? Adrian: OK we should discuss more Dimitri: I thought the same - it is bringing together experience on using addresses, not saying how to do, and not covering future issues. So I have issue with 9.3 which is not based on experience Adrian: The WG needs to decide how want to do Kireeti: We will discuss with ADs and take to list Arthi: For example, for the FA it says a MUST for how to use, but it doesn't say what to do for static case, so doesn't cover all cases Richard: Yakov: Slide #3. Why the decision on FA LSP, this is a change to the protocol. Richard: You don't know it is a FA LSP. How do you know that it is to be advertised back? John Drake: It is covered in RFC3477. Lou: That is unnumbered interfaces. Adrian: Numbered FA LSPs need a way to indicate to the egress that they will be used as FAs. Compare with unnumbered LSPs that have a special object. Arthi: What is the point of changing it to 0? Kireeti: Let's discuss on the list GMPLS/ASON Lexicography - Igor Bryskin Reviewed slides Igor: If anyone is interested in furthering ason-gmpls convergence, talk to Adrian or myself to help Richard: What is your objective? Igor: Have consensus in the group and expand the dictionary. Richard: Saw in one the drafts on ASON there is an appendix. With ASON terms. Should we integrate the ason-gmpls documents' reference terms into this document? Dimitri: No, that work was for CCAMP people to understand ASON. This is a different purpose Igor: Agree. This is for ITU people to understand GMPLS ASON routing evaluation - Dimitri Papadimitriou Reviewed slides Adrian: Who from DT is in the room? # Dimitri and Lyndon Adrian: Thanks for work. Does the DT think this is ready for last call? Lyndon: Yes. Just some minor editing Adrian: Anyone object to last call # None Alex: Doesn't WG need to read this first Adrian: Yes, need to read it for last call OK take to list for last call ASON signaling - Dimitri Papadimitriou Reviewed slides Dimitri: The community that wants to use this document needs it to be recognized as an RFC, it is important to finish Alex: Any technical issues on this or the last document that need to discuss now? Dimitri: Only this item on simultaneous call/connection signaling Alex: Please summarize the technical issues. Please focus the time in the meeting to raise and discuss open issues Lyndon: Will you liaison to SG15 before last call? Kireeti: Yes Steve Trowbridge: Should also include specific changes against g7713.2 Adrian: What is the intention? Steve: Should be for alignment, should not have two normative versions of ASON signaling Adrian: ITU already has versions .1, .2, .3 Steve: State how it differs from .2 version Adrian: OK. This is GMPLS. 7713.2 is not GMPLS. We can do a comparative analysis. Principal difference is call/connection piggybacking Lyndon: Is this UNI/ENNI/INNI? Dimitri: The document states clearly this if you read it Answer is all three Alex: Are the technical issues complete? It would be much better if we have the technical summary. Not just say this work is ready or work is stable. Adrian: We owe the WG status. Kireeti: Dimitri, can you start the liaison? Dimitri: OK CCAMP Work Plan Kireeti reviewed the slide on options what to do - We have pretty much cleared the documents in our queue, and we are reviewing the charter to update Alex: - I have 12 documents submitted to me, 10 docs in id list. - Documents are done when finished also IESG review, I don't expect to wait for this though before going on to new items. Alex reviewed slide on potential new work - Inter domain OK - Layer 2 switching: where is this? Kireeti: We will have a discussion on where to put it Alex continues: - L1VPN New WG - doesn't seem any objection, should prioritize and timeline - Are these Milestones or Work items? Kireeti: - Could do milestones, but defining work items is easier - For example, MPLS/GMPLS interworking is implicit in the charter but not specifically covered. Alex: Can identify high priority items now Adrian: - We already asked the working group and this is on the first slide. - There are six items shown on the slide Alex: Six items that need some work. Is that too much? Adrian: - Not all things are the same size. - Interoperability issues are already on the plate. - Layer 2 switching Moderate size thing. - MPLS/GMPLS migration moderate size. - Second slide shows recent new topics. Maybe take on new items. - Signaling Issues: - Routing issues - GMPLS OAM requirements. Alex: These items are also important Kireeti: Should look at pipelining work as we already started first slide. It all depends on how long it takes to do charter. We have been waiting now for more than a year Alex: Can prioritize and identify if can spin off work to a new, separate working group. Just like Layer 1 VPN that uses GMPLS. Take out other lumps and put in other WGs? Chairs should identify items. Adrian: We can discuss which could spin off, though we need to decide, and not delay, as many items are already being worked on. Bijan Jabbari: When I look at what is being implemented by vendors there is a mismatch with what this group is doing. Perhaps should look at short term. Alex: Yes my thoughts should look at 1 year to 2 years. Bijan: Not really clear what is being implemented Bijan: I work with Academia and industry, and the answer is not clear. You see implementations but you don't see deployments. Business reasons etc. New way of thinking that takes time. Alex: When go for standard track, do need implementation Kireeti: Also need deployments, and that takes time JP: Regarding the item on "input to PCE requirements". Not sure if need this input Adrian: Explain history is that CCAMP made a commitment to assist PCE Could agree to remove this commitment Alex: Yes we should discuss more in both groups. Don't want to make commitment to remove this before discussing it. If we have consensus maybe we don't need the document. JP: On advertisement of TE/GMPLS capabilities, we have implemented and deployed in 5 large service providers, so would like to expedite this Lou: Slide Back to Slide3: For the item on charter - missing is ASON. What do we do about alignment, and that we have two versions of RSVP? There is only one version of GMPLS, what do we need to do? What steps that we need to take as a WG? Alex: ASON is on our charter Lou: It's on charter - we have completed our documents. We can send to SG15, but what do we do from there to align GMPLS and ASON solutions? Adrian: Added it to slides Richard: On recent new topics - do we know what is in-charter currently? Alex: It is up to chairs: Adrian: If it is in the scope of the charter, we will do milestones There will be discussion on the list. Dimitri: Why is "deployment considerations" considered marginal? If you want feedback, how can this be classified as marginal? Please prioritize and please discuss. Adrian: This is from the community view gathered on the list last year Dimitri: Then how will we have deployment Kireeti: You can do canvassing to get people to discuss. We will take back to the list to do a poll again GMPLS for Ethernet - Dimitri Papadimitriou Reviewed slides Define a set of scenarios: 4 Scenarios -Aggregation -Metro -Unified? Core -Transport Dimitri asked if interest to do this work Don Fedyk: We still don't know what is actually meant by GMPLS Ethernet. The document does not go far enough today with enough detail. The document is too open ended and we don't know what exactly is being specified. I asked for more detailed specification. Dimitri: Ali Sajassi: Ethernet differs from other data planes as it's not point to point. Do you want to keep it as in the perspective of IEEE? Other comments: you want to replace existing Ethernet control plane with GMPLS: again how will you do multipoint? Shortest path may overlap with issues discussed in TRILL. How are you going to coordinate with other WGs? Loa: Not speaking for the DT as we didn't discuss it: I have experience running a medium/large scale Ethernet network as a point-to-point network (unified/core). It would be very applicable to add a gmpls control plane. Note that if we can't do it as a standard we (deployers) will do it ourselves. It is pretty straight forward. Ali: I can see for point to point, it's for multipoint that I see it will have issues Dimitri: OK. Can you input specifics? These questions are relevant. How do we work and overlap with various working groups? Richard Spencer: Can you confirm that using GMPLS in enterprise is out of scope? Dimitri: As no one has expressed interest I would say it is out of scope Richard S: Will there be any changes to Ethernet control/data plane? What would be the potential difficulties? Have a discussion with the IEEE and see where they would be impacted. Dimitri: I can not say what will be the solution chosen, we already suggested we work with IEEE Richard S: I see little value for aggregation. I don't see in metro why a provider would want to use this instead of VPLS Dimitri: I have replied to some of the issues on the list. We should discuss more on list Kireeti: We will not change the Ethernet data plane here. If we conclude it may need to be changed, we will liaise to IEEE and get their agreement. CCAMP is focused on core tunneling technologies, though we don't say how you will use them - metro or core - I would like us to continue not to be specific for access or core. If there is anything specifically different for access, then need to add to charter. Lyndon: There is a lot of interest in other groups (ITU, OIF, MEF). I think there is interest. Where people are uncertain is how. Need to look at more on supporting pt to pt or multipt. Don O'Conner: How does this differ from l2vpn? Dimitri: It differs in that this is not mpls. Kireeti: L2VPON charter is different. L2VPN sets up vpns. This work is on signaling and routing in Ethernet networks. Tom Nadeau: Is this in the scope of CCAMP today? Adrian: Yes this is in the scope as a core network. GMPLS handles packet transport networks. Maybe this is could be a new working group. Tom: Seems similar to TRILL. Adrian: Yes. Need to determine if there is overlap. Perhaps this work should go there. Alternatively, perhaps this work goes in a new WG. Dimitri: Some of the items have been discussed. Loa: Trill is in campus networks. Alex: For structuring this work, we need to be very clear what data path modifications need to be done. Should communicate with IEEE liaison, preferably before BOF. MPLS working group is a specific example. : What would be the way to contact the IEEE to do this? Can I get a Liaison? Alex: We have an established liaison relationship with IEEE. Kireeti: First need to decide if we need a change in the data plane. Then talk to the IEEE. Adrian: Also need to tell IEEE what we plan to do, no matter how we do it. Smith: There are limits to the use of VLAN-ID. There are only 4K of them. Will you use this as the label? Adrian: We haven't decided anything about how forwarding will occur yet Dinesh Mohan: I haven't heard yet that there is planned a change to the data plane. Need to understand better. Should look at this as a new control plane using existing data plane. It would be nice to have the GMPLS Control plane but is there no intent to change the control plane? The basic assumption is that you have a different control plane then that should be the assumption. This is fine to explore, but the starting point is not to modify the data plane. Adrian: When we control SDH we did not mess with the data plane. We should not be modifying the transport technology. Monique Morrow: Echo what Alex said, any modification we need to talk to the IEEE. Dimitri: OK, but we are not talking in the context that there is a change to data plane. Ali: Trill and this are using ISIS. Trill plan to change the data plane. Kireeti: Please stop, take to list. Ali: Several vendors offer Ethernet switches that offer point to point using MPLS control plane supporting millions of connections. Yakov: How? Could you tell me whether they carry a label? Ali: Yes. They are MPLS switches Yakov: So it is a router, an LSR , that you can call an Ethernet switch and you are done? Adrian: That is indeed a suggestion. Don O'C: Ethernet is connectionless and now GMPLS is connection- oriented, so this is different. This is redefining Ethernet to make it connection oriented. Is that the intent? Is this making VLAN tags look like GMPLS labels? Adrian: Again, this has not been discussed Loa: From experience, we don't want to remove VLAN tags. Need something else. And the chairs said to the design team not to do that, yet 80% of CCAMP are already assuming this is what we want to do. Adrian: Design team job is done - Thanks. We need now for the WG to discuss. Time is over. Other drafts that we didn't get to discuss, take to list. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 08 Aug 2005 19:45:55 +0000 Message-ID: <00d701c59c51$94875bb0$7a1810ac@movaz.com> From: "Igor Bryskin" To: "Don Fedyk" Cc: Subject: Re: draft-ashwood-ccamp-gmpls-constraints Date: Mon, 8 Aug 2005 15:44:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Don, You can find a detailed description of the Virtual Link mode in the Layer 1 VPN WG documents. In brief, in this mode a domain is represented to the outside routing domain not as a single node (as in case of the Virtual Node mode), but as a set of PEs interconnected by virtual (more correctly, abstract) links. The Virtual Link mode has some serious advantages compared to the Virtual Node mode. Here is some of them: 1. In the Virtual Node mode there is some synchronization required between PEs: in order for the outside routing domain to perceive the hidden domain as a single node all PEs need either to generate exactly the same advertisings ( specifically, they need to agree on the Virtual Node Router ID, learn about every other PE and the links interconnecting the PE with the outside routing domain, etc.) or identify the outside routing domain segments interconnected exclusively by the means of the hidden domain and elect for each of them a single PE that would generate the Virtual Node advertisings. Neither of these approaches is trivial to implement. On the contrary, PEs in the Virtual Link mode advertise information into the outside routing domain completely independently. 2. In order to advertise a matrix of acceptable input-output link combinations a PE must periodically solve ALL PEs -TO-ALL PEs constraint based path computation problem. It is far more difficult problem to solve compared to a single PE -TO-ALL PEs constraint based path computation (which is as complex as a single source - single destination path computation) required in the Virtual Link mode; 3. The constraints used during the computation of the input-output link matrix is not advertised and not available for the external path computer, which diminishes the value of the matrix advertising. In other words, even when the external path computer uses the matrix as a constraint, there is still a significant blocking probability of the LSP setup using the computed path because there is no guarantee that the sets of the "external" and "internal" path computation constraints match. There is no such problem in the Virtual Link mode where the internal path computation constraints could be advertised as abstract TE link attributes and hence could be considered explicitly by the external path computer 4. The matrix of input-output link combinations does not provide information about the cost of a particular input-output binding across the hidden domain. This means that suboptimal path selection is quite possible. On the contrary, each abstract TE link advertising has a TE metric sub-TLV; 5. It is not trivial to use the matrix of input-output link combinations as a constraint, and some modifications of the external path computation engine algorithms are required. There is no such a requirement for the Virtual Link mode. The major disadvantage of the Virtual Link mode, of course, is scalability: the number of the abstract links grows proportionally to the square of number of PEs. Because of that the Virtual Node mode could be the only choice to hide a domain with large number of PEs. Hope this helps. Igor ----- Original Message ----- From: "Don Fedyk" To: Cc: Sent: Thursday, August 04, 2005 6:03 AM Subject: RE: draft-ashwood-ccamp-gmpls-constraints Igor Thanks for the feedback I would like to work with you to capture the Virtual Link Mode into the draft. Regards, Don > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] > Sent: Thursday, August 04, 2005 5:32 AM > > Hi, > > I believe this is a very useful draft. The described blocking > problem (a limited ability of a node to cross-connect > resources on input and output links wrt a particular LSP) > exists not only in the Virtual Node scenario: there could be > "real" network elements experiencing the problem (perhaps, > because of the hardware limitations). Hence there is a need > for a routing controller to be capable to advertise a map of > acceptable (or > unacceptable) input-output link combinations, and for a path > computer to account for such a constraint (which is not trivial). > > I also would suggest the authors to consider the Virtual Link > mode, that is, representing the domain to the outside world > as a bunch of PEs interconnected by abstract (virtual) links. > This approach may require more advertisements compared to the > Virtual Node mode; however, it does relieve external path > computers from handling the interface maps, plus it gives the > idea about the cost and attributes of feasible paths across > the domain. > > Igor Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 08 Aug 2005 10:32:18 +0000 Message-ID: <00dd01c59c04$8ad14560$08849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Alan Davey" Subject: GMPLS Addressing draft Date: Fri, 5 Aug 2005 15:30:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, In CCAMP in Paris Dimitri raised a specific question about section 9.3 of draft-ietf-ccamp-gmpls-addressing-01.txt. As I understood this question, Dimitri wants only to include material that is relevant to current testing or operational experience. He asks, therefore, whether anyone has deployed or tested scenarios where the source is IPv4 and the destination is IPv6 or vice versa. My view is that we should avoid completeness arguments and limit ourselves to implementations and likely deployments. So if anyone has direct experience of this scenario we will keep the text - otherwise section 9.3 will be deleted. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Aug 2005 10:30:04 +0000 Message-ID: <1254.86.255.26.2.1123151381.squirrel@webmail.movaz.com> Date: Thu, 4 Aug 2005 06:29:41 -0400 (EDT) Subject: RE: draft-ashwood-ccamp-gmpls-constraints From: ibryskin@movaz.com To: "Don Fedyk" Cc: ibryskin@movaz.com, ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sure. We can meet today after lunch, otherwise, by email. Igor > Igor > > Thanks for the feedback I would like to work with you to capture the > Virtual Link Mode into the draft. > > Regards, > Don > >> -----Original Message----- >> From: ibryskin@movaz.com [mailto:ibryskin@movaz.com] >> Sent: Thursday, August 04, 2005 5:32 AM >> >> Hi, >> >> I believe this is a very useful draft. The described blocking >> problem (a limited ability of a node to cross-connect >> resources on input and output links wrt a particular LSP) >> exists not only in the Virtual Node scenario: there could be >> "real" network elements experiencing the problem (perhaps, >> because of the hardware limitations). Hence there is a need >> for a routing controller to be capable to advertise a map of >> acceptable (or >> unacceptable) input-output link combinations, and for a path >> computer to account for such a constraint (which is not trivial). >> >> I also would suggest the authors to consider the Virtual Link >> mode, that is, representing the domain to the outside world >> as a bunch of PEs interconnected by abstract (virtual) links. >> This approach may require more advertisements compared to the >> Virtual Node mode; however, it does relieve external path >> computers from handling the interface maps, plus it gives the >> idea about the cost and attributes of feasible paths across >> the domain. >> >> Igor > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Aug 2005 10:04:18 +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: draft-ashwood-ccamp-gmpls-constraints Date: Thu, 4 Aug 2005 06:03:50 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA4036157B7@zrtphxm2> Thread-Topic: draft-ashwood-ccamp-gmpls-constraints Thread-Index: AcWY127F1UPE2b1sQ0Syyj3IohxigQAA6fdw From: "Don Fedyk" To: Cc: Igor Thanks for the feedback I would like to work with you to capture the Virtual Link Mode into the draft.=20 Regards, Don=20 > -----Original Message----- > From: ibryskin@movaz.com [mailto:ibryskin@movaz.com]=20 > Sent: Thursday, August 04, 2005 5:32 AM >=20 > Hi, >=20 > I believe this is a very useful draft. The described blocking=20 > problem (a limited ability of a node to cross-connect=20 > resources on input and output links wrt a particular LSP)=20 > exists not only in the Virtual Node scenario: there could be=20 > "real" network elements experiencing the problem (perhaps,=20 > because of the hardware limitations). Hence there is a need=20 > for a routing controller to be capable to advertise a map of=20 > acceptable (or > unacceptable) input-output link combinations, and for a path=20 > computer to account for such a constraint (which is not trivial). >=20 > I also would suggest the authors to consider the Virtual Link=20 > mode, that is, representing the domain to the outside world=20 > as a bunch of PEs interconnected by abstract (virtual) links.=20 > This approach may require more advertisements compared to the=20 > Virtual Node mode; however, it does relieve external path=20 > computers from handling the interface maps, plus it gives the=20 > idea about the cost and attributes of feasible paths across=20 > the domain. >=20 > Igor Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Aug 2005 09:52:15 +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: draft-ashwood-ccacmp-gmpls-constraints Date: Thu, 4 Aug 2005 05:51:41 -0400 Message-ID: <0901D1988E815341A0103206A834DA07555CB6@mdmxm02.ciena.com> Thread-Topic: draft-ashwood-ccacmp-gmpls-constraints Thread-Index: AcWY2A9cRcxBNRNWRBqnPuo6V05ZKAAAMbuw From: "Ong, Lyndon" To: , "Don Fedyk" Cc: Hi Igor, I was wondering also about using a virtual link model, that seems to=20 be able to carry similar or more information, with maybe a bit more overhead. Cheers, Lyndon=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of ibryskin@movaz.com Sent: Thursday, August 04, 2005 2:32 AM To: Don Fedyk Cc: ccamp@ops.ietf.org Subject: Re: draft-ashwood-ccacmp-gmpls-constraints Hi, I believe this is a very useful draft. The described blocking problem (a limited ability of a node to cross-connect resources on input and output links wrt a particular LSP) exists not only in the Virtual Node scenario: there could be "real" network elements experiencing the problem (perhaps, because of the hardware limitations). Hence there is a need for a routing controller to be capable to advertise a map of acceptable (or unacceptable) input-output link combinations, and for a path computer to account for such a constraint (which is not trivial). I also would suggest the authors to consider the Virtual Link mode, that is, representing the domain to the outside world as a bunch of PEs interconnected by abstract (virtual) links. This approach may require more advertisements compared to the Virtual Node mode; however, it does relieve external path computers from handling the interface maps, plus it gives the idea about the cost and attributes of feasible paths across the domain. Igor > > Since we did not get through all the CCAMP agenda today, I would still > like to get feedback on the following draft. > > Link Viability Constraints Don Fedyk (5 mins)=20 > http://home.clara.net/olddog/63/draft-ashwood-ccamp-gmpls-constraint-r > eq > ts-00.ppt > http://www.ietf.org/internet-drafts/draft-ashwood-ccamp-gmpls-constrai > nt > -reqts-00.txt > > Note the draft is about interfacing a dynamic optical system to a=20 > GMPLS control plane but puts forward the argument we can avoid for now > the standardization of the detailed optical constraints. I would like > to see this in Scope for the IETF (CCAMP) even though I realize the=20 > detailed (or complex) optical constraints may be years from being in=20 > scope and standardization. The current draft is a requirements draft=20 > with some preliminary ideas on how this can be achieved. I would like=20 > to solicit others who are interested in working this problem. > > Please send feedback, I'm around till Friday if anyone would like to=20 > discuss in person, Thanks, Don > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 04 Aug 2005 09:33:47 +0000 Message-ID: <4995.86.255.26.2.1123147927.squirrel@webmail.movaz.com> Date: Thu, 4 Aug 2005 05:32:07 -0400 (EDT) Subject: Re: draft-ashwood-ccacmp-gmpls-constraints From: ibryskin@movaz.com To: "Don Fedyk" Cc: ccamp@ops.ietf.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I believe this is a very useful draft. The described blocking problem (a limited ability of a node to cross-connect resources on input and output links wrt a particular LSP) exists not only in the Virtual Node scenario: there could be “real” network elements experiencing the problem (perhaps, because of the hardware limitations). Hence there is a need for a routing controller to be capable to advertise a map of acceptable (or unacceptable) input-output link combinations, and for a path computer to account for such a constraint (which is not trivial). I also would suggest the authors to consider the Virtual Link mode, that is, representing the domain to the outside world as a bunch of PEs interconnected by abstract (virtual) links. This approach may require more advertisements compared to the Virtual Node mode; however, it does relieve external path computers from handling the interface maps, plus it gives the idea about the cost and attributes of feasible paths across the domain. Igor > > Since we did not get through all the CCAMP agenda today, I would still > like to get feedback on the following draft. > > Link Viability Constraints Don Fedyk (5 mins) > http://home.clara.net/olddog/63/draft-ashwood-ccamp-gmpls-constraint-req > ts-00.ppt > http://www.ietf.org/internet-drafts/draft-ashwood-ccamp-gmpls-constraint > -reqts-00.txt > > Note the draft is about interfacing a dynamic optical system to a GMPLS > control plane but puts forward the argument we can avoid for now the > standardization of the detailed optical constraints. I would like to > see this in Scope for the IETF (CCAMP) even though I realize the > detailed (or complex) optical constraints may be years from being in > scope and standardization. The current draft is a requirements draft > with some preliminary ideas on how this can be achieved. I would like to > solicit others who are interested in working this problem. > > Please send feedback, I'm around till Friday if anyone would like to > discuss in person, > Thanks, > Don > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 03 Aug 2005 16:53:05 +0000 Content-class: urn:content-classes:message Subject: draft-ashwood-ccacmp-gmpls-constraints Date: Wed, 3 Aug 2005 12:50:37 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA403615077@zrtphxm2> Thread-Topic: draft-ashwood-ccacmp-gmpls-constraints Thread-Index: AcWR8KZ24x4uqrZrQTmtl148bcRRTwGVHAgg From: "Don Fedyk" To: Hi Since we did not get through all the CCAMP agenda today, I would still like to get feedback on the following draft. Link Viability Constraints Don Fedyk (5 mins) http://home.clara.net/olddog/63/draft-ashwood-ccamp-gmpls-constraint-req ts-00.ppt http://www.ietf.org/internet-drafts/draft-ashwood-ccamp-gmpls-constraint -reqts-00.txt Note the draft is about interfacing a dynamic optical system to a GMPLS control plane but puts forward the argument we can avoid for now the standardization of the detailed optical constraints. I would like to see this in Scope for the IETF (CCAMP) even though I realize the detailed (or complex) optical constraints may be years from being in scope and standardization. The current draft is a requirements draft with some preliminary ideas on how this can be achieved. I would like to solicit others who are interested in working this problem. Please send feedback, I'm around till Friday if anyone would like to discuss in person, Thanks, Don Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Aug 2005 12:07:35 +0000 Message-ID: <01ab01c5975a$f386dd80$7810ff56@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Subject: Re: LCAS and GMPLS Date: Tue, 2 Aug 2005 13:08:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Thanks Michael, That fits with my assessment. Its a plan. Adrian ----- Original Message ----- From: To: ; Sent: Tuesday, August 02, 2005 11:46 AM Subject: AW: LCAS and GMPLS Hi, Clearly CCAMP is not supposed to do TU-T's job... I have a feeling we need more clarification of the actual requrirements, and then assess which functionalities are supported by SONET/SDH or GMPLS already to identify the missing bits. It may then turn out that we actually most of the mechanisms in place, but need a BCP to clarify how to use them properly. My suggestion to take this forward is that we briefly discuss the two drafts tomorrow, then refine the requirements and the solution drafts until the next IETF meeting. Again, there is definitive interest by operators to get the SDH and GMPLS interworking as clear as possible. Regards, Michael -----Ursprüngliche Nachricht----- Von: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] Im Auftrag von Adrian Farrel Gesendet: Dienstag, 2. August 2005 11:42 An: Huub van Helvoort; ccamp Betreff: Re: LCAS and GMPLS Hi Huub, > > I think the original proposal is that SG15 may want to send CCAMP a > > liaison about this work. That would certainly be fine. > > [hvh] I tried but did not get enough support That is a shame because it is hard for CCAMP to work on this without a clear statement of the requirements and we look to the ITU-T to supply the details of LCAS. If we can identify more precisely what it is we need to know, then we can liaise a request for information. > > I don't think that CCAMP can send a liaison back to support the work > > without having seen it first. > > [hvh] both draft-imajuku-ccamp-gmpls-vcat-lagr-req > and draft-bernstein-LCAS-GMPLS > refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this > recommendation contains the following note: > "NOTE - If a permanent removal of an active member is initiated at the > Sk, this will result in a hit to the reconstructed data. The duration > of this hit will be from the time the member is removed (starts > sending MST = FAIL) until the DNU would have been received from the > So." > > So I supposed the authors of these drafts were aware > of this note, and consequently the mandatory sequence > for a hitless decrease of bandwidth: remove member at > source node first, wait for confirmation, remove member > at sink node (and network path). > Maybe the authors were not aware of a possible solution > presented at the recent SG 15 meeting. I can't speak for the authors. Speaking for myself, I was not aware of the work at the SG15 meeting. I am certain that the majority of CCAMP was not aware. > > With regard to the solution space for the problem: > > - If the solution lies entirely within LCAS then it is out of scope for > > CCAMP. The LSP will simply be torn down when the LCAS > > synchronization has > > been done. > > [hvh] indeed the solution is within the LCAS protocol, but has an > impact on the control plane: it removes the mandatory sequence > for hitless decrease. Yes. it removes a requirement. It doesn't remove any protocol elements because they already exist. It changes the solutions doc, because there is no need to describe a non-requirement. > > - If the problem is to be solved within GMPLS, then we have a > > suitable mechanism already. > > [hvh] if you mean that GMPLS can take care of or guarantee the > above mentioned mandatory sequence, then indeed there is > no problem. > However IMHO it may be a complex solution. Well, if we establish that this *is* a requirement we have to solve it. That will start a discussion of how simple/practical the solution is. IM(NS)HO this is easy work using existing GMPLS tools. > > Thus, it turns out that it is important to scope problems not just > > functionally, but according to which components are intended to resolve > > them. > > [hvh] I hope I did above. Thanks, yes. But in order to understand the requirements here we must understand what we are tyring to support. Do we need to support existing LCAS implementations, or can we assume that the SG15 proposals will come to agreement/standardisation and will be implemented ubiquitously? See below... > > Very obviously, the industry does not need or want two solutions to the > > same problem. > > [hvh] the solution proposed in the last plenary meeting of ITU-T > SG15 delayed document D.286 did not get concensus in the Q11 > meeting. When presented in the Q14 meeting it was agreed that > this proposal would simplify the control of LCAS LSPs. > > If this solution is not accepted soon, more LCAS implementations > will be cast in silicon (currently the majority is in SW) and > t will be very hard to get it accepted at a later date. > > When CCAMP sees the need for adding this enhancement that > removes the mandatory remove sequence, shouldn't a liaison > be sent to SG15/Q11 to express their concern? I think CCAMP will understand the need for hitless add/remove. If CCAMP sees/believes that LCAS does not support this function, then CCAMP will attempt to deliver this function. If CCAMP sees/believes that LCAS already delivers the function, this will not be something that CCAMP discusses further. However, it is not for CCAMP to comment on the function contained within LCAS. LCAS is not our protocol to comment on. Thanks, Adrian > > Cheers, Huub. > > > Adrian > > ----- Original Message ----- > > From: "Huub van Helvoort" > > To: "ccamp" > > Sent: Sunday, July 31, 2005 3:21 PM > > Subject: Re: LCAS and GMPLS > > > >>Hello Wataru, > >> > >>You wrote: > >> > >>>I forward a nice comment from Mr. Huub van Helvoort. > >> > >>Thank you for forwarding. > >>(I hope I can send this message the list myself). > >> > >>>His comments indicates we need liason from ITU-T SG-15 regarding to > >>>this issue. > >> > >>This is a good proposal, it will indicate to ITU-T SG15/Q11 that > >>IETF/CCAMP supports this enhancement. > >> > >>Kind regards, Huub. > >> > >>--- from message 27-7-2005 --- > >> > >> > >>>>One point for the problem statement could be that in order to > >>>>guarantee a hitless removal of one of the members in a VCG > >>>>(decrease of bandwidth) there is a mandatory sequence: First > >>>>remove member at ingress node, wait for confirm and only then > >>>>remove path and member at egress node. > >>>> > >>>>However, a solution was presented at the last ITU-T SG15/q11 > >>>>meeting that removes this requirement. > >>>> > >>>>Cheers, Huub. > > -- > ================================================================ > http://members.chello.nl/hhelvoort/ > ================================================================ > Always remember that you are unique...just like everyone else... > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Aug 2005 10:48:39 +0000 Message-Id: From: Michael.Dueser@t-systems.com To: adrian@olddog.co.uk, ccamp@ops.ietf.org Subject: AW: LCAS and GMPLS Date: Tue, 2 Aug 2005 12:46:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 Clearly CCAMP is not supposed to do TU-T's job... I have a feeling we = need more clarification of the actual requrirements, and then assess = which functionalities are supported by SONET/SDH or GMPLS already to = identify the missing bits. It may then turn out that we actually most = of the mechanisms in place, but need a BCP to clarify how to use them = properly. My suggestion to take this forward is that we briefly discuss = the two drafts tomorrow, then refine the requirements and the solution = drafts until the next IETF meeting. Again, there is definitive interest = by operators to get the SDH and GMPLS interworking as clear as = possible. Regards, Michael=20 -----Urspr=FCngliche Nachricht----- Von: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] Im = Auftrag von Adrian Farrel Gesendet: Dienstag, 2. August 2005 11:42 An: Huub van Helvoort; ccamp Betreff: Re: LCAS and GMPLS Hi Huub, > > I think the original proposal is that SG15 may want to send CCAMP a = > > liaison about this work. That would certainly be fine. > > [hvh] I tried but did not get enough support That is a shame because it is hard for CCAMP to work on this without a = clear statement of the requirements and we look to the ITU-T to supply = the details of LCAS. If we can identify more precisely what it is we need to know, then we = can liaise a request for information. > > I don't think that CCAMP can send a liaison back to support the = work=20 > > without having seen it first. > > [hvh] both draft-imajuku-ccamp-gmpls-vcat-lagr-req > and draft-bernstein-LCAS-GMPLS > refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this > recommendation contains the following note: > "NOTE - If a permanent removal of an active member is initiated at = the=20 > Sk, this will result in a hit to the reconstructed data. The duration = > of this hit will be from the time the member is removed (starts=20 > sending MST =3D FAIL) until the DNU would have been received from the = > So." > > So I supposed the authors of these drafts were aware > of this note, and consequently the mandatory sequence > for a hitless decrease of bandwidth: remove member at > source node first, wait for confirmation, remove member > at sink node (and network path). > Maybe the authors were not aware of a possible solution > presented at the recent SG 15 meeting. I can't speak for the authors. Speaking for myself, I was not aware of the work at the SG15 meeting. I = am certain that the majority of CCAMP was not aware. > > With regard to the solution space for the problem: > > - If the solution lies entirely within LCAS then it is out of scope for > > CCAMP. The LSP will simply be torn down when the LCAS=20 > > synchronization has > > been done. > > [hvh] indeed the solution is within the LCAS protocol, but has an > impact on the control plane: it removes the mandatory sequence > for hitless decrease. Yes. it removes a requirement. It doesn't remove any protocol elements because they already exist. It = changes the solutions doc, because there is no need to describe a = non-requirement. > > - If the problem is to be solved within GMPLS, then we have a=20 > > suitable mechanism already. > > [hvh] if you mean that GMPLS can take care of or guarantee the > above mentioned mandatory sequence, then indeed there is > no problem. > However IMHO it may be a complex solution. Well, if we establish that this *is* a requirement we have to solve it. = That will start a discussion of how simple/practical the solution is. = IM(NS)HO this is easy work using existing GMPLS tools. > > Thus, it turns out that it is important to scope problems not just=20 > > functionally, but according to which components are intended to resolve > > them. > > [hvh] I hope I did above. Thanks, yes. But in order to understand the requirements here we must understand = what we are tyring to support. Do we need to support existing LCAS = implementations, or can we assume that the SG15 proposals will come to = agreement/standardisation and will be implemented ubiquitously? See below... > > Very obviously, the industry does not need or want two solutions to the > > same problem. > > [hvh] the solution proposed in the last plenary meeting of ITU-T > SG15 delayed document D.286 did not get concensus in the Q11 > meeting. When presented in the Q14 meeting it was agreed that > this proposal would simplify the control of LCAS LSPs. > > If this solution is not accepted soon, more LCAS = implementations > will be cast in silicon (currently the majority is in SW) and > t will be very hard to get it accepted at a later date. > > When CCAMP sees the need for adding this enhancement that > removes the mandatory remove sequence, shouldn't a liaison > be sent to SG15/Q11 to express their concern? I think CCAMP will understand the need for hitless add/remove. If CCAMP = sees/believes that LCAS does not support this function, then CCAMP will = attempt to deliver this function. If CCAMP sees/believes that LCAS = already delivers the function, this will not be something that CCAMP = discusses further. However, it is not for CCAMP to comment on the function contained = within LCAS. LCAS is not our protocol to comment on. Thanks, Adrian > > Cheers, Huub. > > > Adrian > > ----- Original Message ----- > > From: "Huub van Helvoort" > > To: "ccamp" > > Sent: Sunday, July 31, 2005 3:21 PM > > Subject: Re: LCAS and GMPLS > > > >>Hello Wataru, > >> > >>You wrote: > >> > >>>I forward a nice comment from Mr. Huub van Helvoort. > >> > >>Thank you for forwarding. > >>(I hope I can send this message the list myself). > >> > >>>His comments indicates we need liason from ITU-T SG-15 regarding = to=20 > >>>this issue. > >> > >>This is a good proposal, it will indicate to ITU-T SG15/Q11 that=20 > >>IETF/CCAMP supports this enhancement. > >> > >>Kind regards, Huub. > >> > >>--- from message 27-7-2005 --- > >> > >> > >>>>One point for the problem statement could be that in order to=20 > >>>>guarantee a hitless removal of one of the members in a VCG=20 > >>>>(decrease of bandwidth) there is a mandatory sequence: First=20 > >>>>remove member at ingress node, wait for confirm and only then=20 > >>>>remove path and member at egress node. > >>>> > >>>>However, a solution was presented at the last ITU-T SG15/q11=20 > >>>>meeting that removes this requirement. > >>>> > >>>>Cheers, Huub. > > -- > = =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=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 > http://members.chello.nl/hhelvoort/ > = =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=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 > Always remember that you are unique...just like everyone else... > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Aug 2005 09:40:17 +0000 Message-ID: <013b01c59746$7d268af0$7810ff56@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Huub van Helvoort" , "ccamp" Subject: Re: LCAS and GMPLS Date: Tue, 2 Aug 2005 10:42:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hi Huub, > > I think the original proposal is that SG15 may want to send CCAMP a > > liaison about this work. That would certainly be fine. > > [hvh] I tried but did not get enough support That is a shame because it is hard for CCAMP to work on this without a clear statement of the requirements and we look to the ITU-T to supply the details of LCAS. If we can identify more precisely what it is we need to know, then we can liaise a request for information. > > I don't think that CCAMP can send a liaison back to support the work > > without having seen it first. > > [hvh] both draft-imajuku-ccamp-gmpls-vcat-lagr-req > and draft-bernstein-LCAS-GMPLS > refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this > recommendation contains the following note: > "NOTE – If a permanent removal of an active member is initiated at the > Sk, this will result in a hit to the reconstructed data. The duration of > this hit will be from the time the member is removed (starts sending MST > = FAIL) until the DNU would have been received from the So." > > So I supposed the authors of these drafts were aware > of this note, and consequently the mandatory sequence > for a hitless decrease of bandwidth: remove member at > source node first, wait for confirmation, remove member > at sink node (and network path). > Maybe the authors were not aware of a possible solution > presented at the recent SG 15 meeting. I can't speak for the authors. Speaking for myself, I was not aware of the work at the SG15 meeting. I am certain that the majority of CCAMP was not aware. > > With regard to the solution space for the problem: > > - If the solution lies entirely within LCAS then it is out of scope for > > CCAMP. The LSP will simply be torn down when the LCAS synchronization has > > been done. > > [hvh] indeed the solution is within the LCAS protocol, but has an > impact on the control plane: it removes the mandatory sequence > for hitless decrease. Yes. it removes a requirement. It doesn't remove any protocol elements because they already exist. It changes the solutions doc, because there is no need to describe a non-requirement. > > - If the problem is to be solved within GMPLS, then we have a suitable > > mechanism already. > > [hvh] if you mean that GMPLS can take care of or guarantee the > above mentioned mandatory sequence, then indeed there is > no problem. > However IMHO it may be a complex solution. Well, if we establish that this *is* a requirement we have to solve it. That will start a discussion of how simple/practical the solution is. IM(NS)HO this is easy work using existing GMPLS tools. > > Thus, it turns out that it is important to scope problems not just > > functionally, but according to which components are intended to resolve > > them. > > [hvh] I hope I did above. Thanks, yes. But in order to understand the requirements here we must understand what we are tyring to support. Do we need to support existing LCAS implementations, or can we assume that the SG15 proposals will come to agreement/standardisation and will be implemented ubiquitously? See below... > > Very obviously, the industry does not need or want two solutions to the > > same problem. > > [hvh] the solution proposed in the last plenary meeting of ITU-T > SG15 delayed document D.286 did not get concensus in the Q11 > meeting. When presented in the Q14 meeting it was agreed that > this proposal would simplify the control of LCAS LSPs. > > If this solution is not accepted soon, more LCAS implementations > will be cast in silicon (currently the majority is in SW) and > t will be very hard to get it accepted at a later date. > > When CCAMP sees the need for adding this enhancement that > removes the mandatory remove sequence, shouldn't a liaison > be sent to SG15/Q11 to express their concern? I think CCAMP will understand the need for hitless add/remove. If CCAMP sees/believes that LCAS does not support this function, then CCAMP will attempt to deliver this function. If CCAMP sees/believes that LCAS already delivers the function, this will not be something that CCAMP discusses further. However, it is not for CCAMP to comment on the function contained within LCAS. LCAS is not our protocol to comment on. Thanks, Adrian > > Cheers, Huub. > > > Adrian > > ----- Original Message ----- > > From: "Huub van Helvoort" > > To: "ccamp" > > Sent: Sunday, July 31, 2005 3:21 PM > > Subject: Re: LCAS and GMPLS > > > >>Hello Wataru, > >> > >>You wrote: > >> > >>>I forward a nice comment from Mr. Huub van Helvoort. > >> > >>Thank you for forwarding. > >>(I hope I can send this message the list myself). > >> > >>>His comments indicates we need liason from ITU-T SG-15 regarding to > >>>this issue. > >> > >>This is a good proposal, it will indicate to ITU-T SG15/Q11 > >>that IETF/CCAMP supports this enhancement. > >> > >>Kind regards, Huub. > >> > >>--- from message 27-7-2005 --- > >> > >> > >>>>One point for the problem statement could be that in order to > >>>>guarantee a hitless removal of one of the members in a VCG > >>>>(decrease of bandwidth) there is a mandatory sequence: > >>>>First remove member at ingress node, wait for confirm and > >>>>only then remove path and member at egress node. > >>>> > >>>>However, a solution was presented at the last ITU-T SG15/q11 > >>>>meeting that removes this requirement. > >>>> > >>>>Cheers, Huub. > > -- > ================================================================ > http://members.chello.nl/hhelvoort/ > ================================================================ > Always remember that you are unique...just like everyone else... > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Aug 2005 08:50:48 +0000 Message-ID: <42EF3395.5@chello.nl> Date: Tue, 02 Aug 2005 10:49:25 +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: ccamp CC: Adrian Farrel Subject: Re: LCAS and GMPLS Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello Adrian, Thanks for your comments. I shall try to give some more insight. You wrote: > I think the original proposal is that SG15 may want to send CCAMP a > liaison about this work. That would certainly be fine. [hvh] I tried but did not get enough support > I don't think that CCAMP can send a liaison back to support the work > without having seen it first. [hvh] both draft-imajuku-ccamp-gmpls-vcat-lagr-req and draft-bernstein-LCAS-GMPLS refer to ITU-T G.7042. Corrigendum 1 (08/2004) to this recommendation contains the following note: "NOTE – If a permanent removal of an active member is initiated at the Sk, this will result in a hit to the reconstructed data. The duration of this hit will be from the time the member is removed (starts sending MST = FAIL) until the DNU would have been received from the So." So I supposed the authors of these drafts were aware of this note, and consequently the mandatory sequence for a hitless decrease of bandwidth: remove member at source node first, wait for confirmation, remove member at sink node (and network path). Maybe the authors were not aware of a possible solution presented at the recent SG 15 meeting. > With regard to the solution space for the problem: > - If the solution lies entirely within LCAS then it is out of scope for > CCAMP. The LSP will simply be torn down when the LCAS synchronization has > been done. [hvh] indeed the solution is within the LCAS protocol, but has an impact on the control plane: it removes the mandatory sequence for hitless decrease. > - If the problem is to be solved within GMPLS, then we have a suitable > mechanism already. [hvh] if you mean that GMPLS can take care of or guarantee the above mentioned mandatory sequence, then indeed there is no problem. However IMHO it may be a complex solution. > Thus, it turns out that it is important to scope problems not just > functionally, but according to which components are intended to resolve > them. [hvh] I hope I did above. > Very obviously, the industry does not need or want two solutions to the > same problem. [hvh] the solution proposed in the last plenary meeting of ITU-T SG15 delayed document D.286 did not get concensus in the Q11 meeting. When presented in the Q14 meeting it was agreed that this proposal would simplify the control of LCAS LSPs. If this solution is not accepted soon, more LCAS implementations will be cast in silicon (currently the majority is in SW) and t will be very hard to get it accepted at a later date. When CCAMP sees the need for adding this enhancement that removes the mandatory remove sequence, shouldn't a liaison be sent to SG15/Q11 to express their concern? Cheers, Huub. > Adrian > ----- Original Message ----- > From: "Huub van Helvoort" > To: "ccamp" > Sent: Sunday, July 31, 2005 3:21 PM > Subject: Re: LCAS and GMPLS > >>Hello Wataru, >> >>You wrote: >> >>>I forward a nice comment from Mr. Huub van Helvoort. >> >>Thank you for forwarding. >>(I hope I can send this message the list myself). >> >>>His comments indicates we need liason from ITU-T SG-15 regarding to >>>this issue. >> >>This is a good proposal, it will indicate to ITU-T SG15/Q11 >>that IETF/CCAMP supports this enhancement. >> >>Kind regards, Huub. >> >>--- from message 27-7-2005 --- >> >> >>>>One point for the problem statement could be that in order to >>>>guarantee a hitless removal of one of the members in a VCG >>>>(decrease of bandwidth) there is a mandatory sequence: >>>>First remove member at ingress node, wait for confirm and >>>>only then remove path and member at egress node. >>>> >>>>However, a solution was presented at the last ITU-T SG15/q11 >>>>meeting that removes this requirement. >>>> >>>>Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Aug 2005 00:28:53 +0000 Message-ID: <00b001c596f6$07f38c10$7810ff56@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Huub van Helvoort" , "ccamp" Subject: Re: LCAS and GMPLS Date: Tue, 2 Aug 2005 01:04:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Huub, Wataru, I think the original proposal is that SG15 may want to send CCAMP a liaison about this work. That would certainly be fine. I don't think that CCAMP can send a liaison back to support the work without having seen it first. With regard to the solution space for the problem: - If the solution lies entirely within LCAS then it is out of scope for CCAMP. The LSP will simply be torn down when the LCAS synchronization has been done. - If the problem is to be solved within GMPLS, then we have a suitable mechanism already. Thus, it turns out that it is important to scope problems not just functionally, but according to which components are intended to resolve them. Very obviously, the industry does not need or want two solutions to the same problem. Adrian ----- Original Message ----- From: "Huub van Helvoort" To: "ccamp" Sent: Sunday, July 31, 2005 3:21 PM Subject: Re: LCAS and GMPLS > Hello Wataru, > > You wrote: > > > I forward a nice comment from Mr. Huub van Helvoort. > > Thank you for forwarding. > (I hope I can send this message the list myself). > > > His comments indicates we need liason from ITU-T SG-15 regarding to > > this issue. > > This is a good proposal, it will indicate to ITU-T SG15/Q11 > that IETF/CCAMP supports this enhancement. > > Kind regards, Huub. > > --- from message 27-7-2005 --- > > >> > >> One point for the problem statement could be that in order to > >> guarantee a hitless removal of one of the members in a VCG > >> (decrease of bandwidth) there is a mandatory sequence: > >> First remove member at ingress node, wait for confirm and > >> only then remove path and member at egress node. > >> > >> However, a solution was presented at the last ITU-T SG15/q11 > >> meeting that removes this requirement. > >> > >> Cheers, Huub. > > -- > ================================================================ > http://members.chello.nl/hhelvoort/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 02 Aug 2005 00:06:43 +0000 Message-ID: <00b001c596f6$07f38c10$7810ff56@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Huub van Helvoort" , "ccamp" Subject: Re: LCAS and GMPLS Date: Tue, 2 Aug 2005 01:04:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Huub, Wataru, I think the original proposal is that SG15 may want to send CCAMP a liaison about this work. That would certainly be fine. I don't think that CCAMP can send a liaison back to support the work without having seen it first. With regard to the solution space for the problem: - If the solution lies entirely within LCAS then it is out of scope for CCAMP. The LSP will simply be torn down when the LCAS synchronization has been done. - If the problem is to be solved within GMPLS, then we have a suitable mechanism already. Thus, it turns out that it is important to scope problems not just functionally, but according to which components are intended to resolve them. Very obviously, the industry does not need or want two solutions to the same problem. Adrian ----- Original Message ----- From: "Huub van Helvoort" To: "ccamp" Sent: Sunday, July 31, 2005 3:21 PM Subject: Re: LCAS and GMPLS > Hello Wataru, > > You wrote: > > > I forward a nice comment from Mr. Huub van Helvoort. > > Thank you for forwarding. > (I hope I can send this message the list myself). > > > His comments indicates we need liason from ITU-T SG-15 regarding to > > this issue. > > This is a good proposal, it will indicate to ITU-T SG15/Q11 > that IETF/CCAMP supports this enhancement. > > Kind regards, Huub. > > --- from message 27-7-2005 --- > > >> > >> One point for the problem statement could be that in order to > >> guarantee a hitless removal of one of the members in a VCG > >> (decrease of bandwidth) there is a mandatory sequence: > >> First remove member at ingress node, wait for confirm and > >> only then remove path and member at egress node. > >> > >> However, a solution was presented at the last ITU-T SG15/q11 > >> meeting that removes this requirement. > >> > >> Cheers, Huub. > > -- > ================================================================ > http://members.chello.nl/hhelvoort/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 01 Aug 2005 08:09:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt Date: Mon, 1 Aug 2005 10:08:17 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt Thread-Index: AcWU6UF6wMowosxgRreHsS9OWN0BPQBhkwkg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: , Cc: , , Hi Adrian, See inline =20 > -----Message d'origine----- > De : Adrian Farrel [mailto:olddog@clara.co.uk]=20 > Envoy=E9 : samedi 30 juillet 2005 11:30 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Dimitri.Papadimitriou@alcatel.be > Cc : arthi@juniper.net; ccamp@ops.ietf.org; jpv@cisco.com;=20 > zzx-adrian@olddog.co.uk > Objet : Re: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt >=20 > Hi,=20 >=20 > Time for me to speak out about the omission of hitherto=20 > mandatory objects from signaling messages.=20 >=20 > I would MUCH prefer that you keep the objects (Upstream Label=20 > or Path, Label on Resv) and use a special label value=20 > (implicit null? some new reserved label value?) to mean=20 > "stitch this".=20 I agree with you.=20 Actually this is what I suggested in the previous email, see below > > JLLR: Yes, and what about defining a new MPLS label value, let say=20 > > label > > 4 =3D "No label assigned", with a semantic distinct from label=20 > >3 semantic (=3Dlabel pop). The UPSTREAM label object with this=20 > >new label value would be included in the end-to-end Path=20 > >message over the LSP-Segment... Regards, JL >=20 > For me this is more natural and is less of a significant=20 > change to the existing protocol and implementation.=20 >=20 > It also solves the bidirection problem.=20 >=20 > Opinions?=20 >=20 > Cheers, > Adrian=20 >=20 >=20 > ----- Original Message ----- > From: > To: "LE ROUX Jean-Louis RD-CORE-LAN"=20 > > Cc: "Arthi Ayyangar" ;=20 > ; > Sent: Friday, July 29, 2005 9:39 PM > Subject: RE: I-D ACTION:draft-ietf-ccamp-lsp-stitching-01.txt=20 >=20 >=20 > > > > hi j-l, arthi > > > > > > > > -In section 4.1.2 you partially describe bidirectional LSP > > > stitching > > > > procedure. You mention that an Upstream Label MUST NOT be > > > allocated by > > > > the end-to-end LSP on the LSP segment, which is OK. But > > > then how the > > > > LSP-Segment Egress will now that the end-to-end LSP is > > > bidirectional? > > > AA--------> Excellent point. > > > > > > > What about defining a flag in the Attributes Flags TLV of the=20 > > > > LSP_ATTRIBUTE object so as to indicate that the LSP is > > > bidirectional? > > > AA------> That would be a change to the processing that GMPLS > > > nodes use > > > AA------> to > > > detect bidirectionality, isn't it ? Normally nodes look for the=20 > > > Upstream Label object to detect bidirectionality. > > > > > > So let us say that an LSP is bidirectional if a) an=20 > Upstream Label=20 > > > is present or b) no Upstream Label, but bit set in=20 > LSP_ATTRIBUTE or=20 > > > c) both However, reliance on an e2e attributes bit set by=20 > head end,=20 > > > means existing head ends will not be setting this bit, so=20 > that will=20 > > > be an issue (wrt compatibility). > > > > JLLR: I agree this may raise some backward compatibility issues. > > This would require that head-ends be upgraded...=20 > > > > > > DP: the other issue is having two methods for indicating the same=20 > > thing > is also not advisable > >=20 > > > > > Could be nice if this signaling was just between the node=20 > doing the=20 > > > stitching and the end point of the LSP segment, since this is the=20 > > > hop that the bidirectionality information is lost. Let me think=20 > > > about this. > > > > JLLR: Yes, and what about defining a new MPLS label value, let say=20 > > label > 4 =3D "No label assigned", with a semantic distinct from label=20 > 3 semantic (=3Dlabel pop). The UPSTREAM label object with this=20 > new label value would be included in the end-to-end Path=20 > message over the LSP-Segment... > >=20 > > > > DP: assuming an information has to be passed for the indicating this > capability i do also think a method like passing an implicit=20 > indication in the upstream label value would be more=20 > appropriated (note that the initial issue is due to the fact=20 > one would allow for unidirectional e2e LSP making use of=20 > bidirectional LSP segments - see comment from J-L here below=20 > - and not maintaining a 1:1 relationship for the=20 > directionality between the e2e LSP and the LSP segment that=20 > can be retrieved with the procedure described in section=20 > 4.2.4 - and so the first question is it worth allowing this?) > >=20 > > > > > > Also the selection of the LSP segment in case of=20 > bidirectional LSP=20 > > > > should be detailed (e.g. If the end-to-end LSP is > > > bidirecitonal then > > > > the LSP-segment MUST be bidirectional. Also shall we allow that=20 > > > > two unidrectional end-to-end LSP use the same bidirectional LSP=20 > > > > segment (one in each direction)? > > > AA----> Yes, this should be okay. IMO. > > > > > > > -At the end of section 4.2.5 you mention that LSP-Segment > > > failure or > > > > maintenance SHOULD be treated as a failure event for the > > > end-to-end LSP. > > > > I agree for LSP-Segment failure but not for LSP-Segment=20 > maintenance. > > > > LSP-Segment maintenance should be treated as TE-link > > > maintenance for > > > > the end-to-end LSP, and procedures defined in GMPLS > > > graceful TE-link > > > > shutdown draft may be useful (Specific RSVP error code=20 > and TE-link=20 > > > > attribute)... > > > AA---> Yes, I agree; we will mention this. Actually the graceful=20 > > > AA---> teardown > > > sentence occurs few paragraphs before, but not in the=20 > right context.=20 > > > So we will clarify the above. > > > > > > DP: i am not sure to understand the comment, the sentence=20 > speaks about > deletion of the LSP segment due to failure/maintenance should=20 > be treated as a failure event for the e2e LSP, so i don't=20 > think the initial sentence was meant to translated the=20 > initial comment, anyway it would be of interest that you=20 > detail the error code > > > > DP: note also that section 4.2.5 indicates that for stitched LSPs > Graceful deletion can be used - i perfectly agree - but the=20 > sequence should be detailed as part of this section > >=20 > > > > > > Hope this helps, > > > AA---> Sure does. > > > > > > > > > Thanks! > > > > > > -arthi > > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > De : owner-ccamp@ops.ietf.org > > > > > [mailto:owner-ccamp@ops.ietf.org] De la part de=20 > > > > > Internet-Drafts@ietf.org Envoy=E9 : vendredi 15 juillet > > > 2005 21:50 =C0 : > > > > > i-d-announce@ietf.org Cc : ccamp@ops.ietf.org Objet : I-D=20 > > > > > ACTION:draft-ietf-ccamp-lsp-stitching-01.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=20 > Measurement=20 > > > > > Plane Working Group of the IETF. > > > > > > > > > > Title: Label Switched Path Stitching with Generalized MPLS=20 > > > > > Traffic Engineering > > > > > Author(s): A. Ayyangar, J. Vasseur > > > > > Filename: draft-ietf-ccamp-lsp-stitching-01.txt > > > > > Pages: 19 > > > > > Date: 2005-7-15 > > > > > > > > > > In certain scenarios, there may be a need to combine=20 > together two > > > > > 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 achieved 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=20 > 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 might be > > > possible to > > > > > configure a GMPLS node to switch the traffic from=20 > an LSP for=20 > > > > > which it > > > > > is the egress, to another LSP for which it is the > > > ingress, without > > > > > requiring any signaling or routing extensions whatsoever,=20 > > > > > completely > > > > > transparent to other nodes. This will also result in > > > LSP stitching > > > > > in the data plane. However, this document does=20 > not cover this > > > > > scenario of LSP stitching. > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitc > > > > hing-01.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.=20 > > > > > After logging in, type "cd internet-drafts" and then "get=20 > > > > > draft-ietf-ccamp-lsp-stitching-01.txt". > > > > > > > > > > A list of Internet-Drafts directories can be found in=20 > > > > > http://www.ietf.org/shadow.html or=20 > > > > > 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-01.txt". > > > > > > > > > > NOTE:The mail server at ietf.org can return the document in=20 > > > > > MIME-encoded form by using the "mpack" utility. To use this=20 > > > > > feature, insert the command "ENCODING mime" before the "FILE" > > > > > command. To decode the response(s), you will need=20 > "munpack" or=20 > > > > > a MIME-compliant mail reader. Different MIME-compliant mail=20 > > > > > readers exhibit different behavior, especially when=20 > dealing with=20 > > > > > "multipart" MIME messages (i.e. documents which have=20 > been split=20 > > > > > up into multiple messages), so check your local=20 > documentation on=20 > > > > > how to manipulate these messages. > > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant=20 > mail reader=20 > > > > > implementation to automatically retrieve the ASCII version of=20 > > > > > the Internet-Draft. > > > > > > > > > > > >=20 > > >=20 >=20