From owner-ccamp@ops.ietf.org Fri Apr 1 01:54:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28520 for ; Fri, 1 Apr 2005 01:54:17 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGA8-0004c7-E0 for ccamp-archive@ietf.org; Fri, 01 Apr 2005 02:01:49 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHFuz-0008mY-PF for ccamp-data@psg.com; Fri, 01 Apr 2005 06:46:09 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHFuy-0008mI-8D for ccamp@ops.ietf.org; Fri, 01 Apr 2005 06:46:08 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IE9001Q88ZZB5@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Thu, 31 Mar 2005 22:35:59 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IE9002K88ZYF9@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Thu, 31 Mar 2005 22:35:59 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Fri, 01 Apr 2005 14:39:53 +0800 Date: Fri, 01 Apr 2005 14:39:53 +0800 From: Amit 70405 Subject: Regarding Reversion To: ccamp@ops.ietf.org Message-id: <124f55b1251c82.1251c82124f55b@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_B4a7zVEkxT2be3Jwn1kIVg)" Content-language: en X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb This is a multi-part message in MIME format. --Boundary_(ID_B4a7zVEkxT2be3Jwn1kIVg) Content-type: message/rfc822 Content-disposition: inline Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Fri, 01 Apr 2005 14:28:44 +0800 Date: Fri, 01 Apr 2005 14:28:44 +0800 From: Amit 70405 Subject: Regarding Reversion To: bala.rajagopalan@intel.com, dimitri.papadimitriou@alcatel.be Cc: ccamp@ietf.org Message-id: <124d788124f2ff.124f2ff124d788@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal Content-Transfer-Encoding: 7BIT Hi, In the draft draft-ietf-ccamp-gmpls-recovery-functional-04.txt, in the section about Reversion. It is said: "Reversion implies that a working path remains allocated to the LSP that was originally routed over it even after a failure." This requirement may hold true for non-PSC networks, and may not be required in PSC. How can RSVP support this?? I mean it may totally violate RSVP-TE standard. As though the failure has happened and LSP should not be deleted. Plz let me know your view on this. Regards, Amit. --Boundary_(ID_B4a7zVEkxT2be3Jwn1kIVg)-- From owner-ccamp@ops.ietf.org Fri Apr 1 04:32:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05943 for ; Fri, 1 Apr 2005 04:32:45 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHIdX-0001vy-5Z for ccamp-archive@ietf.org; Fri, 01 Apr 2005 04:40:19 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHIP8-0001gc-AV for ccamp-data@psg.com; Fri, 01 Apr 2005 09:25:26 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHIP4-0001fu-7Z for ccamp@ops.ietf.org; Fri, 01 Apr 2005 09:25:22 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j319Oj9B010454; Fri, 1 Apr 2005 11:24:46 +0200 To: Amit 70405 Cc: ccamp@ops.ietf.org MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Regarding Reversion Date: Fri, 1 Apr 2005 11:24:44 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 04/01/2005 11:24:46 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_20_30, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_BASE64_TEXT,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 4.8 (++++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmhpIC0gd291bGQgeW91IHBsZWFzZSBj bGFyaWZ5IHlvdXIgY29tbWVudCAtIHRvIHdoaWNoIHBvdGVudGlhbCB2aW9sYXRpb24gZG8geW91 IHJlZmVyID8gaW4gcGFydGljdWxhciB0aGlzIHNwZWNpZmljYXRpb24gYmVpbmcgZnVuY3Rpb25h bCBzcGVjaWZpYyBkZXRhaWxzIGNvbmNlcm5pbmcgcmVhbGl6YXRpb24gdXNpbmcgUlNWUCBhcmUg cHJvdmlkZWQgaW4gdGhlIGVuZC10by1lbmQgc2lnbmFsaW5nIGRvY3VtZW50PEJSPjwvRk9OVD48 QlI+PEZPTlQgU0laRT0yPjxCPkFtaXQgNzA0MDUgJmx0O0FtaXRHQGh1YXdlaS5jb20mZ3Q7PC9C PjwvRk9OVD48QlI+PEZPTlQgU0laRT0yPlNlbnQgYnk6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9y ZzwvRk9OVD48QlI+PEZPTlQgU0laRT0yPjA0LzAxLzIwMDUgMTQ6MzkgWkU4PC9GT05UPjxCUj48 QlI+IDxGT05UIFNJWkU9Mj5Ubzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5jY2FtcEBvcHMuaWV0Zi5v cmc8L0ZPTlQ+PEJSPiA8Rk9OVCBTSVpFPTI+Y2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5i Y2M6PC9GT05UPiA8QlI+IDxGT05UIFNJWkU9Mj5TdWJqZWN0OjwvRk9OVD4gPEZPTlQgU0laRT0y PlJlZ2FyZGluZyBSZXZlcnNpb248L0ZPTlQ+PEJSPiA8QlI+PEJSPjwvUD48UD48Rk9OVCBGQUNF PSJNb25vc3BhY2UsQ291cmllciI+Q29udGVudC10cmFuc2Zlci1lbmNvZGluZzogN0JJVDxCUj5S ZWNlaXZlZDogZnJvbSBbMTcyLjI0LjEuM10gKEZvcndhcmRlZC1Gb3I6IFsxMC43OC4yMzAuMTYz XSkgYnkgc3p4bWMwMi1pbi5odWF3ZWkuY29tIChtc2h0dHBkKTsgRnJpLCAwMSBBcHIgMjAwNSAx NDoyODo0NCArMDgwMDxCUj5EYXRlOiBGcmksIDAxIEFwciAyMDA1IDE0OjI4OjQ0ICswODAwPEJS PkZyb206IEFtaXQgNzA0MDUgJmx0O0FtaXRHQGh1YXdlaS5jb20mZ3Q7PEJSPlN1YmplY3Q6IFJl Z2FyZGluZyBSZXZlcnNpb248QlI+VG86IGJhbGEucmFqYWdvcGFsYW5AaW50ZWwuY29tLCBkaW1p dHJpLnBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTxCUj5DYzogY2NhbXBAaWV0Zi5vcmc8QlI+TWVz c2FnZS1pZDogJmx0OzEyNGQ3ODgxMjRmMmZmLjEyNGYyZmYxMjRkNzg4QGh1YXdlaS5jb20mZ3Q7 PEJSPk1JTUUtdmVyc2lvbjogMS4wPEJSPlgtTWFpbGVyOiBpUGxhbmV0IE1lc3NlbmdlciBFeHBy ZXNzIDUuMiBIb3RGaXggMS4yNSAoYnVpbHQgTWFyICZuYnNwOzMgMjAwNCk8QlI+Q29udGVudC10 eXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXVzLWFzY2lpPEJSPkNvbnRlbnQtbGFuZ3VhZ2U6IGVu PEJSPkNvbnRlbnQtZGlzcG9zaXRpb246IGlubGluZTxCUj5YLUFjY2VwdC1MYW5ndWFnZTogZW48 QlI+UHJpb3JpdHk6IG5vcm1hbDwvRk9OVD48QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD b3VyaWVyIj5IaSw8QlI+SW4gdGhlIGRyYWZ0IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtcmVjb3Zl cnktZnVuY3Rpb25hbC0wNC50eHQsIGluIHRoZSBzZWN0aW9uIGFib3V0IFJldmVyc2lvbi48L0ZP TlQ+PEJSPjwvUD48VUw+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkl0IGlzIHNhaWQ6 PEJSPiZxdW90O1JldmVyc2lvbiBpbXBsaWVzIHRoYXQgYSB3b3JraW5nIHBhdGggcmVtYWlucyBh bGxvY2F0ZWQgdG8gdGhlIExTUCB0aGF0PEJSPndhcyBvcmlnaW5hbGx5IHJvdXRlZCBvdmVyIGl0 IGV2ZW4gYWZ0ZXIgYSBmYWlsdXJlLiZxdW90OzwvRk9OVD48QlI+PEJSPjxGT05UIEZBQ0U9Ik1v bm9zcGFjZSxDb3VyaWVyIj5UaGlzIHJlcXVpcmVtZW50IG1heSBob2xkIHRydWUgZm9yIG5vbi1Q U0MgbmV0d29ya3MsIGFuZCBtYXkgbm90IGJlIHJlcXVpcmVkIGluIFBTQy48QlI+SG93IGNhbiBS U1ZQIHN1cHBvcnQgdGhpcz8/IEkgbWVhbiBpdCBtYXkgdG90YWxseSB2aW9sYXRlIFJTVlAtVEUg c3RhbmRhcmQuPEJSPkFzIHRob3VnaCB0aGUgZmFpbHVyZSBoYXMgaGFwcGVuZWQgYW5kIExTUCBz aG91bGQgbm90IGJlIGRlbGV0ZWQuPC9GT05UPjxCUj48L1VMPjxQPjxGT05UIEZBQ0U9Ik1vbm9z cGFjZSxDb3VyaWVyIj5QbHogbGV0IG1lIGtub3cgeW91ciB2aWV3IG9uIHRoaXMuPEJSPlJlZ2Fy ZHMsPEJSPkFtaXQuPEJSPjwvRk9OVD48L1A+ From owner-ccamp@ops.ietf.org Fri Apr 1 06:06:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12260 for ; Fri, 1 Apr 2005 06:06:44 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHK6T-00056v-Vz for ccamp-archive@ietf.org; Fri, 01 Apr 2005 06:14:20 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHJt7-000Ex9-8N for ccamp-data@psg.com; Fri, 01 Apr 2005 11:00:29 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHJqD-000ERT-BF for ccamp@ops.ietf.org; Fri, 01 Apr 2005 11:00:28 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IE9001E2HVKB5@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Fri, 01 Apr 2005 01:47:44 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IE90023MHVIF9@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Fri, 01 Apr 2005 01:47:44 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Fri, 01 Apr 2005 17:51:36 +0800 Date: Fri, 01 Apr 2005 17:51:36 +0800 From: Amit 70405 Subject: Re: Regarding Reversion To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org Message-id: <126ce3a126e473.126e473126ce3a@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_CRUud2oPw4CxSDSYO22eYw)" Content-language: en X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_50,UPPERCASE_25_50 autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 This is a multi-part message in MIME format. --Boundary_(ID_CRUud2oPw4CxSDSYO22eYw) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT Hi, Thanks for replying. According to the statement I mentioned from the draft, I understand that, if there is a failure the old working LSP should not be deleted. But not only for RSVP, for any MPLS Signaling protocol, it is mandatory that when a failure happens, you should start tearing down the LSP. Take for instance if a OutInterface(on which LSP is setup) goes down. Protocol will lead to LSP deletion. Plz correct me if I am wrong. Regards, Amit. --Boundary_(ID_CRUud2oPw4CxSDSYO22eYw) Content-type: message/rfc822 Content-disposition: inline MIME-version: 1.0 Content-type: TEXT/PLAIN Content-Transfer-Encoding: QUOTED-PRINTABLE =B6=1A+=8B7=9D=C9=EB=17J=96=A6 =17=9C=91=EA=D5z=BB"=A2t=A9j`,=B1=AB,=8A}=F4=D7m4=E3]6=DA=89=E9=B2= =07(=99t=A9jb=DE=BD=E9WJ=96=A6J=D6=AD=BA=C3h=B1=CA+{_=AD=EA=AE=8A= =B7=9D=E7Kz=CBl=01b=04=06=04KM=07L=C2=F6=D3}=07L=C2=CC=11$=80=18A= =D30=B3=080CN=1D3=0BL=01=8C =C1=01=01!:=E11=17L=C2=0C=10t=CC,=E3K`= =D3=91=10=02=CD=00=C1=1A=BA=DA%y=AA=E7=9E=8Bz=BB"=A2}=D3S=C5=03=E3= =C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E6=86= =92=02=D2=07v=F7V=C6B=07=96=F7R=07=06=C6V=176R=066=C6=17&=96g=92=07= =96=F7W"=066=F6=D6=D6V=E7B=02=D2=07F=F2=07v=86=966=82=07=06=F7FV=E7F= =96=16=C2=07f=96=F6=C6=17F=96=F6=E2=06F=F2=07=96=F7R=07&VfW"=03=F2= =06=96=E2=07=06=17'F=967V=C6=17"=07F=86=972=077=06V6=96f=966=17F=96= =F6=E2=06&V=96=E6r=06gV=E67F=96=F6=E6=16=C2=077=06V6=96f=962=06FWF= =16=96=C72=066=F6=E66W&=E6=96=E6r=07&V=16=C6=97=A6=17F=96=F6=E2=07W6= =96=E6r=05%5e=02=06=17&R=07=07&=F7f=96FVB=06=96=E2=07F=86R=06V=E6B= =D7F=F2=D6V=E6B=076=96v=E6=16=C6=96=E6r=06F=F67V=D6V=E7C=C4%#=E3=C2= =F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=054=95=A4S=D3#=E3=C4#=E4=16=D6=97B= =03s=03C=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=92=E66=F6=D2fwC=B3= =C2=F4#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=054=95=A4S=D3#=E56V= =E7B=06'=93=A2=06=F7v=E6W"=D666=16=D7=04=06=F7=072=E6=96WFb=E6=F7&s= =C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=054=95=A4S=D3#=E3=03B=F3=03=12= =F3#=03=03R=03=13C=A33=92=05=A4S=83=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#= =E2=03=C4d=F4=E5B=054=95=A4S=D3#=E5F=F3=A3=C2=F4d=F4=E5C=E2=03=C4d= =F4=E5B=054=95=A4S=D3#=E666=16=D7=04=06=F7=072=E6=96WFb=E6=F7&s=C2= =F4d=F4=E5C=E3=C4%#=E2=03=C4d=F4=E5B=054=95=A4S=D3#=E663=A3=C2=F4d= =F4=E5C=E2=03=C4%#=E2=03=C4d=F4=E5B=054=95=A4S=D3#=E6&63=A3=C2=F4d= =F4=E5C=E2=03=C4%#=E2=03=C4d=F4=E5B=054=95=A4S=D3#=E57V&=A6V7C=A3= =C2=F4d=F4=E5C=E2=03=C4d=F4=E5B=054=95=A4S=D3#=E5&Vv=17&F=96=E6r=05&W= fW'6=96=F6=E3=C2=F4d=F4=E5C=E3=C4%#=E2=03=C4%#=E3=C4%#=E3=C2=F5=03= =E3=C5=03=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&= =96W"#=E46=F6=E7FV=E7B=D7G&=16=E76fW"=D6V=E66=F6F=96=E6s=A2=03t$=95C= =C4%#=E5&V6V=97fVC=A2=06g&=F6=D2=05=B3=13s"=E3#B=E3=12=E35=D2=02=84f= =F7'v=17&FVB=D4f=F7#=A2=05=B3=13=02=E3s=82=E3#3=02=E3=13c5=D2=92=06'= =92=077=A7=86=D63=03"=D6=96=E2=E6=87V=17vV=92=E66=F6=D2=02=86=D76= =87GG=06B=93=B2=04g&=92=C2=03=03=12=04=17=07"=03#=03=03R=03=13C=A3#= =83=A3CB=02=B3=03=83=03=03=C4%#=E4F=17FS=A2=04g& =C2=03=03=12=04=17=07"=03#=03=03R=03=13C=A3#=83=A3CB=02=B3=03=83=03= =03=C4%#=E4g&=F6=D3=A2=04=16=D6=97B=03s=03C=03R=02f=C7C=B4=16=D6=97Dt= =06=87V=17vV=92=E66=F6=D2fwC=B3=C4%#=E57V&=A6V7C=A2=05&Vv=17&F=96= =E6r=05&WfW'6=96=F6=E3=C4%#=E5F=F3=A2=06&=16=C6=12=E7&=16=A6=16v=F7= =06=16=C6=16=E4=06=96=E7FV=C2=E66=F6=D2=C2=06F=96=D6=97G&=92=E7=06= =17=06=16F=96=D6=97G&=96=F7T=06=16=C66=17FV=C2=E6&S=C4%#=E463=A2=0666= =16=D7=04=06=96WFb=E6=F7&s=C4%#=E4=D6W76=16vR=D6=96C=A2=02f=C7C=B3= =13#FCs=83=83=13#Fc&fb=E3=13#Fc&fc=13#FCs=83=84=06=87V=17vV=92=E66= =F6=D2fwC=B3=C4%#=E4=D4=94=D4R=D7fW'6=96=F6=E3=A2=03=12=E3=03=C4%#= =E5=82=D4=D6=16=96=C6W#=A2=06=95=06=C6=16=E6WB=04=D6W76V=E6vW"=04W= =87=07&W72=03R=E3"=04=86=F7Df=97=82=03=12=E3#R=02=86'V=96=C7B=04=D6= =17"=02f=E6'7=03=B32=03#=03=03B=93=C4%#=E46=F6=E7FV=E7B=D7G=97=06S= =A2=07FW=87B=F7=06=C6=16=96=E3=B2=066=86=17'6WC=D7W2=D6=1766=96=93= =C4%#=E46=F6=E7FV=E7B=D6=C6=16=E6wV=16vS=A2=06V=E3=C4%#=E46=F6=E7FV= =E7B=D6F=977=06=F76=97F=96=F6=E3=A2=06=96=E6=C6=96=E6S=C4%#=E5=82= =D4=1666W=07B=D4=C6=16=E6wV=16vS=A2=06V=E3=C4%#=E5=07&=96=F7&=97G= =93=A2=06=E6=F7&=D6=16=C3=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#=E3=C4d=F4= =E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=86=92=C3= =C4%#=E4=96=E2=07F=86R=06G&=16gB=06G&=16gB=D6=96WFb=D666=16=D7=02= =D6v=D7=06=C72=D7&V6=F7fW'=92=D6gV=E67F=96=F6=E6=16=C2=D3=03B=E7G= =87B=C2=06=96=E2=07F=86R=076V7F=96=F6=E2=06=16&=F7WB=05&WfW'6=96=F6= =E2=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C2=F5=03=E3=C5T=C3=E3=C4d=F4=E5B=04d= =144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=97B=06=972=076=16= =96C=A3=C4%#=E2g=17V=F7C=B5&WfW'6=96=F6=E2=06=96=D7=06=C6=96W2=07F= =86=17B=06=12=07v=F7&=B6=96=E6r=07=06=17F=82=07&V=D6=16=96=E72=06= =16=C6=C6=F66=17FVB=07F=F2=07F=86R=04=C55=02=07F=86=17C=C4%#=E7v=172= =06=F7&=96v=96=E6=16=C6=C7=92=07&=F7WFVB=06=F7fW"=06=97B=06WfV=E2= =06=16gFW"=06=12=06f=16=96=C7W&R=E2g=17V=F7C=B3=C2=F4d=F4=E5C=E3=C4%#= =E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&= =96W"#=E5F=86=972=07&W=17V=97&V=D6V=E7B=06=D6=17=92=06=86=F6=C6B=07G'= VR=06f=F7"=06=E6=F6=E2=D5=0542=06=E6WGv=F7&=B72=C2=06=16=E6B=06=D6= =17=92=06=E6=F7B=06&R=07&W=17V=97&VB=06=96=E2=05=0542=E3=C4%#=E4=86= =F7r=066=16=E2=05%5e=02=077W=07=06=F7'B=07F=86=973=F3=F2=04=92=06= =D6V =E2=06=97B=06=D6=17=92=07F=F7F=16=C6=C7=92=07f=96=F6=C6=17FR=05%5e= =02=D5DR=077F=16=E6F=17&B=E3=C4%#=E4=172=07F=86=F7Vv=82=07F=86R=06f= =16=96=C7W&R=06=86=172=06=86=17=07=06V=E6VB=06=16=E6B=04=C55=02=076= =86=F7V=C6B=06=E6=F7B=06&R=06FV=C6WFVB=E3=C2=F4d=F4=E5C=E3=C4%#=E3= =C2=F5T=C3=E3=C5=03=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R= =C46=F7W&=96W"#=E5=06=C7=A2=06=C6WB=06=D6R=06=B6=E6=F7r=07=96=F7W"= =07f=96Wr=06=F6=E2=07F=86=972=E3=C4%#=E5&Vv=17&G2=C3=C4%#=E4=16=D6= =97B=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C2=F5 --Boundary_(ID_CRUud2oPw4CxSDSYO22eYw)-- From owner-ccamp@ops.ietf.org Fri Apr 1 06:58:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16334 for ; Fri, 1 Apr 2005 06:58:44 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHKuq-0006w6-BW for ccamp-archive@ietf.org; Fri, 01 Apr 2005 07:06:20 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHKi8-000MUq-7z for ccamp-data@psg.com; Fri, 01 Apr 2005 11:53:12 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHKi4-000MUG-9Z for ccamp@ops.ietf.org; Fri, 01 Apr 2005 11:53:08 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j31Bpo9B013500; Fri, 1 Apr 2005 13:51:50 +0200 To: Amit 70405 Cc: Dimitri.Papadimitriou@alcatel.be, ccamp@ops.ietf.org MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Regarding Reversion Date: Fri, 1 Apr 2005 13:51:49 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 04/01/2005 13:51:50 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_20,HTML_40_50, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_BASE64_TEXT,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 4.8 (++++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: base64 PFA+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPmFtaXQsIHVwb24gZGF0YSBwbGFuZSBm YWlsdXJlIHRoZXJlIGlzIG5vIHN1Y2ggYmVoYXZpb3VyIGFzIHlvdSBtZW50aW9uIC0gbG9jYWwg ZGF0YSBwbGFuZSBmYWlsdXJlIGRldGVjdGlvbiBkb2VzIG5vdCBpbXBseSBzdGF0ZSBkZWxldGlv biBhbmQgY29tbW9uIFBhdGhFcnIvUmVzdkVyciBkbyBub3QgdHJpZ2dlciBhbnkgc3RhdGUgZGVs ZXRpb24gbm9yIGRvZXMgYSBOb3RpZnk7IGluIHBhcnRpY3VsYXIsIGluIHRoZSBwcmVzZW50IGNv bnRleHQgd2hlcmUgb25lIGRvIGFzc3VtZSBjb250cm9sIHBsYW5lIGF2YWlsYWJpbGl0eSBldmVu IGluIGNhc2Ugb2YgZGF0YSBwbGFuZSBmYWlsdXJlIC0gbm90ZTogZGV0YWlscyBvZiBpdCBhdmFp bGFibGUgaW4gb3RoZXIgZG9jdW1lbnRzIC0gc3RhdGVzIGNhbiBiZSBrZXB0IHJlZnJlc2hlZDwv Rk9OVD48QlI+PEJSPjxGT05UIFNJWkU9Mj48Qj5BbWl0IDcwNDA1ICZsdDtBbWl0R0BodWF3ZWku Y29tJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBv cHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05UIFNJWkU9Mj4wNC8wMS8yMDA1IDE3OjUxIFpFODwv Rk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+RGltaXRy aSBQQVBBRElNSVRSSU9VL0JFL0FMQ0FURUxAQUxDQVRFTDwvRk9OVD48QlI+IDxGT05UIFNJWkU9 Mj5jYzo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPiA8 Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+ IDxGT05UIFNJWkU9Mj5SZTogUmVnYXJkaW5nIFJldmVyc2lvbjwvRk9OVD48QlI+IDxCUj48QlI+ PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5IaSw8QlI+VGhhbmtzIGZvciBy ZXBseWluZy48L0ZPTlQ+PEJSPjwvUD48VUw+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi PkFjY29yZGluZyB0byB0aGUgc3RhdGVtZW50IEkgbWVudGlvbmVkIGZyb20gdGhlIGRyYWZ0LCBJ IHVuZGVyc3RhbmQgdGhhdCwgaWYgdGhlcmUgaXMgYSBmYWlsdXJlIHRoZSBvbGQgd29ya2luZyBM U1Agc2hvdWxkIG5vdCBiZSBkZWxldGVkLjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9z cGFjZSxDb3VyaWVyIj5CdXQgbm90IG9ubHkgZm9yIFJTVlAsIGZvciBhbnkgTVBMUyBTaWduYWxp bmcgcHJvdG9jb2wsIGl0IGlzIG1hbmRhdG9yeSB0aGF0IHdoZW4gYSBmYWlsdXJlIGhhcHBlbnMs IHlvdSBzaG91bGQgc3RhcnQgdGVhcmluZyBkb3duIHRoZSBMU1AuPEJSPjwvRk9OVD48QlI+PEZP TlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlRha2UgZm9yIGluc3RhbmNlIGlmIGEgT3V0SW50 ZXJmYWNlKG9uIHdoaWNoIExTUCBpcyBzZXR1cCkgZ29lcyBkb3duLjxCUj5Qcm90b2NvbCB3aWxs IGxlYWQgdG8gTFNQIGRlbGV0aW9uLjwvRk9OVD48QlI+PC9VTD48UD48Rk9OVCBGQUNFPSJNb25v c3BhY2UsQ291cmllciI+UGx6IGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy48QlI+UmVnYXJkcyw8 QlI+QW1pdC48QlI+PC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIi PkNvbnRlbnQtdHJhbnNmZXItZW5jb2Rpbmc6IFFVT1RFRC1QUklOVEFCTEU8QlI+TUlNRS12ZXJz aW9uOiAxLjA8QlI+Q29udGVudC10eXBlOiBURVhUL1BMQUlOPC9GT05UPjxCUj48QlI+PEZPTlQg RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPiZwYXJhOxorJzcmIzYzNjQwOyZFYWN1dGU7JmV1bWw7 F0qWJmJydmJhcjs8QlI+F5wnJmVjaXJjOyZPdGlsZGU7eiZyYXF1bzsmcXVvdDsmY2VudDt0JmNv cHk7amAsJnBsdXNtbjsmbGFxdW87LIp9Jm9jaXJjOyZ0aW1lczttNCZhdGlsZGU7XTYmVWFjdXRl O4kmZWFjdXRlOyZzdXAyOwcomXQmY29weTtqYiZUSE9STjsmZnJhYzEyOyZlYWN1dGU7V0qWJmJy dmJhcjtKJk91bWw7JnNoeTsmb3JkbTsmQXRpbGRlO2gmcGx1c21uOyZFY2lyYzsre18mc2h5OyZl Y2lyYzsmcmVnO4ombWlkZG90OyYjNjM2NDA7JmNjZWRpbDtLeiZFdW1sO2wBYgQGBEtNB0wmQWNp cmM7Jm91bWw7Jk9hY3V0ZTt9B0wmQWNpcmM7JklncmF2ZTsRJIAYQSZPYWN1dGU7MCZzdXAzOwgw Q04dMwtMAYwgJkFhY3V0ZTsBASE6JmFhY3V0ZTsxF0wmQWNpcmM7DBB0JklncmF2ZTssJmF0aWxk ZTtLYCZPYWN1dGU7JxACJklhY3V0ZTs8QlI+JkFjaXJjOzxCUj48QlI+EgQXByZxdW90OzxCUj4j PEJSPjxCUj5SPEJSPhNDJnBvdW5kOyODJnBvdW5kO0NCAiZzdXAzOzxCUj6DPEJSPjxCUj4mQXVt bDslIyZhdW1sO2cmYW1wOyZvdW1sOyZPYWN1dGU7JmNlbnQ7BBYmT3VtbDuXQjxCUj5zPEJSPkM8 QlI+UgJmJkNjZWRpbDtDJmFjdXRlOxYmT3VtbDuXRHQGh1YXdlYnJmFlbGlnOzYmb3VtbDsmT2dy YXZlO2Z3QyZzdXAzOyZBdW1sOyUjJmFyaW5nOzdWJmFtcDsmYnJ2YmFyO1Y3QyZjZW50OwUmYW1w O1Z2FyZhbXA7RpYmYWVsaWc7cgUmYW1wO1dmVyc2liZvdW1sOyZhdGlsZGU7JkF1bWw7JSMmYXJp bmc7RiZvYWN1dGU7JmNlbnQ7BiZhbXA7FiZBRWxpZzsSJmNjZWRpbDsmYW1wOxYmYnJ2YmFyOxZ2 JmRpdmlkZTsGFiZBRWxpZzsWJmF1bWw7BpYmY2NlZGlsO0ZWJkFjaXJjOyZhZWxpZzs2Jm91bWw7 Jk9ncmF2ZTsmQWNpcmM7BkaWJk91bWw7l0cmYW1wOycmY2NlZGlsOwYXBhZGliZPdW1sO5dHJmFt cDuWJmRpdmlkZTtUBhYmQUVsaWc7NhdGViZBY2lyYzsmYWVsaWc7JmFtcDtTJkF1bWw7JSMmYXVt bDs2MyZjZW50OwY2NhYmdGltZXM7BAaWV0ZiJmFlbGlnOyZkaXZpZGU7JmFtcDtzJkF1bWw7JSMm YXVtbDsmT3VtbDtXNzYWdlImT3VtbDuWQyZjZW50OwJmJkNjZWRpbDtDJnN1cDM7EyNGQ3ODgxMj RmMmYW1wO2ZiJmF0aWxkZTsTI0ZjJmFtcDtmYxMjRkNzgzwvRk9OVD48L1A+ From owner-ccamp@ops.ietf.org Fri Apr 1 08:09:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22174 for ; Fri, 1 Apr 2005 08:09:22 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHM1B-0001Dy-6g for ccamp-archive@ietf.org; Fri, 01 Apr 2005 08:17:00 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHLnN-0007UP-3E for ccamp-data@psg.com; Fri, 01 Apr 2005 13:02:41 +0000 Received: from [192.128.166.71] (helo=almso2.proxy.att.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHLnM-0007T9-4m for ccamp@ops.ietf.org; Fri, 01 Apr 2005 13:02:40 +0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j31D2WSg015696 for ; Fri, 1 Apr 2005 08:02:38 -0500 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (7.2.052) id 423DAD7E00240B6B; Fri, 1 Apr 2005 08:02:38 -0500 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.0.6603.0 Subject: RE: WG last calls Date: Fri, 1 Apr 2005 07:02:38 -0600 Message-ID: <9473683187ADC049A855ED2DA739ABCA060CE50E@KCCLUST06EVS1.ugd.att.com> Thread-Topic: WG last calls Thread-Index: AcU2bDu83poEj13ARbOnsTEGcvqTrQATUvcQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Zhang Renhai" , "Adrian Farrel" , , "Kireeti Kompella" Cc: "Ash, Gerald R \(Jerry\), ALABS" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Zhang, > From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the > number of crankback rerouting is limited, so there will > be a result: there is another LSP,but for the reason of > limiting, the path may be not found. I think sometimes > it is unacceptable.The LSP may be prefered to enhancing > performance. This problem can be avoided by the setting the node retry threshold (configurable per node) very high (~infinity), so retries aren't limited. Thanks, Jerry From owner-ccamp@ops.ietf.org Fri Apr 1 12:11:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16120 for ; Fri, 1 Apr 2005 12:11:41 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHPnj-0002Uj-7K for ccamp-archive@ietf.org; Fri, 01 Apr 2005 12:19:20 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHPXM-000I2C-8P for ccamp-data@psg.com; Fri, 01 Apr 2005 17:02:24 +0000 Received: from [66.129.224.36] (helo=kummer.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DHPXL-000I1u-Go for ccamp@ops.ietf.org; Fri, 01 Apr 2005 17:02:23 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j31H2MXg088376 for ; Fri, 1 Apr 2005 09:02:22 -0800 (PST) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j31H2MRt088373 for ; Fri, 1 Apr 2005 09:02:22 -0800 (PST) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 1 Apr 2005 09:02:22 -0800 (PST) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: WG last calls In-Reply-To: <20050331073357.R83270@kummer.juniper.net> Message-ID: <20050401085445.F88331@kummer.juniper.net> References: <20050331073357.R83270@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On Thu, 31 Mar 2005, Kireeti Kompella wrote: > This is to initiate CCAMP WG last calls on: > > draft-ietf-ccamp-crankback-04.txt While this document is well-written and fairly comprehensive, it is missing an important section. While it has been claimed that the moral pedigree of the editor places his writings beyond question, the said editor is also a WG chair, and as such MUST set an example, good or otherwise. So, this document will not be progressed until an appropriate Morality Considerations section, complete with subsections as specified by RFC 4041, has been added. Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Apr 1 15:30:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07181 for ; Fri, 1 Apr 2005 15:30:47 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHSuS-000255-OZ for ccamp-archive@ietf.org; Fri, 01 Apr 2005 15:38:30 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHSef-000KXO-SN for ccamp-data@psg.com; Fri, 01 Apr 2005 20:22:09 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHSee-000KXB-RS for ccamp@ops.ietf.org; Fri, 01 Apr 2005 20:22:09 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05412; Fri, 1 Apr 2005 15:22:04 -0500 (EST) Message-Id: <200504012022.PAA05412@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-stitching-00.txt Date: Fri, 01 Apr 2005 15:22:03 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) 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.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Label Switched Path Stitching with Generalized MPLS Traffic Engineering Author(s) : A. Ayyangar, J. Vasseur Filename : draft-ietf-ccamp-lsp-stitching-00.txt Pages : 17 Date : 2005-4-1 In certain scenarios, there may be a need to combine 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 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 an LSP for which it is the egress, to another LSP for which it is the ingress, without requiring any signaling or routing extensions whatsoever, completely transparent to other nodes. This will also result in LSP stitching in the data plane. However, this document does not cover this scenario of LSP stitching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-stitching-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-ietf-ccamp-lsp-stitching-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-1154911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lsp-stitching-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lsp-stitching-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-1154911.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Sat Apr 2 12:35:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07848 for ; Sat, 2 Apr 2005 12:35:59 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHmf1-0002Vp-Nh for ccamp-archive@ietf.org; Sat, 02 Apr 2005 12:43:52 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHmNM-0008aK-Q0 for ccamp-data@psg.com; Sat, 02 Apr 2005 17:25:36 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHmNL-0008ZT-6a; Sat, 02 Apr 2005 17:25:35 +0000 Message-ID: <424ED58B.6010007@psg.com> Date: Sat, 02 Apr 2005 19:25:31 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: adrian@olddog.co.uk CC: Kireeti Kompella , ccamp@ops.ietf.org, a-iwata@ah.jp.nec.com, n-fujita@bk.jp.nec.com, gash@att.com, kuvempu@yahoo.com Subject: Re: WG last calls - comments on crankback i-d References: <20050331073357.R83270@kummer.juniper.net> In-Reply-To: <20050331073357.R83270@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Content-Transfer-Encoding: 7bit hi adrian, some coments here below technical --------- 1. section 2.1 it seems from phrasing the term QoS is used in two different ways "Using RSVP-TE, resources can also be reserved along a path to guarantee or control QoS for traffic carried on the LSP" thus last part of this sentence refers to the traffic oriented approach (as detailed in RFC 2702) but after in this section (and in section 4.2) the term "QoS constraints" is used in a resource oriented perspective; 2. section 2.2 " The requirement for end-to-end allocation of lambda resources in GMPLS networks without wavelength converters means that end-to-end restoration is the only way to recover LSP failures. " -> would it be possible to know how you came to this statement ? 3. section 3. i may have missed it but the definition of "Explicit and Implicit Re-routing Indications" is not provided 4. section 4.2.1 not sure to see why the "reason" of the failure is important beside link, label, etc. (in particular since the persistence is limited to the LSP under establishmnet) - but i guess it depends on the semantic you put behind this word in the present context - also by context you mean "position" of the element under failure wrt to its sequence as part of the ERO ? 5. section 4.4 is it " error indication upstream" or indicationS (collection) ? 6. section 5.2 "The Notify message may be used to expedite the propagation of error notifications, but in a network that offers crankback routing at multiple nodes there would need to be some agreement between LSRs as to whether PathErr or Notify provides the stimulus for crankback operation. " this agreement is constrained by the re-routing behavior selection (as listed in section 6.4 7. section 6.4 point 2 - why segment-based is referred to as "hierarchical" - do you refer to an "horizontal hierarchy" here ?) 8. section 7.2 not sure to understand the "Proposed ERO" TLV ? would it be possible to describe this more than "MAY supply suggestions about the ERO that could have been used to avoid the error." not sure to understand the "ERO_NEXT_CONTEXT" TLV " Link Identifiers: A sequence of TLVs as defined here of type 3 that indicate incoming interfaces at downstream nodes that have already participated in crankback attempts and have been declared unusable for the current LSP setup attempt." -> definition does not match the one proposed above in the text " For types 1, 2 and 3 the format of the Value field is already defined in [RFC3471]." 9. section 7.4.1 " As described in section 3, a node receiving crankback information in a PathErr must first check to see whether it is allowed to perform re-routing. This is indicated by the Re-routing Flags in the SESSION_ATTRIBUTE object during LSP setup request." -> why do you make use of the session attribute since section 6.4 mentions usage of lsp attribute object 10. section 7.3 in section 7.3.1 it is mentioned " If crankback is not being used but an IF-ID ERROR_SPEC object is included in a PathErr, ResvErr or Notify message, the sender SHOULD include one of the TLVs of type 1 through 3 as described in [RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described in [BUNDLE] and component links should be identified using the principles described in that document. A sender MAY include additional TLVs from the range 6 through 27 to report crankback information, although this information will at most only be used for logging." [...] "An LSR that proposes to perform crankback re-routing SHOULD support receipt and processing of all of the fundamental crankback TLVs, and is RECOMMENDED to support the receipt and processing of the additional crankback TLVs." in section 7.3.2 it is mentioned " Error Report TLVs are those in the range 1 through 3. (Note that the obsoleted TLVs 4 and 5 may be considered in this category, but SHOULD NOT be used.) As stated above, when crankback information is reported, the IF_ID ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is used, at least one of the TLVs in the range 1 through 3 MUST be present. The choice of which TLV to use will be dependent on the circumstance of the error and device capabilities. For example, a device that does not support IPv6 will not need the ability to create a TLV of type 2. Note, however, that such a device MUST still be prepared to receive and process all error report TLVs." in section 7.3.4 it is mentioned " It is left as an implementation detail precisely when to include each of the TLVs according to the capabilities of the system reporting the error." => would it be possible to harmonize these MUST, SHOULD, MAY, etc; ? one way to achieve this is by reducing repetitions and probably have 2 sub-sections instead of 4 same comment in section 7.4.5 where it is mentioned "When the node gives up it must propagate the failure message further upstream and include crankback information when it does so." 11. section 8. " For example, when an intermediate LSR issues a PathErr message, the signaling module of the intermediate LSR should interact with the routing logic to determine the routing-protocol-specific link or node ID where the blockage or fault occurred and carry this information onto the Link TLV and Node TLV inside the IF_ID ERROR_SPEC object." -> Link TLV is not defined as part of the table ? would it be possible to list to which TLV you are referring to 12. section 9.1 " In a network segmented into areas, the following procedures can be used. As explained in Section 8.2, the LSP restoration behavior is indicated in the Flags field of the SESSION_ATTRIBUTE object of the Path message. If the Flags indicate "End-to-end re-routing", the PathErr message is returned all the way back to the ingress LSR, which may then issue a new Path message along another path, which is the same procedure as in the flat network case above." -> why do you make use of the session attribute since section 6.4 mentions usage of lsp attribute object editorial --------- 1. title "Crankback Signaling Extensions for MPLS and GMPLS Signaling" is probably redundant i would suggest (but leave this at your discretion) "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE" 2. section 2.2 alignment with P&R terminology and concepts would be advisable 3. section 4.2 "On the other hand, in a network partitioned into areas such as with hierarchical OSPF,..." why "hierarchical OSPF" and not simply "OSPF" 4. section 5. - point 3) instead of "... (particularly in the GMPLS context)," i guess you mean for non-PSC LSP ? 5. section 7.2 "IF_ID PHOP" -> IF_ID RSVP_HOP ? 6. section 7.2 " Node Identifiers: A sequence of TLVs as defined here of types 1, 2 or 8 that indicates downstream nodes that have already participated in crankback attempts and have been declared unusable for the current LSP setup attempt." type 1, 2 does not define nodes in the proposed table ? 7. section 8 " The ingress LSR, upon receiving the error message, should interact with the routing logic to compute an alternate path by pruning the specified link ID or node ID in the routing database." i guess "node ID" refers to Router ID ? aslo do no provide the exact pointer for TE Router ID and Router ID in the IS-IS context hope this will help --- Kireeti Kompella wrote: > Hi, > > This is to initiate CCAMP WG last calls on: > > draft-ietf-ccamp-crankback-04.txt > > and > > draft-ietf-ccamp-rsvp-te-exclude-route-03.txt > > Please send your comments to the list (preferably) or to the authors > by April 14, 23:59 GMT (which is when the last calls end). > > Thanks, > Kireeti. > ------- > > > . > From owner-ccamp@ops.ietf.org Sat Apr 2 13:20:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10327 for ; Sat, 2 Apr 2005 13:20:38 -0500 (EST) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHnMG-0004G5-2H for ccamp-archive@ietf.org; Sat, 02 Apr 2005 13:28:32 -0500 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DHn7d-000EYS-Nb for ccamp-data@psg.com; Sat, 02 Apr 2005 18:13:25 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DHn7X-000EXl-7R for ccamp@ops.ietf.org; Sat, 02 Apr 2005 18:13:19 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 89E8CE000086; Sat, 2 Apr 2005 19:12:59 +0100 (BST) Received: from Puppy ([212.43.203.73] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 2 Apr 2005 19:12:57 +0100 Message-ID: <15e901c537af$d846cbd0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Ash, Gerald R (Jerry), ALABS" , "Zhang Renhai" , , "Kireeti Kompella" Cc: "Ash, Gerald R (Jerry), ALABS" References: <9473683187ADC049A855ED2DA739ABCA060CE50E@KCCLUST06EVS1.ugd.att.com> Subject: Re: WG last calls Date: Sat, 2 Apr 2005 18:05:17 +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 Apr 2005 18:12:58.0302 (UTC) FILETIME=[997085E0:01C537AF] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Hi, Yes, to clarify what Jerry says, the number of crankback attempts MAY be limited. At the moment, the only way that we provide to limit the attempts is implemented per LSR. That is, any LSR MAY decide that it has performed enough attempts at rerouting and pass the error back to the upstream LSR. Note that the use of crankback to derive a path through a network is not recommended. This approach is almost equivalent to random walk routing and is neither efficient nor effective. The use of crankback, as described in the draft is intended for use in specific circumstances, such as inter-domain routing. In these cases only selective LSRs (such as domain boundaries) perform rerouting attempts. Adrian ----- Original Message ----- From: "Ash, Gerald R (Jerry), ALABS" To: "Zhang Renhai" ; "Adrian Farrel" ; ; "Kireeti Kompella" Cc: "Ash, Gerald R (Jerry), ALABS" Sent: Friday, April 01, 2005 2:02 PM Subject: RE: WG last calls Zhang, > From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the > number of crankback rerouting is limited, so there will > be a result: there is another LSP,but for the reason of > limiting, the path may be not found. I think sometimes > it is unacceptable.The LSP may be prefered to enhancing > performance. This problem can be avoided by the setting the node retry threshold (configurable per node) very high (~infinity), so retries aren't limited. Thanks, Jerry From lindsay@access.com.au Sat Apr 2 20:49:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10229 for ; Sat, 2 Apr 2005 20:49:50 -0500 (EST) Received: from cvg-65-26-158-17.cinci.rr.com ([65.26.158.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHuMy-0003RW-3F for ccamp-archive@ietf.org; Sat, 02 Apr 2005 20:57:47 -0500 Message-ID: <453f01c537ed$9d81bb01$52bea637@access.com.au> From: "Vanessa J. Smith" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?UG9wdWxhciBzb2Z0IC0gNzUlIE9GRg==?= Date: Sun, 03 Apr 2005 01:33:14 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_24E5A431.737A0798" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 15.5 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_24E5A431.737A0798 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_7329478D.D7E2C772" ------=_NextPart_001_0001_7329478D.D7E2C772 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get all the popular software you need for unbelievably low prices! We sell software 2-6 times cheaper than retail price. Examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... To view full list of products go: http://www.oemunlimited.biz Regards, Vanessa Smith _____________________________________________________ To be taken out, go: http://www.oemunlimited.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_7329478D.D7E2C772 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Access all the popular software imaginable for extremely low prices!
Our software is 2-10 times cheaper than sold by our competitors.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 Quark Xpress 6 Passport Multilanguage

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And lots more... Please visit us at:

http://www.oemunlimited.biz

Best,
Vanessa J. Smith


_____________________________________________________
To change your mail details, go here: http://www.oemunlimited.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_7329478D.D7E2C772-- ------=_NextPart_000_0000_24E5A431.737A0798-- From owner-ccamp@ops.ietf.org Sun Apr 3 22:06:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16014 for ; Sun, 3 Apr 2005 22:06:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIH76-0008Vs-PB for ccamp-archive@ietf.org; Sun, 03 Apr 2005 22:14:59 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIGlx-000MFh-7g for ccamp-data@psg.com; Mon, 04 Apr 2005 01:53:01 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIGlv-000MFH-VZ for ccamp@ops.ietf.org; Mon, 04 Apr 2005 01:53:00 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IEE008GQFQE3G@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Sun, 03 Apr 2005 18:49:26 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IEE00LWSFQDQH@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Sun, 03 Apr 2005 18:49:26 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Mon, 04 Apr 2005 09:53:25 +0800 Date: Mon, 04 Apr 2005 09:53:25 +0800 From: Amit 70405 Subject: Re: Regarding Reversion To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org Message-id: <2c7542afda.2afda2c754@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_rX4cTK5Kc4EZkEGCiEXRAQ)" Content-language: en X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50,UPPERCASE_25_50 autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 This is a multi-part message in MIME format. --Boundary_(ID_rX4cTK5Kc4EZkEGCiEXRAQ) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT Hi Dimitri, I saw the details mentioned by you about this in another draft abot e2e recovery. So the LSP deletion is based on Reresh messages in reversion. But what will be the case in below scenarios: 1. if there is a dwonstream node fails. In this case refresh messages too will get affected. 2. if the signaling is in-band and the outif(as I mentioned in my previous mail) goes down. And there is no other interface to get the refresh messages. In both these scenarios, as refresh does not happen, the LSP should get deleted. Plz confirm if this is right. Or are you going to do some self-refresh kind of for infinite duration. Duration should be infinite as recovery of failure may take time. This self refresh has to be till failure recovers or till you again start getting the refresh messages. Or the State gets explicitly deleted by head end. Plz let me know your view. Thanks and Regards, Amit. --Boundary_(ID_rX4cTK5Kc4EZkEGCiEXRAQ) Content-type: message/rfc822 Content-disposition: inline MIME-version: 1.0 Content-type: TEXT/PLAIN Content-Transfer-Encoding: QUOTED-PRINTABLE =B9=EF=D0=C48=D0=B5=DB=9E=85=0F=AD4=E3]=80=F4=10=B5=DB=9E=85=0F=AD4= =E3]=81=EB=C9=DE=B5=FA=DA=95=C6=ADzW=EB0=83=04=BD=EA=EC=8A=89=F5=D0= =C2=0C=12=F7=AB=B2*'=D7@=A8=9E=D7=A7=B6=DC=A9z=D7=B1=B7=F8m=9AW!j= =BB=1E=B4=84;=CF9=F7P=A8=9E=D7=A7=B6=DA=DA=9E=C7=DE=AD=E9=DC=A1=D8= =A7=81=B6=AC{=AE=170=83=04N=B6=9C=91'=AB=89=A9b=CD=E6=F2F=8B=ADz=BA'= =04C=00 =BD9=FC=11?=00=B0=80LB=D1zW=9A=B1=EEt=D7a=C5=EF=CF=12z=9B^= =99=B7=AB=DB}=B4=D3=86=AD=D3=8F=F4=D7=FD=B4=D3=9Dw=E7^t>=B7=9Cy=D7= =A7q=E6=EE=96E=C0=95=C6=A7z=D3=13=02=C7=1A=9Ew=9DjwZ=BA=D8h=AE,=DEw'= =AC]*Z=98(^rG=ABU=EA=EC=8A=89=D2=A5=A9=80=B2=C6=AC=B2)=F7=D3]=B4=D3= =8Dt=DBj'=A6=C8=1C=A2e=D2=A5=A9=8Bz=F7=A5]*Z=99+Z=B6=EB =A2=C7(=AD=ED=EE=B7=AA=BA*=DEw=9D=B5=EB-=B0=05,=10=18=11-=B4=1D3=0B= =E3Nt=1D3=0B0D=92=00a=07L=C2=CC =C1 8t=CC-0=060=83=04=04=04=84=EB=84=C4]3=080A=D30=B3=8D-=83ND@=0B4=03= =04j=EBh=95=E6=AB=9Ez=BD=EA=EC=8A=89=DFMO=14=0F=8F=11=93=D3=95=08= =11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=9AY\=88=8F=98[Z]=0B= =08=1D\=1B=DB=88=19=18]=18H=1C=1B=18[=99H=19=98Z[=1D\=99H=1D=1A=19\= =99H=1A\=C8=1B=9B=C8=1C=DDX=DA=08=18=99Z=18]=9A[=DD\=88=18\=C8=1E[= =DDH=1BY[=9D=1A[=DB=88=0BH=1B=1B=D8=D8[=08=19=18]=18H=1C=1B=18[=99H= =19=98Z[=1D\=99H=19=19]=19X=DD=1A[=DB=88=19=1B=D9\=C8=1B=9B=DD=08= =1A[\=1B=1EH=1C=DD=18]=19H=19=19[=19]=1A[=DB=88=18[=99=08=18=DB=DB[[= =DB=88=14=18]=1A=11\=9C=8B=D4=99\=DD=91\=9C=88=19=1B=C8=1B=9B=DD=08= =1D=1C=9AY=D9=D9\=88=18[=9EH=1C=DD=18]=19H=19=19[=19]=1A[=DB=88=1B= =9B=DC=88=19=1B=D9\=C8=18H=13=9B=DD=1AY=9EN=C8=1A[=88=1C=18\=9D=1AX= =DD[=18\=8B=08=1A[=88=1D=1A=19H=1C=1C=99\=D9[=9D=08=18=DB=DB=9D=19^= =1D=08=1D=DA=19\=99H=1B=DB=99H=19=1B=C8=18\=DC=DD[YH=18=DB=DB=9D=1C= =9B=DB=08=1C=1B=18[=99H=18]=98Z[=18X=9A[=1A]=1EH=19]=99[=88=1A[=88= =18=D8\=D9H=1B=D9=88=19=18]=18H=1C=1B=18[=99H=19=98Z[=1D\=99H=0BH= =1B=9B=DD=19N=88=19=19]=18Z[=1C=C8=1B=D9=88=1A]=08=18]=98Z[=18X=9B= =19H=1A[=88=1B=DD=1A=19\=88=19=1B=D8=DD[Y[=9D=1C=C8=0BH=1C=DD=18]= =19\=C8=18=D8[=88=18=99H=1A=D9\=1D=08=1C=99Y=9C=99\=DA=19Y=0F=0B=D1= =93=D3=95=0F=8F=10=94=8F=8F=10=94=8F=8F=11=93=D3=95=08=14=D2V=91OL= =8F=8F=10=8F=90[Z]=08 =CC =0C H=09=9B=1D=0E=D0[Z]=11=D0=1A=1DX]=D9ZK=98=DB=DBI=99=DD=0E=CF=0B=D0= =8F=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=11=93=D3=95=08=14=D2V=91OL= =8F=94=D9[=9D=08=18=9EN=88=1B=DD=DB=99\=8BX=D8=D8[\=10=1B=DC=1C=CB= =9AY]=19=8B=9B=DC=99=CF=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=11=93=D3= =95=08=14=D2V=91OL=8F=8C =0B=CC=0CK=CC=8C=0C H=0CM=CE=8DLH=16=91N=0F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=10=94=8F= =88=0F=11=93=D3=95=08=14=D2V=91OL=8F=95=1B=CE=8F=0B=D1=93=D3=95=0F= =88=0F=11=93=D3=95=08=14=D2V=91OL=8F=91=1A[Z]=1C=9AH=14=10T=10Q=12SRU= =14=92S=D5K=D0=91K=D0S=10=D0U=11S=10=10S=10=D0U=11S=0F=0B=D1=93=D3= =95=0F=8F=10=94=8F=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=98=D8=CE=8F= =0B=D1=93=D3=95=0F=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=98=D8=D8[\= =10=1B=DC=1C=CB=9AY]=19=8B=9B=DC=99=CF=0B=D1=93=D3=95=0F=8F=10=94= =8F=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=98=98=D8=CE=8F=0B=D1=93=D3= =95=0F=88=0F=10=94=8F=88=0F=11=93=D3=95=08=14=D2V=91OL=8F=94=DDX=9A= =99X=DD=0E=8F=0B=D1=93=D3=95=0F=88=0F=11=93=D3=95=08=14=D2V=91OL=8F= =94=99N=88=14=99Y=D8\=99=1A[=99=C8=14=99]=99\=9C=DA[=DB=8F=0B=D1=93= =D3=95=0F=8F=10=94=8F=88=0F=10=94=8F=8F=10=94=8F=8F=0B=D4=0F=8F=14= =0F=8F=11=93=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\= =9AY\=88=8F=92=1AK=0F=10=94=8F=95=1A=18[=9A=DC=C8=19=9B=DC=88=1C=99\= =1B=1EZ[=99=CB=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=0B=D4=0F=8F=15S= =0F=8F=11=93=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\= =9AY\=88=8F=90X=D8=DB=DC=99=1A[=99=C8=1D=1B=C8=1D=1A=19H=1C=DD=18]= =19[Y[=9D=08=12H=1BY[=9D=1A[=DB=99Y=08=19=9C=9B=DBH=1D=1A=19H=19=1C= =98Y=9D=0B=08=12H=1D[=99=19\=9C=DD=18[=99=08=1D=1A=18]=0B=08=1AY=88= =1D=1A=19\=99H=1A\=C8=18H=19=98Z[=1D\=99H=1D=1A=19H=1B=DB=19=08=1D= =DB=DC=9A=DA[=99=C8=13=14=D4=08=1C=DA=1B=DD[=19=08=1B=9B=DD=08=18= =99H=19=19[=19]=19Y=0B=8F=10=94=8F=8F=0B=D1=93=D3=95=0F=8F=10=94=8F= =8F=11=93=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=9AY\= =88=8F=90=9D]=08=1B=9B=DD=08=1B=DB=9B=1EH=19=9B=DC=88=14=94=D5=94= =0B=08=19=9B=DC=88=18[=9EH=13T=13=14=C8=14=DAY=DB=98[=1A[=99=C8=1C= =1C=9B=DD=1B=D8=DB=DB=0B=08=1A]=08=1A\=C8=1BX[=99=18]=1B=DC=9EH=1D= =1A=18]=08=1D=DA=19[=88=18H=19=98Z[=1D\=99H=1A=18\=1C=19[=9C=CB=08= =1E[=DDH=1C=DA=1B=DD[=19=08=1C=DD=18\=9D=08=1D=19X\=9A[=99=C8=19=1B= =DD=DB=88=1D=1A=19H=13=14=D4=0B=8F=10=94=8F=8F=0B=D1=93=D3=95=0F=8F= =10=94=8F=8F=11=93=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10= =DB=DD\=9AY\=88=8F=95=18Z=D9H=19=9B=DC=88=1A[=9C=DD=18[=98=D9H=1AY= =88=18H=13=DD]=12[=9D=19\=99=98X=D9J=1B=DB=88=1D=DA=1AX=DA=08=13=14= =D4=08=1A\=C8=1C=D9]=1D\ H=19=DB=D9\=C8=19=1B=DD=DB=8B=8F=10=94=8F=94=1C=9B=DD=1B=D8=DB=DB= =08=1D=DA[=1B=08=1B=19XY=08=1D=1B=C8=13=14=D4=08=19=19[=19]=1A[=DB= =8B=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=0B=D5S=0F=8F=14=0F=8F=11=93= =D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=9AY\=88=8F= =94=1B=1E=88=18=DB=DC=9C=99X=DD=08=1BYH=1AY=88=12H=18[H=1D=DC=9B=DB= =99=CB=8F=10=94=8F=94=99Y=D8\=99=1C=CB=0F=10=94=8F=90[Z]=0B=8F=10= =94=8F=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=10=94=8F=8F=11=93=D3=95= =08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=9AY\=88=8F=90=DB= =DB=9D=19[=9D=0B]=1C=98[=9C=D9=99\=8BY[=98=DB=D9=1A[=99=CE=88=14US= =D5=11Q=0BT=14=92S=95=10P=93=11O=10=94=8F=93RSQK]=99\=9C=DA[=DB=8E= =88=0CK=8C=0F=10=94=8F=90=DB=DB=9D=19[=9D=0B]=1E\=19N=88=15=11V=15= =0B=D4=13=10RS=8F=0B=D1=93=D3=95=0F=8F=10=94=8F=8F=10=94=8F=8F=11= =93=D3=95=08=11=90P=D1OH=93[=DB=9B=DC=DC=18X=D9K=10=DB=DD\=9AY\=88= =8F=89=9C=18\=98N=C6=8A=C9=CD=C9=88=CD=8C=CD=8D=0C=0E=C9=91XX=DD]= =19N=C9=99][[=0E=C5=D2=A5=89=98=9C=9D=98=98\=8E=CF=10=94=8F=85=E7= =09=C9=99X=DA\=98=CE=C9=93=DD=1A[=19=19N=DE=89=9C=98\][=CE=C9=9C][= =DD=0E=C9=98=D9[=9D=0E=DD=09=98=DB=DC=1EN=DA=98=0B=09=9C=1B=1D\=DB[= =8E=C9=9B=18\][=CE=CB"=9FI=9B=D8=DA\=98=CE=C9=9D=1A[Y\=CE=DBM=09=98]= =1A[=19=19N=D7M=89=95XX=DD]=19N=E2I=99XX=DD]=19N=C9=9C=DD\=0C=8E=C1= =CA&]=09=98=DB=DC=1EN=DA=98=89=95=12=13=D4=93=8E=C9=99=9C=98X=CCL= =8E=C9=99XX=DD]=19N=D5=D2=A5=89=98=9C=9D=98=98\=8E=D2=89=93=DD[[=0E= =C9=9C=DA=1EN=C9=9B=DC=99=1BN=C9=90]=1A[=19=19N=DA=09=9C=1B=1D\=DB[= =8E=C9=91X=DA\=98=CE=CA=DE=D7=C9=9C=DA=1EN=C9=99X=DA\=98=CE=C9=9C= =99Y=CE=E2=89=9BZY=19=1B=DD=0E=C9=88=CD=8C=CD=8D=0C=0E=C9=98=D8=D9Y= =1A[=0E=D2=DE=89=91][[=0E=DB=00X=81=01=81=12=D3A=D3=09=90X=DA\=98= =CE=C9=9B=DD[[=0E=C9=93=D8X=DD]=19N=DFA=D3=09=90X=DA\=98=CE=C9=92Y= =DC=98]=99N=C4I =06=10I=93=D8X=DD]=19N=CC=09=9C=DD\=0C=CE=C2=0C=10= =D3=87L=C2=D3=00c=08=09=90XX=DD]=19N=C0@HN=89=98XX=DD]=19N=CCE=D3= =09=90X=DA\=98=CE=C3=04=1D=09=92Y=DC=98]=99N=CB=09=98]=1A[=19=19N= =D2=D8=09=93=D8X=DD]=19N=C9=C4=00=89=92XX=DD]=19N=CF=10=94=8F=89=90X= =DA\=98=CE=CF=10=94=8F=8F=10=94=8F=84=81=05=C1=C9=9C][=DD=0E=CF=10= =94=8F=88=CF=10=94=8F=8F=10=94=8F=94=8F=10=94=8F=84=D0=C9=9C=1B=DD[= =99=0E=C8=E0=C9=9C=1B=DD[=99=0E=D0=D0=80=89=9C=DD\=0C=CE=CF=10=94= =8F=A0=CF=10=94=8F=8F=10=94=8F=89=90][[=0E=C9H=C9=98][[=0E=D9=C9=98[\= =0E=C9=9B=DD[[=0E=C9=93=D8X=DD]=19N=C9=98=D9[=9D=0E=C1=05=89=93=DD[[= =0E=E5=D0=8F=10=94=8F=9C=CF=10=94=8F=90=CF=10=94=8F=94=80=99=89=90= =D8=D9Y=1A[=0E=D0=C9=98X=DD]=19N=C5=89=93=DD[[=0E=E5=D1=1D=01=A1=D5= =85=DD=95=89=C9=98Y[=1AY=CE=CD=89=9B=DD[[=0E=C9=93=D9=DC=98]=99N=D9= =9D=D0=C9=9C=DD\=0C=CE=C9=90][[=0E=C9H=C9=98\=9A[ =CE=CD=D5=89=98[\=0E=C9=98=9C=9D=98=98\=8E=D5=8D=D0=C9=98=D9[=9D=0E= =C1I=98[\=0E=D5=9D=85=C9=98[\=0E=D1=A5=89=98Y[=1AY=CE=DC=81I=98[\= =0E=D5=D9=95=C9=CD=A5=89=9B=DD[[=0E=C9=98]=1A[=19=19N=C9=90][[=0E= =C9H=C9=98\=9A[=99=CE=D1=89=9B=D8X=DD]=19N=C9=98=D9[=9D=0E=C1=89=98[\= =0E=C5=89=90Q[=1AY=CE=C4=89=98=D8=D9Y=1A[=0E=C9=98[\=0E=C5=89=98=9C= =9D=98=98\=8E=C5=9D=89=99=1A]=9AY=19N=C1=85=89=90Q[=1AY=CE=C5=89=98][= [=0E=C1=A5=89=98=D8=D9Y=1A[=0E=D1=95=89=90X=DA\=98=CE=C9=98Y[=1AY= =CE=CD=89=9B=DD[[=0E=C9=93=D9=DC=98]=99N=C9=90X=DA\=98=CE=C1=91=A5= =89=93=DD[[=0E=E5=D1=C9=98[\=0E=C9=C9=98=D8=D9Y=1A[=0E=C1=85=C1=85= =91=A5=89=93=DD[[=0E=E5=D1=C9=98[\=0E=E5=89=99=1A]=9AY=19N=D5=01=85= =89=90Q[=1AY=CE=CD=85=D1=95=89=90X=DA\=98=CE=C9=98Y[=1AY=CE=C9=98[\= =0E=D4=C9=90][[=0E=C9H=C9=98][[=0E=CD=8C=C9=98=D9[=9D=0E=C1=8D=8D= =85=89=9D=1A[Y\=CE=C1=01=A5=95=D1=98=89=98Y[=1AY=CE=C9=99=1A]=9AY= =19N=C9=98[\=0E=DC=C9=90][[=0E=C9H=C9=98][[=0E=C9=93=DD[[=0E=D5=CD= =CD=85=9D=94=89=93=DD[[=0E=E5=90=C9=98=D9[=9D=0E=C0=99=89=90=D8=D9Y= =1A[=0E=D0=C9=9C=DD\=0C=CE=C4=C8=D1=90=DC=E0=E0=C4=C8=D1=98=C9=98[\= =0E=D9=98=89=98]=1A[=19=19N=C4=C8=D1=98=C9=98[\=0E=D9=98=C4=C8=D1= =90=DC=E0=CF=0B=D1=93=D3=95=0F=8F=0B --Boundary_(ID_rX4cTK5Kc4EZkEGCiEXRAQ)-- From owner-ccamp@ops.ietf.org Mon Apr 4 05:25:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10175 for ; Mon, 4 Apr 2005 05:25:36 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DINxo-0002f0-5b for ccamp-archive@ietf.org; Mon, 04 Apr 2005 05:33:49 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DINgV-0007xM-4W for ccamp-data@psg.com; Mon, 04 Apr 2005 09:15:51 +0000 Received: from [61.144.161.54] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DINgL-0007wn-Kg for ccamp@ops.ietf.org; Mon, 04 Apr 2005 09:15:46 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IEF00KH40F4UP@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Mon, 04 Apr 2005 17:16:16 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IEF005740F47P@szxga02-in.huawei.com> for ccamp@ops.ietf.org; Mon, 04 Apr 2005 17:16:16 +0800 (CST) Received: from z18605 ([10.110.100.105]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IEF00G4B0JPSG@szxml01-in.huawei.com>; Mon, 04 Apr 2005 17:19:01 +0800 (CST) Date: Mon, 04 Apr 2005 16:51:03 +0800 From: Zhang Renhai Subject: Re: WG last calls To: Adrian Farrel Cc: "Ash, Gerald R (Jerry), ALABS" , ccamp@ops.ietf.org Message-id: <00a901c538f3$71e26d00$69646e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <9473683187ADC049A855ED2DA739ABCA060CE50E@KCCLUST06EVS1.ugd.att.com> <15e901c537af$d846cbd0$dccb2bd4@Puppy> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7BIT Hi, Adrian In RFC 3209,LSP is provided with attribute of Priority(Setup Priority,Holding Priority), so it is more reasonable to process different LSPs according to the Priority, for the LSP with higher priority, more retry number should be given, lower priority with less number. Extremely, to the highest LSP, can the interception be concelled by ABR?(although multi LSPs may be derived simultaneously, sellection can be done by egress on receiving Path massege .So we can get another LSP with most possibility because of its highest priority) Just my suggestion. Regard, Zhang ----- Original Message ----- From: "Adrian Farrel" To: "Ash, Gerald R (Jerry), ALABS" ; "Zhang Renhai" ; ; "Kireeti Kompella" Cc: "Ash, Gerald R (Jerry), ALABS" Sent: Sunday, April 03, 2005 1:05 AM Subject: Re: WG last calls > Hi, > > Yes, to clarify what Jerry says, the number of crankback attempts MAY be > limited. At the moment, the only way that we provide to limit the attempts > is implemented per LSR. That is, any LSR MAY decide that it has performed > enough attempts at rerouting and pass the error back to the upstream LSR. > > Note that the use of crankback to derive a path through a network is not > recommended. This approach is almost equivalent to random walk routing and > is neither efficient nor effective. > > The use of crankback, as described in the draft is intended for use in > specific circumstances, such as inter-domain routing. In these cases only > selective LSRs (such as domain boundaries) perform rerouting attempts. > > Adrian > > ----- Original Message ----- > From: "Ash, Gerald R (Jerry), ALABS" > To: "Zhang Renhai" ; "Adrian Farrel" > ; ; "Kireeti Kompella" > > Cc: "Ash, Gerald R (Jerry), ALABS" > Sent: Friday, April 01, 2005 2:02 PM > Subject: RE: WG last calls > > > Zhang, > > > From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the > > number of crankback rerouting is limited, so there will > > be a result: there is another LSP,but for the reason of > > limiting, the path may be not found. I think sometimes > > it is unacceptable.The LSP may be prefered to enhancing > > performance. > > This problem can be avoided by the setting the node retry threshold > (configurable per node) very high (~infinity), so retries aren't > limited. > > Thanks, > Jerry > > > > From owner-ccamp@ops.ietf.org Mon Apr 4 06:39:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15992 for ; Mon, 4 Apr 2005 06:39:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIP7N-0005Dj-3K for ccamp-archive@ietf.org; Mon, 04 Apr 2005 06:47:44 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIOrd-000HOb-0r for ccamp-data@psg.com; Mon, 04 Apr 2005 10:31:25 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIOrY-000HO3-DX for ccamp@ops.ietf.org; Mon, 04 Apr 2005 10:31:21 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id E495FE0001E9; Mon, 4 Apr 2005 11:31:04 +0100 (BST) Received: from Puppy ([212.43.203.6] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 11:30:49 +0100 Message-ID: <165f01c53901$9fa68c90$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: , Cc: "Kireeti Kompella" , , , , , References: <20050331073357.R83270@kummer.juniper.net> <424ED58B.6010007@psg.com> Subject: Re: WG last calls - comments on crankback i-d Date: Sun, 3 Apr 2005 08:40:32 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_161D_01C53828.CC72F3A0" 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: 04 Apr 2005 10:30:50.0987 (UTC) FILETIME=[5F7F83B0:01C53901] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48,HTML_30_40,HTML_MESSAGE autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: ea4f8bb40fb51c4b78b78b96371429a8 This is a multi-part message in MIME format. ------=_NextPart_000_161D_01C53828.CC72F3A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dimitri, Thanks for the thorough review. > technical > --------- >=20 > 1. section 2.1 >=20 > it seems from phrasing the term QoS is used in two different ways >=20 > "Using RSVP-TE, resources can also be reserved along a path to = guarantee > or control QoS for traffic carried on the LSP" thus last part of = this=20 > sentence refers to the traffic oriented approach (as detailed in RFC=20 > 2702) but after in this section (and in section 4.2) the term "QoS=20 > constraints" is used in a resource oriented perspective; Point taken. This needs to be clarified. > 2. section 2.2 >=20 > " The requirement for end-to-end allocation of lambda resources in > GMPLS networks without wavelength converters means that end-to-end > restoration is the only way to recover LSP failures. " >=20 > -> would it be possible to know how you came to this statement ? Yes. Actually, it should read "may be the only way". Simply put, segment protection may be much harder in networks of = photonic cross-connects because a particular lambda may already be in = use on other links. End-to-end protection offers the choice of use of = another lambda, but this choice is not available in segment protection. =20 > 3. section 3. >=20 > I may have missed it but the definition of "Explicit and Implicit=20 > Re-routing Indications" is not provided The first paragraph was intended to convey this. We will clarify. > 4. section 4.2.1 >=20 > not sure to see why the "reason" of the failure is important beside=20 > link, label, etc. (in particular since the persistence is limited to = the=20 > LSP under establishmnet) - but i guess it depends on the semantic you=20 > put behind this word in the present context - OK. It would probably help if we gave an example and a counter example. Off the top of my head: "temporary control plane congestion" has a = different impact on crankback rerouting to "cannot route to = destination". > also by context you mean "position" of the element under failure wrt = to=20 > its sequence as part of the ERO ? Yeah. I don't think either of us has the right word here. We'll try to = find something that explains this a bit better. > 5. section 4.4 >=20 > is it " error indication upstream" or indicationS (collection) ? Hmmm. One error indication (message) may report multiple errors. We will clarify this by inserting the word "message". > 6. section 5.2 >=20 > "The Notify > message may be used to expedite the propagation of error > notifications, but in a network that offers crankback routing at > multiple nodes there would need to be some agreement between LSRs > as to whether PathErr or Notify provides the stimulus for = crankback > operation. " >=20 > this agreement is constrained by the re-routing behavior selection (as = > listed in section 6.4 Yes. That would be a helpful cross-reference. > 7. section 6.4 >=20 > point 2 - why segment-based is referred to as "hierarchical" - do you=20 > refer to an "horizontal hierarchy" here ?) Probably best if we remove this word because it has overloaded semantics = with respect to hierarchical LSPs. What we meant is simply that segment based protection allows you to = protect ever smaller segments in a nested way. For example... A--B--C--D--E--F--G--H | | | | | | | | P--Q | | | R----S---T | W----X----Y----Z=20 > 8. section 7.2 >=20 > not sure to understand the "Proposed ERO" TLV ? would it be possible = to=20 > describe this more than "MAY supply suggestions about the ERO that = could=20 > have been used to avoid the error." Intention is to allow a downstream LSR to report that "I cannot route = using the supplied ERO, but if you had supplied *this* ERO it would have = been possible." > not sure to understand the "ERO_NEXT_CONTEXT" TLV Both of these TLVs are described a bit further in 7.3.4. However, on = re-reading I see that there isn't enough information. The distinction = between TLVs 12 and 13 is the distinction between "this is the hop I was = trying to satisfy when I failed" and "this is the next hop I was trying = to reach when I failed". > " Link Identifiers: >=20 > A sequence of TLVs as defined here of type 3 that indicate > incoming interfaces at downstream nodes that have already > participated in crankback attempts and have been declared > unusable for the current LSP setup attempt." >=20 > -> definition does not match the one proposed above in the text >=20 > " For types 1, 2 and 3 the format of the Value field is already=20 > defined in [RFC3471]." Not sure what you are saying. Are you simply suggesting that the = defintion of the Value for type 27 should point to 3471? > 9. section 7.4.1 >=20 > " As described in section 3, a node receiving crankback information = in > a PathErr must first check to see whether it is allowed to perform > re-routing. This is indicated by the Re-routing Flags in the > SESSION_ATTRIBUTE object during LSP setup request." >=20 > -> why do you make use of the session attribute since section 6.4=20 > mentions usage of lsp attribute object Good catch! Old text that should be replaced with LSP ATTRIBUTE. > 10. section 7.3 >=20 > in section 7.3.1 it is mentioned >=20 > " If crankback is not being used but an IF-ID ERROR_SPEC object is > included in a PathErr, ResvErr or Notify message, the sender = SHOULD > include one of the TLVs of type 1 through 3 as described in > [RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described in > [BUNDLE] and component links should be identified using the > principles described in that document. >=20 > A sender MAY include additional TLVs from the range 6 through 27 > to report crankback information, although this information will at > most only be used for logging." >=20 > [...] >=20 > "An LSR that proposes to perform crankback re-routing SHOULD > support receipt and processing of all of the fundamental crankback > TLVs, and is RECOMMENDED to support the receipt and processing of > the additional crankback TLVs." >=20 > in section 7.3.2 it is mentioned >=20 > " Error Report TLVs are those in the range 1 through 3. (Note that > the obsoleted TLVs 4 and 5 may be considered in this category, but > SHOULD NOT be used.) >=20 > As stated above, when crankback information is reported, the IF_ID > ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object = is > used, at least one of the TLVs in the range 1 through 3 MUST be > present. The choice of which TLV to use will be dependent on the > circumstance of the error and device capabilities. For example, a > device that does not support IPv6 will not need the ability to > create a TLV of type 2. Note, however, that such a device MUST = still > be prepared to receive and process all error report TLVs." >=20 > in section 7.3.4 it is mentioned >=20 > " It is left as an implementation detail precisely when to include = each > of the TLVs according to the capabilities of the system reporting = the > error." >=20 > =3D> would it be possible to harmonize these MUST, SHOULD, MAY, etc; ? = one=20 > way to achieve this is by reducing repetitions and probably have 2=20 > sub-sections instead of 4 Yes. > same comment in section 7.4.5 where it is mentioned >=20 > "When the node gives up it must propagate > the failure message further upstream and include crankback > information when it does so." Same answer. > 11. section 8. >=20 > " For example, when an intermediate LSR issues a PathErr message, = the > signaling module of the intermediate LSR should interact with the > routing logic to determine the routing-protocol-specific link or = node > ID where the blockage or fault occurred and carry this information > onto the Link TLV and Node TLV inside the IF_ID ERROR_SPEC = object." >=20 > -> Link TLV is not defined as part of the table ? would it be possible = > to list to which TLV you are referring to Yes. Means TLV 1, 2 or 3. > 12. section 9.1 >=20 > " In a network segmented into areas, the following procedures can be > used. As explained in Section 8.2, the LSP restoration behavior is > indicated in the Flags field of the SESSION_ATTRIBUTE object of = the > Path message. If the Flags indicate "End-to-end re-routing", the > PathErr message is returned all the way back to the ingress LSR, > which may then issue a new Path message along another path, which = is > the same procedure as in the flat network case above." >=20 > -> why do you make use of the session attribute since section 6.4=20 > mentions usage of lsp attribute object Ditto, above. > editorial > --------- >=20 > 1. title >=20 > "Crankback Signaling Extensions for MPLS and GMPLS Signaling" >=20 > is probably redundant i would suggest (but leave this at your = discretion) >=20 > "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE" OK > 2. section 2.2 >=20 > alignment with P&R terminology and concepts would be advisable > = OK. Anything specific or do we just need to do a general parse? > 3. section 4.2 >=20 > "On the other hand, in a network partitioned into areas such as with > hierarchical OSPF,..." >=20 > why "hierarchical OSPF" and not simply "OSPF" Because we like adding the word "hierarchical" at every oportunity :-) > 4. section 5. - point 3) >=20 > instead of "... (particularly in the GMPLS context)," >=20 > I guess you mean for non-PSC LSP ? You guess correctly. Will tidy this. > 5. section 7.2 >=20 > "IF_ID PHOP" -> IF_ID RSVP_HOP ? Yes. > 6. section 7.2 >=20 > " Node Identifiers: >=20 > A sequence of TLVs as defined here of types 1, 2 or 8 that > indicates downstream nodes that have already participated = in > crankback attempts and have been declared unusable for the > current LSP setup attempt." >=20 > type 1, 2 does not define nodes in the proposed table ? Not sure about this. Your point is valid, but it is also the case that = one may identify a node by one of its interfaces. Thus it may be = convenient to simply put the list of failed interfaces into this TLV and = thus identify the list of nodes that have failed to perform crankback. I guess we need a little input from the implementers on this point. > 7. section 8 >=20 > " The ingress LSR, upon receiving the error message, should interact > with the routing logic to compute an alternate path by pruning the > specified link ID or node ID in the routing database." >=20 > i guess "node ID" refers to Router ID ? Well, "TE Router ID". And, of course, "Routing database" should read "Traffic Engineering = Database". > also do no provide the exact pointer for TE Router ID and Router ID in = > the IS-IS context Yup. I think by using TE Router ID we are covered in the IS-IS case, and = we just need to update the text to identify the exact field. > hope this will help It does, a lot. Thanks, Adrian ------=_NextPart_000_161D_01C53828.CC72F3A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Dimitri,
 
Thanks for the thorough = review.
 
> technical
> = ---------
>
>=20 1. section 2.1
>
> it seems from phrasing the term QoS is = used in=20 two different ways
>
> "Using RSVP-TE, resources can also = be=20 reserved along a path to guarantee
>   or control QoS for = traffic=20 carried on the LSP" thus last part of this
> sentence refers to = the=20 traffic oriented approach (as detailed in RFC
> 2702) but after = in this=20 section (and in section 4.2) the term "QoS
> constraints" is used = in a=20 resource oriented perspective;
 
Point taken. This needs to be=20 clarified.

> 2. section 2.2
> =
> " The=20 requirement for end-to-end allocation of lambda resources in
>=20     GMPLS networks without wavelength converters means = that=20 end-to-end
>     restoration is the only way to = recover LSP=20 failures. "
>
> -> would it be possible to know how you = came to=20 this statement ?
 
Yes.
Actually, it should read "may be the = only=20 way".
Simply put, segment protection may be = much harder=20 in networks of photonic cross-connects because a particular lambda = may=20 already be in use on other links. End-to-end protection offers the = choice of use=20 of another lambda, but this choice is not available in segment=20 protection.
 
> 3. section 3.
>=20
> I may have missed it but the definition of "Explicit and = Implicit=20
> Re-routing Indications" is not provided
 
The first paragraph was intended to = convey this.=20 We will clarify.

> 4. section 4.2.1
> =
> not=20 sure to see why the "reason" of the failure is important beside
> = link,=20 label, etc. (in particular since the persistence is limited to the =
> LSP=20 under establishmnet) - but i guess it depends on the semantic you =
> put=20 behind this word in the present context -
 
OK. It would probably help if we gave = an example=20 and a counter example.
 
Off the top of my head: "temporary = control plane=20 congestion" has a different impact on crankback rerouting to "cannot = route to=20 destination".
 
> also by context you mean = "position" of the=20 element under failure wrt to
> its sequence as part of the ERO=20 ?
 
Yeah. I don't think either of us has = the right=20 word here. We'll try to find something that explains this a bit=20 better.
 
> 5. section 4.4
>
> = is it "=20 error indication upstream" or indicationS (collection) ?
 
Hmmm.
One error indication (message) may = report=20 multiple errors.
We will clarify this by inserting the = word=20 "message".
 
> 6. section 5.2
>
> = "The=20 Notify
>     message may be used to expedite the=20 propagation of error
>     notifications, but in a = network=20 that offers crankback routing at
>     multiple = nodes there=20 would need to be some agreement between LSRs
>     = as to=20 whether PathErr or Notify provides the stimulus for crankback
>=20     operation. "
>
> this agreement is = constrained=20 by the re-routing behavior selection (as
> listed in section=20 6.4
 
Yes. That would be a helpful=20 cross-reference.

> 7.=20 section 6.4
>
> point 2 - why segment-based is referred to = as=20 "hierarchical" - do you
> refer to an "horizontal hierarchy" here = ?)
 
Probably best if we remove this word = because it=20 has overloaded semantics with respect to hierarchical LSPs.
What we meant is simply that segment = based=20 protection allows you to protect ever smaller segments in a nested way. = For=20 example...
 
 
A--B--C--D--E--F--G--H
   |  |  = |  | =20 |  |
   |  |  P--Q =20 |  |
   |  = R----S---T =20 |
   W----X----Y----Z =
 

> 8. section 7.2
> =
> not sure=20 to understand the "Proposed ERO" TLV ? would it be possible to
> = describe=20 this more than "MAY supply suggestions about the ERO that could
> = have=20 been used to avoid the error."
 
Intention is to allow a downstream = LSR to report=20 that "I cannot route using the supplied ERO, but if you had supplied = *this* ERO=20 it would have been possible."
 
> not sure to understand the=20 "ERO_NEXT_CONTEXT" TLV
 
Both of these TLVs are described a = bit further in=20 7.3.4. However, on re-reading I see that there isn't enough information. = The=20 distinction between TLVs 12 and 13 is the distinction between "this is = the hop I=20 was trying to satisfy when I failed" and "this is the next hop I was = trying to=20 reach when I failed".

> " Link Identifiers:
>
>=20            A sequence = of TLVs=20 as defined here of type 3 that indicate
>=20            incoming = interfaces=20 at downstream nodes that have already
>=20            = participated in=20 crankback attempts and have been declared
>=20            unusable = for the=20 current LSP setup attempt."
>
> -> definition does not = match the=20 one proposed above in the text
>
> "   For types = 1, 2 and=20 3 the format of the Value field is already
> defined in = [RFC3471]."
 
Not sure what you are saying. Are you simply suggesting that the = defintion=20 of the Value for type 27 should point to 3471?
 
> 9. section 7.4.1
>
> "   As described = in=20 section 3, a node receiving crankback information in
> =    =20 a PathErr must first check to see whether it is allowed to = perform
>=20     re-routing. This is indicated by the Re-routing Flags = in=20 the
>     SESSION_ATTRIBUTE object during LSP setup = request."
>
> -> why do you make use of the session = attribute=20 since section 6.4
> mentions usage of lsp attribute object
 
Good catch!
Old text that should be replaced with LSP ATTRIBUTE.
 
> 10. section 7.3
>
> in section 7.3.1 it is=20 mentioned
>
>   "  If crankback is not being used = but an=20 IF-ID ERROR_SPEC object is
>     included in a = PathErr,=20 ResvErr or Notify message, the sender SHOULD
>     = include=20 one of the TLVs of type 1 through 3 as described in
> =    =20 [RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described = in
>=20     [BUNDLE] and component links should be identified = using=20 the
>     principles described in that = document.
>=20
>     A sender MAY include additional TLVs from = the range=20 6 through 27
>     to report crankback information, = although this information will at
>     most only = be used=20 for logging."
>
> [...]
>
>    "An = LSR that=20 proposes to perform crankback re-routing SHOULD
> =    =20 support receipt and processing of all of the fundamental = crankback
>=20     TLVs, and is RECOMMENDED to support the receipt and=20 processing of
>     the additional crankback = TLVs."
>=20
> in section 7.3.2 it is mentioned
>
> " Error = Report TLVs=20 are those in the range 1 through 3. (Note that
> =     the=20 obsoleted TLVs 4 and 5 may be considered in this category, but
>=20     SHOULD NOT be used.)
>
> =     As=20 stated above, when crankback information is reported, the IF_ID
>=20     ERROR_SPEC object MUST be used. When the IF_ID = ERROR_SPEC=20 object is
>     used, at least one of the TLVs in = the range=20 1 through 3 MUST be
>     present. The choice of = which TLV=20 to use will be dependent on the
>     circumstance = of the=20 error and device capabilities. For example, a
>     = device=20 that does not support IPv6 will not need the ability to
>=20     create a TLV of type 2. Note, however, that such a = device=20 MUST still
>     be prepared to receive and process = all=20 error report TLVs."
>
> in section 7.3.4 it is = mentioned
>=20
> " It is left as an implementation detail precisely when to = include=20 each
>     of the TLVs according to the = capabilities of the=20 system reporting the
>     error."
>
> = =3D>=20 would it be possible to harmonize these MUST, SHOULD, MAY, etc; ? one =
>=20 way to achieve this is by reducing repetitions and probably have 2 =
>=20 sub-sections instead of 4
 
Yes.

> same comment in section 7.4.5 where it is = mentioned
>=20
> "When the node gives up it must propagate
> =    =20 the failure message further upstream and include crankback
>=20     information when it does so."
 
Same answer.

> 11. section 8.
>
>    " For = example, when=20 an intermediate LSR issues a PathErr message, the
> =    =20 signaling module of the intermediate LSR should interact with = the
>=20     routing logic to determine the = routing-protocol-specific link=20 or node
>     ID where the blockage or fault = occurred and=20 carry this information
>     onto the Link TLV and = Node TLV=20 inside the IF_ID ERROR_SPEC object."
>
> -> Link TLV is = not=20 defined as part of the table ? would it be possible
> to list to = which=20 TLV you are referring to
 
Yes. Means TLV 1, 2 or 3.

> 12. section 9.1
>
> "   In a = network=20 segmented into areas, the following procedures can be
> =    =20 used. As explained in Section 8.2, the LSP restoration behavior = is
>=20     indicated in the Flags field of the SESSION_ATTRIBUTE = object=20 of the
>     Path message. If the Flags indicate=20 "End-to-end re-routing", the
>     PathErr message = is=20 returned all the way back to the ingress LSR,
>     = which=20 may then issue a new Path message along another path, which is
>=20     the same procedure as in the flat network case=20 above."
>
> -> why do you make use of the session = attribute=20 since section 6.4
> mentions usage of lsp attribute object
 
Ditto, above.

> editorial
> ---------
>
> 1. = title
>=20
> "Crankback Signaling Extensions for MPLS and GMPLS = Signaling"
>=20
> is probably redundant i would suggest (but leave this at your=20 discretion)
>
> "Crankback Signaling Extensions for MPLS = and GMPLS=20 RSVP-TE"
 
OK
 
> 2. section 2.2
>
> alignment with P&R = terminology and=20 concepts would be advisable
> <http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recov= ery-terminology-06.txt>
 
OK. Anything specific or do we just = need to do a=20 general parse?
 
> 3. section 4.2
>
> "On the other hand, in a = network=20 partitioned into areas such as with
>     = hierarchical=20 OSPF,..."
>
> why "hierarchical OSPF" and not simply = "OSPF"
 
Because we like adding the word "hierarchical" at every oportunity=20 :-)
 
> 4. section 5. - point 3)
>
> instead of "...=20 (particularly in the GMPLS context),"
>
> I guess you = mean for=20 non-PSC LSP ?
 
You guess correctly. Will tidy this.
 
> 5. section 7.2
>
> "IF_ID PHOP" -> IF_ID = RSVP_HOP=20 ?
 
Yes.

> 6. section 7.2
>
>=20        " Node Identifiers:
> =
>=20            A sequence = of TLVs=20 as defined here of types 1, 2 or 8 that
>=20            indicates=20 downstream nodes that have already participated in
>=20            crankback = attempts=20 and have been declared unusable for the
>=20            current LSP = setup=20 attempt."
>
> type 1, 2 does not define nodes in the = proposed table=20 ?
 
Not sure about this. Your point is valid, but it is also the case = that one=20 may identify a node by one of its interfaces. Thus it may be convenient = to=20 simply put the list of failed interfaces into this TLV and thus identify = the=20 list of nodes that have failed to perform crankback.
 
I guess we need a little input from the implementers on this=20 point.

> 7. section 8
>
> "  The ingress = LSR, upon=20 receiving the error message, should interact
>     = with the=20 routing logic to compute an alternate path by pruning the
>=20     specified link ID or node ID in the routing=20 database."
>
> i guess "node ID" refers to Router ID = ?
 
Well, "TE Router ID".
And, of course, "Routing database" should read "Traffic Engineering = Database".

> also do no provide the exact pointer for TE Router ID and = Router=20 ID in
> the IS-IS context
 
Yup. I think by using TE Router ID we are covered in the IS-IS = case, and we=20 just need to update the text to identify the exact field.
 
> hope this will help
 
It does, a lot.
 
Thanks,
Adrian
 
------=_NextPart_000_161D_01C53828.CC72F3A0-- From owner-ccamp@ops.ietf.org Mon Apr 4 19:04:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22889 for ; Mon, 4 Apr 2005 19:04:02 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIak2-0005Ja-9F for ccamp-archive@ietf.org; Mon, 04 Apr 2005 19:12:23 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIaVU-0007ak-Ng for ccamp-data@psg.com; Mon, 04 Apr 2005 22:57:20 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIaVK-0007Z2-PW; Mon, 04 Apr 2005 22:57:11 +0000 Message-ID: <4251C641.7020803@psg.com> Date: Tue, 05 Apr 2005 00:57:05 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: dimitri.papadimitriou@alcatel.be, Kireeti Kompella , ccamp@ops.ietf.org, a-iwata@ah.jp.nec.com, n-fujita@bk.jp.nec.com, gash@att.com, kuvempu@yahoo.com Subject: Re: WG last calls - comments on crankback i-d References: <20050331073357.R83270@kummer.juniper.net> <424ED58B.6010007@psg.com> <165f01c53901$9fa68c90$dccb2bd4@Puppy> In-Reply-To: <165f01c53901$9fa68c90$dccb2bd4@Puppy> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Content-Transfer-Encoding: 7bit hi adrian - see in-line for one or two remaining clarifications: Adrian Farrel wrote: > Hi Dimitri, > > Thanks for the thorough review. > >> technical --------- >> >> 1. section 2.1 >> >> it seems from phrasing the term QoS is used in two different ways >> >> "Using RSVP-TE, resources can also be reserved along a path to >> guarantee or control QoS for traffic carried on the LSP" thus last >> part of this sentence refers to the traffic oriented approach (as >> detailed in RFC 2702) but after in this section (and in section >> 4.2) the term "QoS constraints" is used in a resource oriented >> perspective; > > Point taken. This needs to be clarified. > > >> 2. section 2.2 >> >> " The requirement for end-to-end allocation of lambda resources in >> GMPLS networks without wavelength converters means that end-to-end >> restoration is the only way to recover LSP failures. " >> >> -> would it be possible to know how you came to this statement ? > > Yes. Actually, it should read "may be the only way". Simply put, > segment protection may be much harder in networks of photonic > cross-connects because a particular lambda may already be in use on > other links. End-to-end protection offers the choice of use of > another lambda, but this choice is not available in segment > protection. > >> 3. section 3. >> >> I may have missed it but the definition of "Explicit and Implicit >> Re-routing Indications" is not provided > > The first paragraph was intended to convey this. We will clarify. > >> 4. section 4.2.1 >> >> not sure to see why the "reason" of the failure is important beside >> link, label, etc. (in particular since the persistence is limited >> to the LSP under establishmnet) - but i guess it depends on the >> semantic you put behind this word in the present context - > > OK. It would probably help if we gave an example and a counter > example. > > Off the top of my head: "temporary control plane congestion" has a > different impact on crankback rerouting to "cannot route to > destination". > >> also by context you mean "position" of the element under failure >> wrt to its sequence as part of the ERO ? > > Yeah. I don't think either of us has the right word here. We'll try > to find something that explains this a bit better. > >> 5. section 4.4 >> >> is it " error indication upstream" or indicationS (collection) ? > > Hmmm. One error indication (message) may report multiple errors. We > will clarify this by inserting the word "message". > >> 6. section 5.2 >> >> "The Notify message may be used to expedite the propagation of >> error notifications, but in a network that offers crankback routing >> at multiple nodes there would need to be some agreement between >> LSRs as to whether PathErr or Notify provides the stimulus for >> crankback operation. " >> >> this agreement is constrained by the re-routing behavior selection >> (as listed in section 6.4 > > Yes. That would be a helpful cross-reference. > >> 7. section 6.4 >> >> point 2 - why segment-based is referred to as "hierarchical" - do >> you refer to an "horizontal hierarchy" here ?) > > Probably best if we remove this word because it has overloaded > semantics with respect to hierarchical LSPs. What we meant is simply > that segment based protection allows you to protect ever smaller > segments in a nested way. For example... > > A--B--C--D--E--F--G--H > | | | | | | > | | P--Q | | > | R----S---T | > W----X----Y----Z -> ok - i would refer to this as "nested crankback" >> 8. section 7.2 >> >> not sure to understand the "Proposed ERO" TLV ? would it be >> possible to describe this more than "MAY supply suggestions about >> the ERO that could have been used to avoid the error." > > Intention is to allow a downstream LSR to report that "I cannot route > using the supplied ERO, but if you had supplied *this* ERO it would have > been possible." > >> not sure to understand the "ERO_NEXT_CONTEXT" TLV > > Both of these TLVs are described a bit further in 7.3.4. However, on > re-reading I see that there isn't enough information. The distinction > between TLVs 12 and 13 is the distinction between "this is the hop I was > trying to satisfy when I failed" and "this is the next hop I was trying > to reach when I failed". > >> " Link Identifiers: >> >> A sequence of TLVs as defined here of type 3 that indicate incoming >> interfaces at downstream nodes that have already participated in >> crankback attempts and have been declared unusable for the current >> LSP setup attempt." >> >> -> definition does not match the one proposed above in the text >> >> " For types 1, 2 and 3 the format of the Value field is already >> defined in [RFC3471]." > > > Not sure what you are saying. Are you simply suggesting that the > defintion of the Value for type 27 should point to 3471? -> i mean that the encoding is borrowed from [RFC3471] but not the definition since pointing to "incoming interface at downstream node" (which is the RFC3209 definition taken from ERO construction) and not the corr. definition of [RFC3473] "Data channels are specified from the viewpoint of the sender of the Path message". >> 9. section 7.4.1 >> >> " As described in section 3, a node receiving crankback information >> in a PathErr must first check to see whether it is allowed to >> perform re-routing. This is indicated by the Re-routing Flags in >> the SESSION_ATTRIBUTE object during LSP setup request." >> >> -> why do you make use of the session attribute since section 6.4 >> mentions usage of lsp attribute object > > Good catch! Old text that should be replaced with LSP ATTRIBUTE. > >> 10. section 7.3 >> >> in section 7.3.1 it is mentioned >> >> " If crankback is not being used but an IF-ID ERROR_SPEC object is >> included in a PathErr, ResvErr or Notify message, the sender SHOULD >> include one of the TLVs of type 1 through 3 as described in >> [RFC3473]. TLVs of type 4 or 5 SHOULD NOT be used as described in >> [BUNDLE] and component links should be identified using the >> principles described in that document. >> >> A sender MAY include additional TLVs from the range 6 through 27 to >> report crankback information, although this information will at >> most only be used for logging." >> >> [...] >> >> "An LSR that proposes to perform crankback re-routing SHOULD >> support receipt and processing of all of the fundamental crankback >> TLVs, and is RECOMMENDED to support the receipt and processing of >> the additional crankback TLVs." >> >> in section 7.3.2 it is mentioned >> >> " Error Report TLVs are those in the range 1 through 3. (Note that >> the obsoleted TLVs 4 and 5 may be considered in this category, but >> SHOULD NOT be used.) >> >> As stated above, when crankback information is reported, the IF_ID >> ERROR_SPEC object MUST be used. When the IF_ID ERROR_SPEC object is >> used, at least one of the TLVs in the range 1 through 3 MUST be >> present. The choice of which TLV to use will be dependent on the >> circumstance of the error and device capabilities. For example, a >> device that does not support IPv6 will not need the ability to >> create a TLV of type 2. Note, however, that such a device MUST >> still be prepared to receive and process all error report TLVs." >> >> in section 7.3.4 it is mentioned >> >> " It is left as an implementation detail precisely when to include >> each of the TLVs according to the capabilities of the system >> reporting the error." >> >> => would it be possible to harmonize these MUST, SHOULD, MAY, etc; >> ? one way to achieve this is by reducing repetitions and probably >> have 2 sub-sections instead of 4 > > Yes. > >> same comment in section 7.4.5 where it is mentioned >> >> "When the node gives up it must propagate the failure message >> further upstream and include crankback information when it does >> so." > > Same answer. > >> 11. section 8. >> >> " For example, when an intermediate LSR issues a PathErr message, >> the signaling module of the intermediate LSR should interact with >> the routing logic to determine the routing-protocol-specific link >> or node ID where the blockage or fault occurred and carry this >> information onto the Link TLV and Node TLV inside the IF_ID >> ERROR_SPEC object." >> >> -> Link TLV is not defined as part of the table ? would it be >> possible to list to which TLV you are referring to > > Yes. Means TLV 1, 2 or 3. > >> 12. section 9.1 >> >> " In a network segmented into areas, the following procedures can >> be used. As explained in Section 8.2, the LSP restoration behavior >> is indicated in the Flags field of the SESSION_ATTRIBUTE object of >> the Path message. If the Flags indicate "End-to-end re-routing", >> the PathErr message is returned all the way back to the ingress >> LSR, which may then issue a new Path message along another path, >> which is the same procedure as in the flat network case above." >> >> -> why do you make use of the session attribute since section 6.4 >> mentions usage of lsp attribute object > > Ditto, above. > >> editorial --------- >> >> 1. title >> >> "Crankback Signaling Extensions for MPLS and GMPLS Signaling" >> >> is probably redundant i would suggest (but leave this at your >> discretion) >> >> "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE" > > OK > >> 2. section 2.2 >> >> alignment with P&R terminology and concepts would be advisable >> > > OK. Anything specific or do we just need to do a general parse? -> adapt terminology (use the term protecting instead of backup, use the term protected or working instead of primary, etc.) and concepts (e.g. prefer the term "recovery" rather than restoration in the sentence "... various restoration schemes for link or node failures ..."; prefer the term "re-routing" rather than restoration in the sentence "... and include fast restoration.", etc.) >> 3. section 4.2 >> >> "On the other hand, in a network partitioned into areas such as >> with hierarchical OSPF,..." >> >> why "hierarchical OSPF" and not simply "OSPF" > > Because we like adding the word "hierarchical" at every oportunity > :-) > >> 4. section 5. - point 3) >> >> instead of "... (particularly in the GMPLS context)," >> >> I guess you mean for non-PSC LSP ? > > You guess correctly. Will tidy this. > >> 5. section 7.2 >> >> "IF_ID PHOP" -> IF_ID RSVP_HOP ? > > Yes. > >> 6. section 7.2 >> >> " Node Identifiers: >> >> A sequence of TLVs as defined here of types 1, 2 or 8 that >> indicates downstream nodes that have already participated in >> crankback attempts and have been declared unusable for the current >> LSP setup attempt." >> >> type 1, 2 does not define nodes in the proposed table ? > > Not sure about this. Your point is valid, but it is also the case > that one may identify a node by one of its interfaces. Thus it may be > convenient to simply put the list of failed interfaces into this TLV and > thus identify the list of nodes that have failed to perform crankback. > > I guess we need a little input from the implementers on this point. -> you would need feedback from people having implemented this with numbered i/fs (from my side, crankback has been experimented for unnumbered id) but this is indeed a common trick - so you would probably need to insert a hint here - >> 7. section 8 >> >> " The ingress LSR, upon receiving the error message, should >> interact with the routing logic to compute an alternate path by >> pruning the specified link ID or node ID in the routing database." >> >> i guess "node ID" refers to Router ID ? > > Well, "TE Router ID". And, of course, "Routing database" should read > "Traffic Engineering Database". > >> also do no provide the exact pointer for TE Router ID and Router ID >> in the IS-IS context > > Yup. I think by using TE Router ID we are covered in the IS-IS case, > and we just need to update the text to identify the exact field. > >> hope this will help > > > It does, a lot. > > Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Apr 5 05:01:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25417 for ; Tue, 5 Apr 2005 05:01:16 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIk46-0008BI-8R for ccamp-archive@ietf.org; Tue, 05 Apr 2005 05:09:42 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIjjX-0001zJ-Vh for ccamp-data@psg.com; Tue, 05 Apr 2005 08:48:27 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIjjW-0001z2-CL; Tue, 05 Apr 2005 08:48:26 +0000 Message-ID: <425250D8.8050809@psg.com> Date: Tue, 05 Apr 2005 10:48:24 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adrian Farrel CC: kireeti Kompella , Cheng-Yin.Lee@alcatel.com, stefaan.de_cnodder@alcatel.be, "ccamp@ops.ietf.org" Subject: Re: WG last calls - comments on draft-ietf-ccamp-rsvp-te-exclude-route-03.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: 7bit hi adrian, some comments here below on the exclude route i-d technical --------- 1. section 2.1 "Constrained Shortest Path First (CSPF) computation at Ingress, so the ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, AB2-strict, Egress-loose) and (B1, B2, BC1, C1, C2) respectively." AB1 should also be excluded as AB2 does not know the first path crosses this node so there may be a case (in this example for inst. imagine there is no link between AB2 and B3) where this could lead to overlap if AB2 selects an area B link to reach AB1 2. section 4 "The exclude route identifies a list of abstract nodes that MUST NOT be traversed along the path of the LSP being established." while section 4.1 " The concept of loose or strict hops has no meaning in route exclusion. The L bit, defined for ERO subobjects in [RSPV-TE], is reused here to indicate that an abstract node MUST be avoided (value 0) or SHOULD be avoided (value 1)." 3. section 4.1 "The subobjects are identical to those defined in [RFC3209] and [RFC3473] for use in EROs." looking at the definitions this is not the case (moreover the SRLG subobject has been added) - 4. section 4.1 " An Attribute octet is introduced in the subobjects that define IP addresses to indicate the attribute (e.g. interface, node, SRLG) associated with the IP addresses that can be excluded from the path." what is a subobject that define IP addresses ? 5. section 4.1 " For instance, the attribute node allows a whole node to be excluded from the path, in contrast to the attribute interface, which allows specific interfaces to be excluded from the path. " but below the definition says "0 indicates that the interface or set of interfaces associated with the IP prefix should be excluded or avoided" which makes the term specific ambiguous 6. section 4.1.5 " node 1 indicates that the node with the Router ID should be excluded or avoided (this can be achieved using IPv4/v6 subobject as well, but is included here because it may be convenient to use subobjects from RRO, in specifying the exclusions)" until "(this can be achieved using IPv4/v6 subobject" i understand after i would ask you to clarify i guess you mean RRO from another path ? should you include this as part of the definition ? 7. section 4.2 - condition 1. what does happen when the L flag is not set and the condition is not verified ? 8. section 4.2 - condition 3. "If they do contradict, the subobjects with the L flag not set, strict or MUST be excluded, respectively, in the ERO or XRO MUST take precedence." this sentence is cryptic i put in the technical part because it impacts understanding concerning the exact processing 9. section 4.2 - condition 4. "The number of introduced SLRGs with the L flag set to "avoid" should be minimised." i guess you mean wrt to the number of "exclude" SRLGs (blocking) ? or is there an absolute limitation due to the message size 10. section 4.2 - concerning the operations i would suggesting adding a rule suggesting that no contradicting exclusions get inserted 11. section 5. "The Explicit Exclude Route defines abstract nodes or resources (such as links, unnumbered interfaces or labels) that must not be used on the path between two inclusive abstract nodes or resources in the explicit route." ... "must" while the L bit means either "avoid" or "exclude" 12. section 5.1 " A new ERO subobject type is defined. The Explicit Exclude Route Subobject (EXRS) has type [TBD]. The EXRS may not be present in an RRO or XRO." would you clarify the meaning of the second sentence in the context of the first one ? (note: the doc. since far tells the reader that the EXRS is an ERO subobject) 13. section 5.1 " Note: The Most Significant Bit in the Type field could be used to indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating the need to prepend the subobject with an additional TLV header. This would reduce the number bytes require for each subobject by 2 bytes. However, this approach would reduce the ERO Type field space by half. This issue need WG discussion and feedback." -> i would suggest keeping existing definition (since the EXRS is to considered as an optimization), this said better formalization of the EXRS subobjects needs to be provided - as the next section mentions "Each EXRS may carry multiple exclusions. The exclusion is encoded exactly as for XRO subobjects and prefixed by an additional Type and Length." while with the provided alignment it looks like each exclusion element is encoded with this double Type/Length field note that section 5. would probably require a revision after completion of the technical details 14. section 6. " 2. The EXRS SHOULD be supported. If supported, the same restrictions as for the XRO apply." -> the EXRS is an optimization it should not be considered as a should but optional ie MAY 15. there is nothing said concerning usage of EXRS when using XRO ? editorial --------- 1. section 2. and onward why referring to a "Explicit Exclude Route" and then to a "5.1 Explicit Exclusion Route Subobject (EXRS)" and not a "Explicit Exclude Route Subobject (EXRS)" ? -> the document would benefit from using a single term either "exclude" or "exclusion" 2. section 2. " This subobject might also be appropriate for use within Explicit Routes or Record Routes, but that discussion is outside the scope of this document." would suggest replace this sentence with "This document does not assume or preclude any other usage for this subobject." 3. section 2. "A new subobject type the Explicit Exclude Route Subobject (EXRS) is introduced to indicate an exclusion between a pair of included abstract nodes." would complete the last part of the sentence (as i guess you mean of the ERO in the present context) 4. why section 3.1 is defined as "SRLG ERO Subobject" i think this should better be defined as an "SRLG Subobject" as i do not see a specific reason for having an SRLG subobject outside of the XRO, EXRS context ? 5. Section 4.1.x - adapt IP address to IPv4 address when defining the IPv4 subobject, etc. 6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID, 7. section 5.1 ""Thus, an EXRO subobject for an IP hop might look as follows:..." ? what do you mean by might ? isn't EXRS instead of EXRO ? 8. section 5.1 "Both subobjects are as described earlier in this document." both (to which subobject do you refer here) ? 9 "5.2 Semantics and Processing Rules for the EXRS" -> "5.2 Processing Rules for the EXR Subobject and its Subobjects" 10. section 5.2 "If the presence of EXRO Subobjects precludes further forwarding of the Path message, the node should return a PathErr with the error code "Routing Problem" and error value of "Route blocked by Exclude Route"." you mean EXRS ? instead EXRO ? 11. section 5.2 "If a node is called upon to process an EXRS and does not support handling of exclusions it will return a PathErr with a "Bad EXPLICIT_ROUTE object" error." ... Routing Problem/Bad EXPLICIT_ROUTE object note that in general definition of the subobject field could be made a bit more explicit hope these comments will help you thanks, - dimitri. From owner-ccamp@ops.ietf.org Tue Apr 5 15:34:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24689 for ; Tue, 5 Apr 2005 15:34:31 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DItx0-0006XL-2K for ccamp-archive@ietf.org; Tue, 05 Apr 2005 15:43:02 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DItiJ-00008V-L0 for ccamp-data@psg.com; Tue, 05 Apr 2005 19:27:51 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DItiI-00008B-Fe for ccamp@ops.ietf.org; Tue, 05 Apr 2005 19:27:50 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23115; Tue, 5 Apr 2005 15:27:47 -0400 (EDT) Message-Id: <200504051927.PAA23115@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Date: Tue, 05 Apr 2005 15:27:47 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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 : RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Author(s) : J. Lang, et al. Filename : draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt Pages : 36 Date : 2005-4-5 This document describes protocol specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that is protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-5155955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-5155955.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Apr 5 15:34:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24763 for ; Tue, 5 Apr 2005 15:34:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DItxE-0006YV-Vp for ccamp-archive@ietf.org; Tue, 05 Apr 2005 15:43:17 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DItg0-000PzG-Sz for ccamp-data@psg.com; Tue, 05 Apr 2005 19:25:28 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DItfu-000Pyb-68 for ccamp@ops.ietf.org; Tue, 05 Apr 2005 19:25:22 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 08A1CE00012F; Tue, 5 Apr 2005 20:25:10 +0100 (BST) Received: from Puppy ([212.43.203.160] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 20:22:30 +0100 Message-ID: <16c901c53a15$10666f40$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Zhang Renhai" Cc: "Ash, Gerald R (Jerry), ALABS" , References: <9473683187ADC049A855ED2DA739ABCA060CE50E@KCCLUST06EVS1.ugd.att.com> <15e901c537af$d846cbd0$dccb2bd4@Puppy> <00a901c538f3$71e26d00$69646e0a@huawei.com> Subject: Re: WG last calls Date: Tue, 5 Apr 2005 20:11: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-OriginalArrivalTime: 05 Apr 2005 19:22:31.0549 (UTC) FILETIME=[D020BAD0:01C53A14] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Hi Zhang, There is certainly nothing to prevent your suggestion. This would be an implementation choice, although an operator would probably want to configure identical behavior on all crankback-capable LSRs in the network. Adrian ----- Original Message ----- From: "Zhang Renhai" To: "Adrian Farrel" Cc: "Ash, Gerald R (Jerry), ALABS" ; Sent: Monday, April 04, 2005 9:51 AM Subject: Re: WG last calls > Hi, Adrian > In RFC 3209,LSP is provided with attribute of Priority(Setup Priority,Holding Priority), > so it is more reasonable to process different LSPs according to the Priority, for the LSP > with higher priority, more retry number should be given, lower priority with less number. > Extremely, to the highest LSP, can the interception be concelled by ABR?(although multi LSPs > may be derived simultaneously, sellection can be done by egress on receiving Path massege > .So we can get another LSP with most possibility because of its highest priority) > > Just my suggestion. > > Regard, > Zhang > > > ----- Original Message ----- > From: "Adrian Farrel" > To: "Ash, Gerald R (Jerry), ALABS" ; "Zhang Renhai" ; ; "Kireeti Kompella" > Cc: "Ash, Gerald R (Jerry), ALABS" > Sent: Sunday, April 03, 2005 1:05 AM > Subject: Re: WG last calls > > > > Hi, > > > > Yes, to clarify what Jerry says, the number of crankback attempts MAY be > > limited. At the moment, the only way that we provide to limit the attempts > > is implemented per LSR. That is, any LSR MAY decide that it has performed > > enough attempts at rerouting and pass the error back to the upstream LSR. > > > > Note that the use of crankback to derive a path through a network is not > > recommended. This approach is almost equivalent to random walk routing and > > is neither efficient nor effective. > > > > The use of crankback, as described in the draft is intended for use in > > specific circumstances, such as inter-domain routing. In these cases only > > selective LSRs (such as domain boundaries) perform rerouting attempts. > > > > Adrian > > > > ----- Original Message ----- > > From: "Ash, Gerald R (Jerry), ALABS" > > To: "Zhang Renhai" ; "Adrian Farrel" > > ; ; "Kireeti Kompella" > > > > Cc: "Ash, Gerald R (Jerry), ALABS" > > Sent: Friday, April 01, 2005 2:02 PM > > Subject: RE: WG last calls > > > > > > Zhang, > > > > > From draft-ietf-ccamp-crankback-04.txt ,section 4.5, the > > > number of crankback rerouting is limited, so there will > > > be a result: there is another LSP,but for the reason of > > > limiting, the path may be not found. I think sometimes > > > it is unacceptable.The LSP may be prefered to enhancing > > > performance. > > > > This problem can be avoided by the setting the node retry threshold > > (configurable per node) very high (~infinity), so retries aren't > > limited. > > > > Thanks, > > Jerry > > > > > > > > > > > From owner-ccamp@ops.ietf.org Tue Apr 5 15:35:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25130 for ; Tue, 5 Apr 2005 15:35:45 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DItyB-0006eJ-9N for ccamp-archive@ietf.org; Tue, 05 Apr 2005 15:44:16 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DItg5-000Pzb-Br for ccamp-data@psg.com; Tue, 05 Apr 2005 19:25:33 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DItg2-000PzM-IQ for ccamp@ops.ietf.org; Tue, 05 Apr 2005 19:25:30 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 26FE7E000294; Tue, 5 Apr 2005 20:25:27 +0100 (BST) Received: from Puppy ([212.43.203.160] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 20:22:21 +0100 Message-ID: <16bd01c53a15$0b1f92f0$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Kohei Shiomoto" , "'Rajiv Papneja'" , "Richard Rabbat" Subject: Interoperability/Addressing Draft - Please read it Date: Mon, 4 Apr 2005 11:46:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 05 Apr 2005 19:22:21.0851 (UTC) FILETIME=[CA58EEB0:01C53A14] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48 autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Hi, The editors have produced a new version of this important draft which can be found at http://www.ietf.org/internet-drafts/draft-shiomoto-ccamp-gmpls-addressing-01.txt Please review this revision and send your comments to the list. Thanks, Adrian From owner-ccamp@ops.ietf.org Tue Apr 5 16:49:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15646 for ; Tue, 5 Apr 2005 16:49:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIv7h-0005mX-O9 for ccamp-archive@ietf.org; Tue, 05 Apr 2005 16:58:11 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIusu-0008Le-Ha for ccamp-data@psg.com; Tue, 05 Apr 2005 20:42:52 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DIuso-0008L2-9Z for ccamp@ops.ietf.org; Tue, 05 Apr 2005 20:42:46 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 61A56E0001C7 for ; Tue, 5 Apr 2005 21:42:36 +0100 (BST) Received: from Puppy ([212.43.203.74] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 21:32:36 +0100 Message-ID: <175101c53a1e$dbeed720$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: Enforcement of Updated IPR Boilerplate Date: Tue, 5 Apr 2005 21:19:48 +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: 05 Apr 2005 20:32:37.0866 (UTC) FILETIME=[9B49C4A0:01C53A1E] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Please be aware and update your new draft submissions accordingly. Adrian ----- Original Message ----- From: "IETF Secretariat" To: "IETF Announcement list" Sent: Monday, April 04, 2005 6:05 PM Subject: Enforcement of Updated IPR Boilerplate > As you may be aware, RFC 3667 (BCP 78), "IETF Rights in Contributions," > has been obsoleted by RFC 3978 (BCP 78), which was published in March > 2005, and which bears the same title. The major difference between the > two RFCs is that the IPR-related notices and disclaimers that the IETF > requires in all Internet-Drafts have been updated to correct anomalies. > > The updated versions of the required notices and disclaimers are specified > in Section 5, "Notices Required in IETF Documents," of RFC 3978, and in > Section 3, "IPR-Related Notices Required in Internet-Drafts," of the > recently revised "Guidelines to Authors of Internet-Drafts" > (http://www.ietf.org/ietf/1id-guidelines.html). The "Guidelines" document > also provides additional guidance regarding the placement of these notices. > > Currently, the IETF Secretariat accepts and posts Internet-Drafts that > include *either* the RFC 3667 or the RFC 3978 version of these notices. > However, as of 17:00 ET on Friday May 6, 2005, the Secretariat will > accept *only* those Internet-Drafts that comply with the requirements > of RFC 3978, and with the most recent version of the "Guidelines" > document. > > Please note that the required notices and disclaimers must be reproduced > verbatim since they have been legally reviewed and formally adopted as part > of the IETF process. The Secretariat will not accept deviations from the > specified text, nor will it correct the text. Any documents that do not > comply with the requirements will be returned to the submitter. > > The IETF Secretariat From owner-ccamp@ops.ietf.org Tue Apr 5 17:17:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18182 for ; Tue, 5 Apr 2005 17:17:58 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIvZ8-0006qX-3k for ccamp-archive@ietf.org; Tue, 05 Apr 2005 17:26:31 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DIvM6-000B5W-Gk for ccamp-data@psg.com; Tue, 05 Apr 2005 21:13:02 +0000 Received: from [66.129.224.36] (helo=kummer.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DIvM5-000B5J-LJ for ccamp@ops.ietf.org; Tue, 05 Apr 2005 21:13:01 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j35LCuXg006894; Tue, 5 Apr 2005 14:12:56 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j35LCuL8006891; Tue, 5 Apr 2005 14:12:56 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Tue, 5 Apr 2005 14:12:55 -0700 (PDT) From: Kireeti Kompella To: Adrian Farrel cc: ccamp@ops.ietf.org Subject: Re: Fw: Enforcement of Updated IPR Boilerplate In-Reply-To: <175101c53a1e$dbeed720$dccb2bd4@Puppy> Message-ID: <20050405141135.F5370@kummer.juniper.net> References: <175101c53a1e$dbeed720$dccb2bd4@Puppy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de On Tue, 5 Apr 2005, Adrian Farrel wrote: > Please be aware and update your new draft submissions accordingly. For those using xml2rfc, there is a new version that has the new boilerplate. Kireeti. ------- From owner-ccamp@ops.ietf.org Tue Apr 5 23:01:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15913 for ; Tue, 5 Apr 2005 23:01:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ0vg-0001oy-7R for ccamp-archive@ietf.org; Tue, 05 Apr 2005 23:10:10 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ0gw-000JES-Pl for ccamp-data@psg.com; Wed, 06 Apr 2005 02:54:54 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ0gs-000JD6-Ih for ccamp@ops.ietf.org; Wed, 06 Apr 2005 02:54:50 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IEI009XC7XOZQ@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 05 Apr 2005 19:51:24 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IEI00EQS7XNV8@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 05 Apr 2005 19:51:24 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Wed, 06 Apr 2005 10:55:21 +0800 Date: Wed, 06 Apr 2005 10:55:21 +0800 From: Amit 70405 Subject: Re: Regarding Reversion To: ccamp@ops.ietf.org Message-id: <10486b10559e.10559e10486b@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7BIT Hi All, Can anybody plz clarify. Thanks in advance. Regards, Amit. From Amit 70405 Sent Monday, April 4, 2005 9:53 am To Dimitri.Papadimitriou@alcatel.be Cc ccamp@ops.ietf.org Bcc Subject Re: Regarding Reversion Hi Dimitri, I saw the details mentioned by you about this in another draft abot e2e recovery. So the LSP deletion is based on Reresh messages in reversion. But what will be the case in below scenarios: 1. if there is a dwonstream node fails. In this case refresh messages too will get affected. 2. if the signaling is in-band and the outif(as I mentioned in my previous mail) goes down. And there is no other interface to get the refresh messages. In both these scenarios, as refresh does not happen, the LSP should get deleted. Plz confirm if this is right. Or are you going to do some self-refresh kind of for infinite duration. Duration should be infinite as recovery of failure may take time. This self refresh has to be till failure recovers or till you again start getting the refresh messages. Or the State gets explicitly deleted by head end. Plz let me know your view. Thanks and Regards, Amit. From Dimitri.Papadimitriou@alcatel.be Sent Friday, April 1, 2005 7:51 pm To Amit 70405 Cc Dimitri.Papadimitriou@alcatel.be , ccamp@ops.ietf.org Bcc Subject Re: Regarding Reversion amit, upon data plane failure there is no such behaviour as you mention - local data plane failure detection does not imply state deletion and common PathErr/ResvErr do not trigger any state deletion nor does a Notify; in particular, in the present context where one do assume control plane availability even in case of data plane failure - note: details of it available in other documents - states can be kept refreshed Amit 70405 Sent by: owner-ccamp@ops.ietf.org 04/01/2005 17:51 ZE8 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: ccamp@ops.ietf.org bcc: Subject: Re: Regarding Reversion Hi, Thanks for replying. According to the statement I mentioned from the draft, I understand that, if there is a failure the old working LSP should not be deleted. But not only for RSVP, for any MPLS Signaling protocol, it is mandatory that when a failure happens, you should start tearing down the LSP. Take for instance if a OutInterface(on which LSP is setup) goes down. Protocol will lead to LSP deletion. Plz correct me if I am wrong. Regards, Amit. From Dimitri.Papadimitriou@alcatel.be Sent Friday, April 1, 2005 5:24 pm To Amit 70405 Cc ccamp@ops.ietf.org Bcc Subject Re: Regarding Reversion hi - would you please clarify your comment - to which potential violation do you refer ? in particular this specification being functional specific details concerning realization using RSVP are provided in the end-to-end signaling document Amit 70405 Sent by: owner-ccamp@ops.ietf.org 04/01/2005 14:39 ZE8 To: ccamp@ops.ietf.org cc: bcc: Subject: Regarding Reversion Hi, In the draft draft-ietf-ccamp-gmpls-recovery-functional-04.txt, in the section about Reversion. It is said: "Reversion implies that a working path remains allocated to the LSP that was originally routed over it even after a failure." This requirement may hold true for non-PSC networks, and may not be required in PSC. How can RSVP support this?? I mean it may totally violate RSVP-TE standard. As though the failure has happened and LSP should not be deleted. Plz let me know your view on this. Regards, Amit. From owner-ccamp@ops.ietf.org Wed Apr 6 04:02:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12164 for ; Wed, 6 Apr 2005 04:02:06 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ5cZ-0003T5-KX for ccamp-archive@ietf.org; Wed, 06 Apr 2005 04:10:44 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ5KG-000Nom-T2 for ccamp-data@psg.com; Wed, 06 Apr 2005 07:51:48 +0000 Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ5KC-000Nnl-Gn for ccamp@ops.ietf.org; Wed, 06 Apr 2005 07:51:45 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j367pM9B026363; Wed, 6 Apr 2005 09:51:22 +0200 To: Amit 70405 Cc: ccamp@ops.ietf.org MIME-Version: 1.0 From: Dimitri.Papadimitriou@alcatel.be Subject: Re: Regarding Reversion Date: Wed, 6 Apr 2005 09:51:19 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 04/06/2005 09:51:22 MIME-Version: 1.0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_20_30, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_BASE64_TEXT,MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 4.8 (++++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: base64 PFA+YW1pdCwgPC9QPjxQPnVwb24gY29udHJvbCBwbGFuZSBmYWlsdXJlIHlvdSBhcHBseSB0aGUg bWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA5IG9mIFJGQyAzNDczIHRoYXQgYWxsb3dz IHJlY292ZXJ5IHdoZW4gdGhlIGRhdGEgcGxhbmUgaGFzIHJldGFpbmVkIHRoZSBmb3J3YXJkaW5n IHN0YXRlIGFjcm9zcyBhIHJlc3RhcnQgKHRoaXMgY292ZXJzIHRoZSBjYXNlIHlvdSBtZW50aW9u IGhlcmUgYmVsb3cgd2hlbiBjb250cm9sIGNoYW5uZWwgaXMgdW5kZXIgZmFpbHVyZSksIGluIGNh c2Ugb2Ygc291cmNlIG5vZGFsIGZhaWx1cmUgeW91IGFwcGx5IHRoZSBleHRlbmRlZCByZXN0YXJ0 IG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gJmx0O2RyYWZ0LWlldGYtY2NhbXAtcnN2cC1yZXN0YXJ0 LWV4dC0wMi50eHQmZ3Q7ID0mZ3Q7IHRoZSBMU1AgaXMgbm90IGRlbGV0ZWQgKGlmIHRoaXMgeW91 ciBxdWVzdGlvbiksIGluIHRoZSBvdGhlciB3YXkgYXJvdW5kIHRoZXJlIGlzIG5vIHNwZWNpZmlj IGlzc3VlIGFzIHJlc291cmNlcyBhcmUgcmV0YWluZWQgYW5kIHRoZSBMU1AgcmVmcmVzaGVkIHVu dGlsIGRhdGEgcGxhbmUgZmFpbHVyZSBpcyByZWNvdmVyZWQ8QlI+PEJSPjxGT05UIFNJWkU9Mj48 Qj5BbWl0IDcwNDA1ICZsdDtBbWl0R0BodWF3ZWkuY29tJmd0OzwvQj48L0ZPTlQ+PEJSPjxGT05U IFNJWkU9Mj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8L0ZPTlQ+PEJSPjxGT05U IFNJWkU9Mj4wNC8wNi8yMDA1IDEwOjU1IFpFODwvRk9OVD48QlI+PEJSPiA8Rk9OVCBTSVpFPTI+ VG86PC9GT05UPiA8Rk9OVCBTSVpFPTI+Y2NhbXBAb3BzLmlldGYub3JnPC9GT05UPjxCUj4gPEZP TlQgU0laRT0yPmNjOjwvRk9OVD4gPEJSPiA8Rk9OVCBTSVpFPTI+YmNjOjwvRk9OVD4gPEJSPiA8 Rk9OVCBTSVpFPTI+U3ViamVjdDo8L0ZPTlQ+IDxGT05UIFNJWkU9Mj5SZTogUmVnYXJkaW5nIFJl dmVyc2lvbjwvRk9OVD48QlI+IDxCUj48QlI+PC9QPjxQPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD b3VyaWVyIj5IaSBBbGwsPEJSPkNhbiBhbnlib2R5IHBseiBjbGFyaWZ5LjxCUj5UaGFua3MgaW4g YWR2YW5jZS48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5SZWdhcmRz LDxCUj5BbWl0LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5G cm9tICZuYnNwOyBBbWl0IDcwNDA1ICZsdDtBbWl0R0BodWF3ZWkuY29tJmd0OzxCUj5TZW50ICZu YnNwO01vbmRheSwgQXByaWwgNCwgMjAwNSA5OjUzIGFtPEJSPlRvICZuYnNwO0RpbWl0cmkuUGFw YWRpbWl0cmlvdUBhbGNhdGVsLmJlPEJSPkNjICZuYnNwO2NjYW1wQG9wcy5pZXRmLm9yZzxCUj5C Y2M8QlI+U3ViamVjdCAmbmJzcDtSZTogUmVnYXJkaW5nIFJldmVyc2lvbjxCUj48L0ZPTlQ+PEJS PjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5IaSBEaW1pdHJpLDxCUj5JIHNhdyB0aGUg ZGV0YWlscyBtZW50aW9uZWQgYnkgeW91IGFib3V0IHRoaXMgaW4gYW5vdGhlciBkcmFmdCBhYm90 IGUyZSByZWNvdmVyeS48QlI+U28gdGhlIExTUCBkZWxldGlvbiBpcyBiYXNlZCBvbiBSZXJlc2gg bWVzc2FnZXMgaW4gcmV2ZXJzaW9uLjxCUj5CdXQgd2hhdCB3aWxsIGJlIHRoZSBjYXNlIGluIGJl bG93IHNjZW5hcmlvczo8QlI+MS4gaWYgdGhlcmUgaXMgYSBkd29uc3RyZWFtIG5vZGUgZmFpbHMu IEluIHRoaXMgY2FzZSByZWZyZXNoIG1lc3NhZ2VzIHRvbyB3aWxsIGdldCBhZmZlY3RlZC48QlI+ Mi4gaWYgdGhlIHNpZ25hbGluZyBpcyBpbi1iYW5kIGFuZCB0aGUgb3V0aWYoYXMgSSBtZW50aW9u ZWQgaW4gbXkgcHJldmlvdXMgbWFpbCkgZ29lcyBkb3duLiBBbmQgdGhlcmUgaXMgbm8gb3RoZXIg aW50ZXJmYWNlIHRvIGdldCB0aGUgcmVmcmVzaCBtZXNzYWdlcy48L0ZPTlQ+PEJSPjwvUD48VUw+ PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkluIGJvdGggdGhlc2Ugc2NlbmFyaW9zLCBh cyByZWZyZXNoIGRvZXMgbm90IGhhcHBlbiwgdGhlIExTUCBzaG91bGQgZ2V0IGRlbGV0ZWQuPEJS PjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPlBseiBjb25maXJtIGlm IHRoaXMgaXMgcmlnaHQuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJp ZXIiPk9yIGFyZSB5b3UgZ29pbmcgdG8gZG8gc29tZSBzZWxmLXJlZnJlc2gga2luZCBvZiBmb3Ig aW5maW5pdGUgZHVyYXRpb24uPEJSPkR1cmF0aW9uIHNob3VsZCBiZSBpbmZpbml0ZSBhcyByZWNv dmVyeSBvZiBmYWlsdXJlIG1heSB0YWtlIHRpbWUuPEJSPlRoaXMgc2VsZiByZWZyZXNoIGhhcyB0 byBiZSB0aWxsIGZhaWx1cmUgcmVjb3ZlcnMgb3IgdGlsbCB5b3UgYWdhaW4gc3RhcnQgZ2V0dGlu ZyB0aGUgcmVmcmVzaCBtZXNzYWdlcy4gT3IgdGhlIFN0YXRlIGdldHMgZXhwbGljaXRseSBkZWxl dGVkIGJ5IGhlYWQgZW5kLjwvRk9OVD48QlI+PC9VTD48UD48Rk9OVCBGQUNFPSJNb25vc3BhY2Us Q291cmllciI+UGx6IGxldCBtZSBrbm93IHlvdXIgdmlldy48QlI+VGhhbmtzIGFuZCBSZWdhcmRz LDxCUj5BbWl0LjxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5G cm9tICZuYnNwOyBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTxCUj5TZW50ICZuYnNw O0ZyaWRheSwgQXByaWwgMSwgMjAwNSA3OjUxIHBtPEJSPlRvICZuYnNwO0FtaXQgNzA0MDUgJmx0 O0FtaXRHQGh1YXdlaS5jb20mZ3Q7PEJSPkNjICZuYnNwO0RpbWl0cmkuUGFwYWRpbWl0cmlvdUBh bGNhdGVsLmJlICwgY2NhbXBAb3BzLmlldGYub3JnPEJSPkJjYzxCUj5TdWJqZWN0ICZuYnNwO1Jl OiBSZWdhcmRpbmcgUmV2ZXJzaW9uPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNl LENvdXJpZXIiPmFtaXQsIHVwb24gZGF0YSBwbGFuZSBmYWlsdXJlIHRoZXJlIGlzIG5vIHN1Y2gg YmVoYXZpb3VyIGFzIHlvdSBtZW50aW9uIC0gbG9jYWwgZGF0YSBwbGFuZSBmYWlsdXJlIGRldGVj dGlvbiBkb2VzIG5vdCBpbXBseSBzdGF0ZSBkZWxldGlvbiBhbmQgY29tbW9uIFBhdGhFcnIvUmVz dkVyciBkbyBub3QgdHJpZ2dlciBhbnkgc3RhdGUgZGVsZXRpb24gbm9yIGRvZXMgYSBOb3RpZnk7 IGluIHBhcnRpY3VsYXIsIGluIHRoZSBwcmVzZW50IGNvbnRleHQgd2hlcmUgb25lIGRvIGFzc3Vt ZSBjb250cm9sIHBsYW5lIGF2YWlsYWJpbGl0eSBldmVuIGluIGNhc2Ugb2YgZGF0YSBwbGFuZSBm YWlsdXJlIC0gbm90ZTogZGV0YWlscyBvZiBpdCBhdmFpbGFibGUgaW4gb3RoZXIgZG9jdW1lbnRz IC0gc3RhdGVzIGNhbiBiZSBrZXB0IHJlZnJlc2hlZDxCUj48L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9 Ik1vbm9zcGFjZSxDb3VyaWVyIj5BbWl0IDcwNDA1ICZsdDtBbWl0R0BodWF3ZWkuY29tJmd0OzxC Uj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8QlI+MDQvMDEvMjAwNSAxNzo1MSBa RTg8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VG86IERpbWl0 cmkgUEFQQURJTUlUUklPVS9CRS9BTENBVEVMQEFMQ0FURUw8QlI+Y2M6IGNjYW1wQG9wcy5pZXRm Lm9yZzxCUj5iY2M6PEJSPlN1YmplY3Q6IFJlOiBSZWdhcmRpbmcgUmV2ZXJzaW9uPEJSPjwvRk9O VD48QlI+PEJSPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkhpLDxCUj5U aGFua3MgZm9yIHJlcGx5aW5nLjxCUj48L0ZPTlQ+PEJSPjxCUj48Rk9OVCBGQUNFPSJNb25vc3Bh Y2UsQ291cmllciI+QWNjb3JkaW5nIHRvIHRoZSBzdGF0ZW1lbnQgSSBtZW50aW9uZWQgZnJvbSB0 aGUgZHJhZnQsIEkgdW5kZXJzdGFuZCB0aGF0LCBpZiB0aGVyZSBpcyBhIGZhaWx1cmUgdGhlIG9s ZCB3b3JraW5nIExTUCBzaG91bGQgbm90IGJlIGRlbGV0ZWQuPEJSPjwvRk9OVD48QlI+PEZPTlQg RkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkJ1dCBub3Qgb25seSBmb3IgUlNWUCwgZm9yIGFueSBN UExTIFNpZ25hbGluZyBwcm90b2NvbCwgaXQgaXMgbWFuZGF0b3J5IHRoYXQgd2hlbiBhIGZhaWx1 cmUgaGFwcGVucywgeW91IHNob3VsZCBzdGFydCB0ZWFyaW5nIGRvd24gdGhlIExTUC48QlI+PC9G T05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3BhY2UsQ291cmllciI+VGFrZSBmb3IgaW5zdGFuY2Ug aWYgYSBPdXRJbnRlcmZhY2Uob24gd2hpY2ggTFNQIGlzIHNldHVwKSBnb2VzIGRvd24uPEJSPlBy b3RvY29sIHdpbGwgbGVhZCB0byBMU1AgZGVsZXRpb24uPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFD RT0iTW9ub3NwYWNlLENvdXJpZXIiPlBseiBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcuPEJSPlJl Z2FyZHMsPEJSPkFtaXQuPEJSPjwvRk9OVD48QlI+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxD b3VyaWVyIj5Gcm9tICZuYnNwOyBEaW1pdHJpLlBhcGFkaW1pdHJpb3VAYWxjYXRlbC5iZTxCUj5T ZW50ICZuYnNwO0ZyaWRheSwgQXByaWwgMSwgMjAwNSA1OjI0IHBtPEJSPlRvICZuYnNwO0FtaXQg NzA0MDUgJmx0O0FtaXRHQGh1YXdlaS5jb20mZ3Q7PEJSPkNjICZuYnNwO2NjYW1wQG9wcy5pZXRm Lm9yZzxCUj5CY2M8QlI+U3ViamVjdCAmbmJzcDtSZTogUmVnYXJkaW5nIFJldmVyc2lvbjxCUj48 L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5oaSAtIHdvdWxkIHlvdSBw bGVhc2UgY2xhcmlmeSB5b3VyIGNvbW1lbnQgLSB0byB3aGljaCBwb3RlbnRpYWwgdmlvbGF0aW9u IGRvIHlvdSByZWZlciA/IGluIHBhcnRpY3VsYXIgdGhpcyBzcGVjaWZpY2F0aW9uIGJlaW5nIGZ1 bmN0aW9uYWwgc3BlY2lmaWMgZGV0YWlscyBjb25jZXJuaW5nIHJlYWxpemF0aW9uIHVzaW5nIFJT VlAgYXJlIHByb3ZpZGVkIGluIHRoZSBlbmQtdG8tZW5kIHNpZ25hbGluZyBkb2N1bWVudDxCUj48 L0ZPTlQ+PEJSPjxGT05UIEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5BbWl0IDcwNDA1ICZsdDtB bWl0R0BodWF3ZWkuY29tJmd0OzxCUj5TZW50IGJ5OiBvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmc8 QlI+MDQvMDEvMjAwNSAxNDozOSBaRTg8QlI+PC9GT05UPjxCUj48Rk9OVCBGQUNFPSJNb25vc3Bh Y2UsQ291cmllciI+VG86IGNjYW1wQG9wcy5pZXRmLm9yZzxCUj5jYzo8QlI+YmNjOjxCUj5TdWJq ZWN0OiBSZWdhcmRpbmcgUmV2ZXJzaW9uPEJSPjwvRk9OVD48QlI+PEJSPjxGT05UIEZBQ0U9Ik1v bm9zcGFjZSxDb3VyaWVyIj5IaSw8QlI+SW4gdGhlIGRyYWZ0IGRyYWZ0LWlldGYtY2NhbXAtZ21w bHMtcmVjb3ZlcnktZnVuY3Rpb25hbC0wNC50eHQsIGluIHRoZSBzZWN0aW9uIGFib3V0IFJldmVy c2lvbi48QlI+PC9GT05UPjxCUj48QlI+PEZPTlQgRkFDRT0iTW9ub3NwYWNlLENvdXJpZXIiPkl0 IGlzIHNhaWQ6PEJSPiZxdW90O1JldmVyc2lvbiBpbXBsaWVzIHRoYXQgYSB3b3JraW5nIHBhdGgg cmVtYWlucyBhbGxvY2F0ZWQgdG8gdGhlIExTUCB0aGF0PEJSPndhcyBvcmlnaW5hbGx5IHJvdXRl ZCBvdmVyIGl0IGV2ZW4gYWZ0ZXIgYSBmYWlsdXJlLiZxdW90OzxCUj48L0ZPTlQ+PEJSPjxGT05U IEZBQ0U9Ik1vbm9zcGFjZSxDb3VyaWVyIj5UaGlzIHJlcXVpcmVtZW50IG1heSBob2xkIHRydWUg Zm9yIG5vbi1QU0MgbmV0d29ya3MsIGFuZCBtYXkgbm90IGJlIHJlcXVpcmVkIGluIFBTQy48QlI+ SG93IGNhbiBSU1ZQIHN1cHBvcnQgdGhpcz8/IEkgbWVhbiBpdCBtYXkgdG90YWxseSB2aW9sYXRl IFJTVlAtVEUgc3RhbmRhcmQuPEJSPkFzIHRob3VnaCB0aGUgZmFpbHVyZSBoYXMgaGFwcGVuZWQg YW5kIExTUCBzaG91bGQgbm90IGJlIGRlbGV0ZWQuPEJSPjwvRk9OVD48QlI+PEZPTlQgRkFDRT0i TW9ub3NwYWNlLENvdXJpZXIiPlBseiBsZXQgbWUga25vdyB5b3VyIHZpZXcgb24gdGhpcy48QlI+ UmVnYXJkcyw8QlI+QW1pdC48QlI+PC9GT05UPjxCUj48QlI+PC9QPg== From owner-ccamp@ops.ietf.org Wed Apr 6 06:07:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22259 for ; Wed, 6 Apr 2005 06:07:07 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ7ZU-0007zJ-J9 for ccamp-archive@ietf.org; Wed, 06 Apr 2005 06:15:46 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJ7Hp-000COV-Ci for ccamp-data@psg.com; Wed, 06 Apr 2005 09:57:25 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJ7HD-000CKG-VT for ccamp@ops.ietf.org; Wed, 06 Apr 2005 09:57:24 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IEI00H5ZP2U1K@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 06 Apr 2005 02:01:42 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IEI00MOYP2SIG@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Wed, 06 Apr 2005 02:01:42 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Wed, 06 Apr 2005 17:05:39 +0800 Date: Wed, 06 Apr 2005 17:05:39 +0800 From: Amit 70405 Subject: Re: Regarding Reversion To: Dimitri.Papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org Message-id: <13108213495d.13495d131082@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_jlL27lHPPHdyZhwcM8dQqw)" Content-language: en X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_50, MIME_QP_LONG_LINE,UPPERCASE_25_50 autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 This is a multi-part message in MIME format. --Boundary_(ID_jlL27lHPPHdyZhwcM8dQqw) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT Hi Dimitri, Thanks a lot for replying. But depending on GR may lead to below problems: - For all the LSP's, on restart(or failure) a notification MAY be sent to the upstream of the LSP about the failure. And if the upstream(Ingress) decides to delete the LSP, then upstream MAY only delete it till the restarted node. Downstream to the Retarted node the LSP will continue to exist as result of GR process till the GR completes. - And if a restarting node or the neighbor node doesnt support GR than it will not be possible to retain the LSP. Yes but I agree with you that GR can be used for Reversion. Thanks a lot again. Regards, Amit. --Boundary_(ID_jlL27lHPPHdyZhwcM8dQqw) Content-type: message/rfc822 Content-disposition: inline MIME-version: 1.0 Content-type: TEXT/PLAIN Content-Transfer-Encoding: QUOTED-PRINTABLE E*n*zZ*0***q****"z***^q**y***hnk*r***m*****'tB4*F-*T*****6*xnk*r**y*: ***Nu**7**<*@*M*z+*u*******7*{3***)**m*****<`kM*******h*********"*** ***a**X**n[*)m1***M8*+a#>'tB4***3M*B****7*xnk*r**y*:***Nu**u**<*@*M*z+ *u****r***(*^;**:*****x****z'(*#*jw*1*,j**'*****z-,u****[Lj***N0**DH** ***4*wP*****Ch*=***jj]j***(*g***)*m4*N***>*M4E****~*&*****u**^*****jW **_****(****&**1*n8*Z*x***C'***M =C4d=F4=E5B=054=95=A4S=D3#=E6&63=A3=C2=F4d=F4=E5C=E2=03=C4%#=E2=03= =C4d=F4=E5B=054=95=A4S=D3#=E57V&=A6V7C=A3=C2=F4d=F4=E5C=E2=03=C4d= =F4=E5B=054=95=A4S=D3#=E5&S=A2=05&Vv=17&F=96=E6r=05&WfW'6=96=F6=E3= =C2=F4d=F4=E5C=E3=C4%#=E2=03=C4%#=E3=C4%#=E3=C2=F5=03=E3=C5=03=E3= =C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=86= =92=04=16=C6=C2=C3=C4%#=E46=16=E2=06=16=E7=96&=F6G=92=07=06=C7=A2= =066=C6=17&=96g=92=E3=C4%#=E5F=86=16=E6=B72=06=96=E2=06=16Gf=16=E66R= =E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77= =06=166R=C46=F7W&=96W"#=E5&Vv=17&G2=C3=C4%#=E4=16=D6=97B=E3=C4%#=E3= =C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06= =166R=C46=F7W&=96W"#=E4g&=F6=D2=02f=E6'7=03=B2=04=16=D6=97B=03s=03C= =03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=92=E66=F6=D2fwC=B3=C4%#=E56V= =E7B=02f=E6'7=03=B4=D6=F6=E6F=17=92=C2=04=17=07&=96=C2=03B=C2=03#= =03=03R=03=93=A3S2=06=16=D3=C4%#=E5F=F2=02f=E6'7=03=B4F=96=D6=97G&= =92=E5=06=17=06=16F=96=D6=97G&=96=F7T=06=16=C66=17FV=C2=E6&S=C4%#= =E462=02f=E6'7=03=B666=16=D7=04=06=F7=072=E6=96WFb=E6=F7&s=C4%#=E4&63= =C4%#=E57V&=A6V7B=02f=E6'7=03=B5&S=A2=05&Vv=17&F=96=E6r=05&WfW'6=96= =F6=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6= =F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=86=92=04F=96=D6=97G&=92=C3=C4%#= =E4=92=076=17r=07F=86R=06FWF=16=96=C72=06=D6V=E7F=96=F6=E6VB=06'=92= =07=96=F7R=06=16&=F7WB=07F=86=972=06=96=E2=06=16=E6=F7F=86W"=06G&= =16gB=06=16&=F7B=06S&R=07&V6=F7fW'=92=E3=C4%#=E56=F2=07F=86R=04=C55= =02=06FV=C6WF=96=F6=E2=06=972=06&=176VB=06=F6=E2=05&W&W6=82=06=D6W76= =16vW2=06=96=E2=07&WfW'6=96=F6=E2=E3=C4%#=E4'WB=07v=86=17B=07v=96= =C6=C2=06&R=07F=86R=066=176R=06=96=E2=06&V=C6=F7r=0766V=E6=17&=96= =F73=A3=C4%#=E3=12=E2=06=96b=07F=86W&R=06=972=06=12=06Gv=F6=E77G&V= =16=D2=06=E6=F6FR=06f=16=96=C72=E2=04=96=E2=07F=86=972=066=176R=07&Vg= &W6=82=06=D6W76=16vW2=07F=F6=F2=07v=96=C6=C2=06vWB=06=16ffV7FVB=E3= =C4%#=E3"=E2=06=96b=07F=86R=076=96v=E6=16=C6=96=E6r=06=972=06=96=E2= =D6&=16=E6B=06=16=E6B=07F=86R=06=F7WF=96b=86=172=04=92=06=D6V=E7F= =96=F6=E6VB=06=96=E2=06=D7=92=07=07&Wf=96=F7W2=06=D6=16=96=C2=92=06v= =F6W2=06F=F7v=E2=E2=04=16=E6B=07F=86W&R=06=972=06=E6=F2=06=F7F=86W"= =06=96=E7FW&f=166R=07F=F2=06vWB=07F=86R=07&V &W6=82=06=D6W76=16vW2=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C2=F5=03=E3=C5T= =C3=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#= =E4=96=E2=06&=F7F=82=07F=86W6R=0766V=E6=17&=96=F72=C2=06=172=07&Vg&W6= =82=06F=F6W2=06=E6=F7B=06=86=17=07=06V=E2=C2=07F=86R=04=C55=02=076= =86=F7V=C6B=06vWB=06FV=C6WFVB=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3= =C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E5=06= =C7=A2=066=F6=E6f=97&=D2=06=96b=07F=86=972=06=972=07&=96v=87B=E3=C4%#= =E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77= =06=166R=C46=F7W&=96W"#=E4=F7"=06=17&R=07=96=F7R=06v=F6=96=E6r=07F= =F2=06F=F2=076=F6=D6R=076V=C6b=D7&Vg&W6=82=06=B6=96=E6B=06=F6b=06f= =F7"=06=96=E6f=96=E6=97FR=06GW&=17F=96=F6=E2=E3=C4%#=E4GW&=17F=96= =F6=E2=076=86=F7V=C6B=06&R=06=96=E6f=96=E6=97FR=06=172=07&V6=F7fW'= =92=06=F6b=06f=16=96=C7W&R=06=D6=17=92=07F=16=B6R=07F=96=D6R=E3=C4%#= =E5F=86=972=076V=C6b=07&Vg&W6=82=06=86=172=07F=F2=06&R=07F=96=C6=C2= =06f=16=96=C7W&R=07&V6=F7fW'2=06=F7"=07F=96=C6=C2=07=96=F7R=06=16v= =16=96=E2=077F=17'B=06vWGF=96=E6r=07F=86R=07&Vg&W6=82=06=D6W76=16vW2= =E2=04=F7"=07F=86R=057F=17FR=06vWG2=06W=87=06=C6=966=97F=C7=92=06FV= =C6WFVB=06'=92=06=86V=16B=06V=E6B=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C2=F5T= =C3=E3=C5=03=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&= =96W"#=E5=06=C7=A2=06=C6WB=06=D6R=06=B6=E6=F7r=07=96=F7W"=07f=96Wr= =E3=C4%#=E5F=86=16=E6=B72=06=16=E6B=05&Vv=17&G2=C3=C4%#=E4=16=D6=97B= =E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6= =E6=F77=06=166R=C46=F7W&=96W"#=E4g&=F6=D2=02f=E6'7=03=B2=04F=96=D6= =97G&=92=E5=06=17=06=16F=96=D6=97G&=96=F7T=06=16=C66=17FV=C2=E6&S= =C4%#=E56V=E7B=02f=E6'7=03=B4g&=96F=17=92=C2=04=17=07&=96=C2=03=12= =C2=03#=03=03R=03s=A3S=12=07=06=D3=C4%#=E5F=F2=02f=E6'7=03=B4=16=D6= =97B=03s=03C=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=92=E66=F6=D2fwC= =B3=C4%#=E462=02f=E6'7=03=B4F=96=D6=97G&=92=E5=06=17=06=16F=96=D6= =97G&=96=F7T=06=16=C66=17FV=C2=E6&R=02=C2=0666=16=D7=04=06=F7=072= =E6=96WFb=E6=F7&s=C4%#=E4&63=C4%#=E57V&=A6V7B=02f=E6'7=03=B5&S=A2= =05&Vv=17&F=96=E6r=05&WfW'6=96=F6=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#= =E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E6= =16=D6=97B=C2=07W=06=F6=E2=06 =17F=12=07=06=C6=16=E6R=06f=16=96=C7W&R=07F=86W&R=06=972=06=E6=F2= =077V6=82=06&V=86=17f=96=F7W"=06=172=07=96=F7R=06=D6V=E7F=96=F6=E2= =02=D2=06=C6=F66=16=C2=06F=17F=12=07=06=C6=16=E6R=06f=16=96=C7W&R= =06FWFV7F=96=F6=E2=06F=F6W2=06=E6=F7B=06=96=D7=06=C7=92=077F=17FR= =06FV=C6WF=96=F6=E2=06=16=E6B=066=F6=D6=D6=F6=E2=05=06=17F=84W'"=F5&W= 7dW'"=06F=F2=06=E6=F7B=07G&=96vvW"=06=16=E7=92=077F=17FR=06FV=C6WF= =96=F6=E2=06=E6=F7"=06F=F6W2=06=12=04=E6=F7F=96g=93=B2=06=96=E2=07= =06=17'F=967V=C6=17"=C2=06=96=E2=07F=86R=07=07&W6V=E7B=066=F6=E7FW= =87B=07v=86W&R=06=F6=E6R=06F=F2=06=1777V=D6R=066=F6=E7G&=F6=C2=07= =06=C6=16=E6R=06=17f=16=96=C6=16&=96=C6=97G=92=06WfV=E2=06=96=E2=066= =176R=06=F6b=06F=17F=12=07=06=C6=16=E6R=06f=16=96=C7W&R=02=D2=06=E6= =F7FS=A2=06FWF=16=96=C72=06=F6b=06=97B=06=17f=16=96=C6=16&=C6R=06= =96=E2=06=F7F=86W"=06F=F67V=D6V=E7G2=02=D2=077F=17FW2=066=16=E2=06&R= =06=B6W=07B=07&Vg&W6=86VC=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4= =E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=16=D6=97B= =03s=03C=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=92=E66=F6=D2fwC=B3= =C4%#=E56V=E7B=06'=93=A2=06=F7v=E6W"=D666=16=D7=04=06=F7=072=E6=96WFb= =E6=F7&s=C4%#=E3=03B=F3=03=12=F3#=03=03R=03=13s=A3S=12=05=A4S=83=C4%#= =E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77= =06=166R=C46=F7W&=96W"#=E5F=F3=A2=04F=96=D6=97G&=92=05=04=15=04=14D= =94=D4=95E$=94=F5R=F4$R=F4=14=C44=15DT=C4=04=14=C44=15DT=C3=C4%#=E663= =A2=0666=16=D7=04=06=F7=072=E6=96WFb=E6=F7&s=C4%#=E6&63=A3=C4%#=E57V&= =A6V7C=A2=05&S=A2=05&Vv=17&F=96=E6r=05&WfW'6=96=F6=E3=C4%#=E3=C2=F4d= =F4=E5C=E3=C4%#=E3=C4%#=E3=C4%#=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$= =D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=86=92=C3=C4%#=E5F=86=16=E6= =B72=06f=F7"=07&W=06=C7=96=96=E6r=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#= =E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&= =96W"#=E4=1666=F7&F=96=E6r=07F=F2=07F=86R=077F=17FV=D6V=E7B=04=92= =06=D6V=E7F=96=F6=E6VB=06g&=F6=D2=07F=86R=06G&=16gB=C2=04=92=07V=E6FW= '7F=16=E6B=07F=86=17B=C2=06=96b=07F=86W&R=06=972=06=12=06f=16=96=C7W&= R=07F=86R=06=F6=C6B=07v=F7&=B6=96=E6r=04=C55=02=076=86=F7V=C6B=06= =E6=F7B=06&R=06FV=C6WFVB=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4= =E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W =96W"#=E4'WB=06=E6=F7B=06=F6=E6=C7=92=06f=F7"=05%5e=02=C2=06f=F7"= =06=16=E7=92=04=D5=04=C52=056=96v=E6=16=C6=96=E6r=07=07&=F7F=F66=F6= =C2=C2=06=97B=06=972=06=D6=16=E6F=17F=F7'=92=07F=86=17B=07v=86V=E2= =06=12=06f=16=96=C7W&R=06=86=17=07=06V=E72=C2=07=96=F7R=076=86=F7V= =C6B=077F=17'B=07FV=17&=96=E6r=06F=F7v=E2=07F=86R=04=C55=02=E3=C4%#= =E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77= =06=166R=C46=F7W&=96W"#=E5F=16=B6R=06f=F7"=06=96=E77F=16=E66R=06=96b= =06=12=04=F7WD=96=E7FW&f=166R=86=F6=E2=07v=86=966=82=04=C55=02=06= =972=076WGW=02=92=06v=F6W2=06F=F7v=E2=E3=C4%#=E5=07&=F7F=F66=F6=C2= =07v=96=C6=C2=06=C6V=16B=07F=F2=04=C55=02=06FV=C6WF=96=F6=E2=E3=C4%#= =E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77= =06=166R=C46=F7W&=96W"#=E5=06=C7=A2=066=F7'&V7B=06=D6R=06=96b=04=92= =06=16=D2=07w&=F6=E6r=E3=C4%#=E5&Vv=17&G2=C3=C4%#=E4=16=D6=97B=E3= =C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$= =D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4g&=F6=D2=02f=E6'7=03=B2=04F= =96=D6=97G&=92=E5=06=17=06=16F=96=D6=97G&=96=F7T=06=16=C66=17FV=C2= =E6&S=C4%#=E56V=E7B=02f=E6'7=03=B4g&=96F=17=92=C2=04=17=07&=96=C2= =03=12=C2=03#=03=03R=03S=A3#B=07=06=D3=C4%#=E5F=F2=02f=E6'7=03=B4= =16=D6=97B=03s=03C=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV=92=E66=F6= =D2fwC=B3=C4%#=E462=02f=E6'7=03=B666=16=D7=04=06=F7=072=E6=96WFb=E6= =F7&s=C4%#=E4&63=C4%#=E57V&=A6V7B=02f=E6'7=03=B5&S=A2=05&Vv=17&F=96= =E6r=05&WfW'6=96=F6=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B= =04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E6=86=92=02=D2=07v= =F7V=C6B=07=96=F7R=07=06=C6V=176R=066=C6=17&=96g=92=07=96=F7W"=066= =F6=D6=D6V=E7B=02=D2=07F=F2=07v=86=966=82=07=06=F7FV=E7F=96=16=C2= =07f=96=F6=C6=17F=96=F6=E2=06F=F2=07=96=F7R=07&VfW"=03=F2=06=96=E2= =07=06=17'F=967V=C6=17"=07F=86=972=077=06V6=96f=966=17F=96=F6=E2=06&V= =96=E6r=06gV=E67F=96=F6=E6=16=C2=077=06V6=96f=962=06FWF=16=96=C72= =066=F6=E66W&=E6=96=E6r=07&V=16=C6=97=A6=17F=96=F6=E2=07W6=96=E6r= =05%5e=02=06=17&R=07=07&=F7f=96FVB=06=96=E2=07F=86R=06V=E6B=D7F=F2= =D6V=E6B=076=96v=E6=16=C6=96=E6r=06F=F67V=D6V=E7C=C4%#=E3=C2=F4d=F4= =E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&= =96W"#=E4=16=D6=97B=03s=03C=03R=02f=C7C=B4=16=D6=97Dt=06=87V=17vV= =92=E66=F6=D2fw =B3=C4%#=E56V=E7B=06'=93=A2=06=F7v=E6W"=D666=16=D7=04=06=F7=072=E6= =96WFb=E6=F7&s=C4%#=E3=03B=F3=03=12=F3#=03=03R=03=13C=A33=92=05=A4S= =83=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6= =E6=F77=06=166R=C46=F7W&=96W"#=E5F=F3=A2=0666=16=D7=04=06=F7=072=E6= =96WFb=E6=F7&s=C4%#=E663=A3=C4%#=E6&63=A3=C4%#=E57V&=A6V7C=A2=05&Vv= =17&F=96=E6r=05&WfW'6=96=F6=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#= =E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4= =86=92=C3=C4%#=E4=96=E2=07F=86R=06G&=16gB=06G&=16gB=D6=96WFb=D666= =16=D7=02=D6v=D7=06=C72=D7&V6=F7fW'=92=D6gV=E67F=96=F6=E6=16=C2=D3= =03B=E7G=87B=C2=06=96=E2=07F=86R=076V7F=96=F6=E2=06=16&=F7WB=05&WfW'6= =96=F6=E2=E3=C4%#=E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#=E3=C4d=F4=E5B=04d= =144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&=96W"#=E4=97B=06=972=076=16= =96C=A3=C4%#=E2g=17V=F7C=B5&WfW'6=96=F6=E2=06=96=D7=06=C6=96W2=07F= =86=17B=06=12=07v=F7&=B6=96=E6r=07=06=17F=82=07&V=D6=16=96=E72=06= =16=C6=C6=F66=17FVB=07F=F2=07F=86R=04=C55=02=07F=86=17C=C4%#=E7v=172= =06=F7&=96v=96=E6=16=C6=C7=92=07&=F7WFVB=06=F7fW"=06=97B=06WfV=E2= =06=16gFW"=06=12=06f=16=96=C7W&R=E2g=17V=F7C=B3=C4%#=E3=C2=F4d=F4= =E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&= =96W"#=E5F=86=972=07&W=17V=97&V=D6V=E7B=06=D6=17=92=06=86=F6=C6B=07G'= VR=06f=F7"=06=E6=F6=E2=D5=0542=06=E6WGv=F7&=B72=C2=06=16=E6B=06=D6= =17=92=06=E6=F7B=06&R=07&W=17V=97&VB=06=96=E2=05=0542=E3=C4%#=E4=86= =F7r=066=16=E2=05%5e=02=077W=07=06=F7'B=07F=86=973=F3=F2=04=92=06= =D6V=16=E2=06=97B=06=D6=17=92=07F=F7F=16=C6=C7=92=07f=96=F6=C6=17FR= =05%5e=02=D5DR=077F=16=E6F=17&B=E3=C4%#=E4=172=07F=86=F7Vv=82=07F= =86R=06f=16=96=C7W&R=06=86=172=06=86=17=07=06V=E6VB=06=16=E6B=04=C55= =02=076=86=F7V=C6B=06=E6=F7B=06&R=06FV=C6WFVB=E3=C4%#=E3=C2=F4d=F4= =E5C=E3=C4%#=E3=C4d=F4=E5B=04d=144S=D2$=D6=F6=E6=F77=06=166R=C46=F7W&= =96W"#=E5=06=C7=A2=06=C6WB=06=D6R=06=B6=E6=F7r=07=96=F7W"=07f=96Wr= =06=F6=E2=07F=86=972=E3=C4%#=E5&Vv=17&G2=C3=C4%#=E4=16=D6=97B=E3=C4%#= =E3=C2=F4d=F4=E5C=E3=C4%#=E3=C4%#=E3=C2=F5=03=E0 --Boundary_(ID_jlL27lHPPHdyZhwcM8dQqw)-- From owner-ccamp@ops.ietf.org Wed Apr 6 09:32:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10837 for ; Wed, 6 Apr 2005 09:32:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJAmM-0007bV-EB for ccamp-archive@ietf.org; Wed, 06 Apr 2005 09:41:13 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJATP-000Ak6-Pu for ccamp-data@psg.com; Wed, 06 Apr 2005 13:21:35 +0000 Received: from [64.208.49.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJATL-000AjS-RN; Wed, 06 Apr 2005 13:21:32 +0000 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j36DLG9B025361; Wed, 6 Apr 2005 15:21:16 +0200 Received: from [138.203.86.121] ([138.203.86.121]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.12HF788) with ESMTP id 2005040615211517:3637 ; Wed, 6 Apr 2005 15:21:15 +0200 Message-ID: <4253E24B.3090109@alcatel.be> Date: Wed, 06 Apr 2005 15:21:15 +0200 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dimitri.papadimitriou@alcatel.be, dpapadimitriou@psg.com Cc: ccamp@ops.ietf.org, kireeti Kompella , Cheng-Yin.Lee@alcatel.com, Adrian Farrel Subject: Re: WG last calls - comments on draft-ietf-ccamp-rsvp-te-exclude-route-03.txt References: <425250D8.8050809@psg.com> In-Reply-To: <425250D8.8050809@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 04/06/2005 15:21:15, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 04/06/2005 15:21:18, Serialize complete at 04/06/2005 15:21:18 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Content-Transfer-Encoding: 7bit Hi Dimitri, Thanks for these useful comments. Replies inline... dimitri papadimitriou wrote: > hi adrian, > > some comments here below on the exclude route i-d > > technical > --------- > > 1. section 2.1 > > "Constrained Shortest Path First (CSPF) computation at Ingress, so the > ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, > AB2-strict, Egress-loose) and (B1, B2, BC1, C1, C2) respectively." > > AB1 should also be excluded as AB2 does not know the first path crosses > this node so there may be a case (in this example for inst. imagine > there is no link between AB2 and B3) where this could lead to overlap if > AB2 selects an area B link to reach AB1 > correct, the same applies for the next area as well. > 2. section 4 > > "The exclude route identifies a list of abstract nodes that MUST NOT > be traversed along the path of the LSP being established." > > while section 4.1 > > " The concept of loose or strict hops has no meaning in route > exclusion. The L bit, defined for ERO subobjects in [RSPV-TE], is > reused here to indicate that an abstract node MUST be avoided (value > 0) or SHOULD be avoided (value 1)." > correct. I believe it is better to say "... that should not be traversed..." with "should" in small because the formal specification is in the subsections. > > 3. section 4.1 > > "The subobjects are identical to > those defined in [RFC3209] and [RFC3473] for use in EROs." > > looking at the definitions this is not the case (moreover the SRLG > subobject has been added) - > Are you only referring to the SRLG subobject? If yes, then it is best to change it into "...those defined in [RFC3209] and [RFC3473] for use in EROs and section 3.1 of this document." > 4. section 4.1 > > " An Attribute octet is introduced in the subobjects that define IP > addresses to indicate the attribute (e.g. interface, node, SRLG) > associated with the IP addresses that can be excluded from the path." > > what is a subobject that define IP addresses ? see following subsections. Is it enough that I change "IP address" into "IP prefix" to make it more clear? > > 5. section 4.1 > > " For instance, the attribute node allows a whole node to be excluded > from the path, in contrast to the attribute interface, which allows > specific interfaces to be excluded from the path. " > > but below the definition says "0 indicates that the interface or set of > interfaces associated with the IP prefix should be excluded or avoided" > which makes the term specific ambiguous > Section 4.1 is an example on how to exclude a node or an interface from a path. Section 4.1.1 contains the full specification and the example looks to be contained in 4.1.1. > 6. section 4.1.5 > > " node > > 1 indicates that the node with the Router ID should be > excluded or avoided (this can be achieved using IPv4/v6 > subobject as well, but is included here because it may be > convenient to use subobjects from RRO, in specifying the > exclusions)" > > until "(this can be achieved using IPv4/v6 subobject" i understand after > i would ask you to clarify i guess you mean RRO from another path ? > should you include this as part of the definition ? > Can you give an example on how the exlude/avoid resources from a path computation while the path is already computed and signaled (otherwise you do not have an RRO)? > 7. section 4.2 - condition 1. what does happen when the L flag is not > set and the condition is not verified ? > Then the actions mentioned do not have to be done and the next step in the processing is done. There is no explicit statement saying that in this case the next step must be taken, neither is there a statement saying that the processing also stops when the condition is met. See 4.3.4.1. of RFC3209 for similar way of describing processing. > 8. section 4.2 - condition 3. "If they do contradict, the subobjects > with the L flag not set, strict or MUST be excluded, respectively, in > the ERO or XRO MUST take precedence." this sentence is cryptic i put in > the technical part because it impacts understanding concerning the exact > processing > Indeed, the sentence is not understandable and even wrong (the same applies to a similar sentence in EXRS). Irrespective of whether the ERO subobject is strict or loose, it takes precedence togheter with exclude subobjects in the XRO over the avoid subobjects. > 9. section 4.2 - condition 4. "The number of introduced SLRGs with the L > flag set to "avoid" should be minimised." i guess you mean wrt to the > number of "exclude" SRLGs (blocking) ? or is there an absolute > limitation due to the message size > The sentence you are referring to is not related to the number of subobejcts in the XRO. It is related to the number of links belonging to SRLGs that should be avoided. For instance, when there is a path that has a link with 1 SRLG to be avoided, and there is another path with a link of 2 SRLGs to be avoided, and there are no alternative paths then take the first path because it minimises the number of SLRGs with the L flag set to avoid. To make it clear, I will change the text as follows: "The number of introduced explicit ndoes or abstract nodes in the computed path with the L flag set to "avoid" should be minimised. > 10. section 4.2 - concerning the operations i would suggesting adding a > rule suggesting that no contradicting exclusions get inserted > What is a contradicting exclusion? Do you mean if for instance a node appears twice in the XRO, as avoid and exclude? In that case it is exclude. I will add a statement. Contradictions with ERO are possible but that is mentioned. > 11. section 5. > > "The Explicit Exclude Route defines abstract nodes or resources (such > as links, unnumbered interfaces or labels) that must not be used on > the path between two inclusive abstract nodes or resources in the > explicit route." > > ... "must" while the L bit means either "avoid" or "exclude" > indeed, should be "...must not or should not be used...". > 12. section 5.1 > > " A new ERO subobject type is defined. The Explicit Exclude Route > Subobject (EXRS) has type [TBD]. The EXRS may not be present in an > RRO or XRO." > > would you clarify the meaning of the second sentence in the context of > the first one ? (note: the doc. since far tells the reader that the EXRS > is an ERO subobject) > Better to make it "The EXRS MUST NOT be present in an XRO". The subobjects of the XRO are the same as the ERO subobject. The EXRS is also an ERO subobject, but may not be present in XRO. It is rather obvious that EXRS can not be in the RRO, so that can be removed. > 13. section 5.1 > > " Note: The Most Significant Bit in the Type field could be used to > indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating > the need to prepend the subobject with an additional TLV header. > This would reduce the number bytes require for each subobject by 2 > bytes. However, this approach would reduce the ERO Type field space > by half. This issue need WG discussion and feedback." > > -> i would suggest keeping existing definition (since the EXRS is to > considered as an optimization), this said better formalization of the > EXRS subobjects needs to be provided - as the next section mentions > "Each EXRS may carry multiple exclusions. The exclusion is encoded > exactly as for XRO subobjects and prefixed by an additional Type and > Length." while with the provided alignment it looks like each exclusion > element is encoded with this double Type/Length field > Thanks for your feedback on this question. Concerning the alignment: there can be multiple subobjects in an EXRS, note the plural form of "EXRS subobjects" in the first figure of section 5.1. Better to make this more explicit in the specification of "EXRS subobjects": One or more EXRS subobjects. An EXRS subobject indicates....". For a better alignment it might be better to indeed add 2 padding bytes after the Type and Length. > note that section 5. would probably require a revision after completion > of the technical details > I agree. In fact, I believe the processing can be largely removed by referring to the XRO processing. The processing is the same except with the limitation that it only applies to a part of the path. For instance comment 8 above, also applies here and it makes not much sense to duplicate things. > 14. section 6. > > " 2. The EXRS SHOULD be supported. If supported, the same > restrictions as for the XRO apply." > > -> the EXRS is an optimization it should not be considered as a should > but optional ie MAY > Because it is about *minimal* compliance, I tend to agree. > 15. there is nothing said concerning usage of EXRS when using XRO ? > Good point. Since there is basically not much difference in the processing between EXRS and XRO, it is not a big deal to handle both. > editorial > --------- > > 1. section 2. and onward why referring to a "Explicit Exclude Route" and > then to a "5.1 Explicit Exclusion Route Subobject (EXRS)" and not a > "Explicit Exclude Route Subobject (EXRS)" ? -> the document would > benefit from using a single term either "exclude" or "exclusion" > ok, lets take "exclusion" > 2. section 2. > > " This subobject might also be appropriate for use within Explicit > Routes or Record Routes, but that discussion is outside the scope of > this document." > > would suggest replace this sentence with "This document does not assume > or preclude any other usage for this subobject." > ok > 3. section 2. "A new subobject type the Explicit Exclude > Route Subobject (EXRS) is introduced to indicate an exclusion > between a pair of included abstract nodes." > > would complete the last part of the sentence (as i guess you mean of the > ERO in the present context) > indeed, sentence should be "A new ERO subobject type ...." > 4. why section 3.1 is defined as "SRLG ERO Subobject" i think this > should better be defined as an "SRLG Subobject" as i do not see a > specific reason for having an SRLG subobject outside of the XRO, EXRS > context ? > not really, see 2 previous comments. It is really an ERO subobject but the usage of this in ERO is not part of this document. This comes down to the discussion whether XRO defines new subobjects specific for XRO or whether XRO simply reuses the ERO subobjects with some modifications (L-flag and attribute). So far, the latter has been choosen but that means that it is an SRLG ERO subobject. > 5. Section 4.1.x - adapt IP address to IPv4 address when defining the > IPv4 subobject, etc. > yes > 6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID, > see rfc3477, section 4, from where we got the object. In fact, a reference to this RFC is missing. > 7. section 5.1 > > ""Thus, an EXRO subobject for an IP hop might look as follows:..." ? > what do you mean by might ? isn't EXRS instead of EXRO ? > "Might" means that there other methods to do the same. For instance, if the IP hop is IPv6, it looks different. If unnumbered links are used, it is also different. Indeed, EXRO should be EXRS. > 8. section 5.1 > > "Both subobjects are as described earlier in this document." both (to > which subobject do you refer here) ? > should be "The format of an EXRS subobject is exactly the same as the format of a subobject in the XRO. An EXRS may include all subobjects defined for the XRO in this document.". In this way it is more clear. Becuase SRLG has been defined for XRO in this document it may also be in the EXRS but that is implicit in the above sentence. > 9 "5.2 Semantics and Processing Rules for the EXRS" -> "5.2 Processing > Rules for the EXR Subobject and its Subobjects" > indeed. should be "5.2 Semantics and Processing Rules for the EXRS and its Subobjects". > 10. section 5.2 > > "If the presence of EXRO Subobjects precludes further forwarding of > the Path message, the node should return a PathErr with the error > code "Routing Problem" and error value of "Route blocked by Exclude > Route"." > > you mean EXRS ? instead EXRO ? > yes > 11. section 5.2 > > "If a node is called upon to process an EXRS and does not support > handling of exclusions it will return a PathErr with a "Bad > EXPLICIT_ROUTE object" error." > > ... Routing Problem/Bad EXPLICIT_ROUTE object > yes > note that in general definition of the subobject field could be made a > bit more explicit > I agree with that. > > hope these comments will help you > Sure. Thanks for the comments. regards, Stefaan From owner-ccamp@ops.ietf.org Wed Apr 6 11:39:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27169 for ; Wed, 6 Apr 2005 11:39:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJCl9-00047O-6H for ccamp-archive@ietf.org; Wed, 06 Apr 2005 11:48:05 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJCT5-00030W-Sw for ccamp-data@psg.com; Wed, 06 Apr 2005 15:29:23 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJCT2-00030F-O2 for ccamp@ops.ietf.org; Wed, 06 Apr 2005 15:29:20 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 80695E000271; Wed, 6 Apr 2005 16:29:10 +0100 (BST) Received: from Puppy ([212.43.203.93] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 16:29:09 +0100 Message-ID: <181601c53abd$a2af8910$dccb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Lam, Hing-Kam (Kam)" Cc: , , "'Kireeti Kompella'" , "Scott Bradner" , , "Bill Fenner" Subject: Liaison to ITU-T Q14/15 on Inclusion of Crankback in G.7713 Date: Wed, 6 Apr 2005 15:25: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-OriginalArrivalTime: 06 Apr 2005 15:29:10.0566 (UTC) FILETIME=[614E0460:01C53ABD] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit To: Mr. Kam Lam, Rapporteur ITU-T Q14/15 From: Adrian Farrel and Kireeti Kompella Co-chairs of IETF CCAMP Working Group Subject: Inclusion of Crankback in G.7713 For: Action Deadline: May 1st 2005 Dear Mr. Lam, Thank you for your recent response liaison on Crankback. The CCAMP working group is pleased to hear that our work on crankback is of use to your Question and looks forward to seeing the inclusion of crankback within G.7713, and to the inclusion of specific protocol elements in G.7713.2. In order to increase the convergence between the work of our two organizations, the CCAMP working group would welcome the opportunity to review and comment on these inclusions in G.7713 and G.7713.2 before they are presented for consent. Thank you. Adrian Farrel and Kireeti Kompella From owner-ccamp@ops.ietf.org Thu Apr 7 04:03:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24910 for ; Thu, 7 Apr 2005 04:03:36 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJS7l-0007cq-RF for ccamp-archive@ietf.org; Thu, 07 Apr 2005 04:12:26 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJRpd-000GW3-I8 for ccamp-data@psg.com; Thu, 07 Apr 2005 07:53:41 +0000 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJRpa-000GVG-4g; Thu, 07 Apr 2005 07:53:38 +0000 Message-ID: <4254E6FF.6080301@psg.com> Date: Thu, 07 Apr 2005 09:53:35 +0200 From: dimitri papadimitriou Reply-To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stefaan.de_cnodder@alcatel.be CC: dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org, kireeti Kompella , Cheng-Yin.Lee@alcatel.com, Adrian Farrel Subject: Re: WG last calls - comments on draft-ietf-ccamp-rsvp-te-exclude-route-03.txt References: <425250D8.8050809@psg.com> <4253E24B.3090109@alcatel.be> In-Reply-To: <4253E24B.3090109@alcatel.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Content-Transfer-Encoding: 7bit hi stefaan thanks for your detailed reply - see in-line for some additional clarifications stefaan.de_cnodder@alcatel.be wrote: > > Hi Dimitri, > > Thanks for these useful comments. Replies inline... > > dimitri papadimitriou wrote: > >> hi adrian, >> >> some comments here below on the exclude route i-d >> >> technical >> --------- >> >> 1. section 2.1 >> >> "Constrained Shortest Path First (CSPF) computation at Ingress, so the >> ERO and XRO signaled at Ingress could be (A3-strict, A4-strict, >> AB2-strict, Egress-loose) and (B1, B2, BC1, C1, C2) respectively." >> >> AB1 should also be excluded as AB2 does not know the first path >> crosses this node so there may be a case (in this example for inst. >> imagine there is no link between AB2 and B3) where this could lead to >> overlap if AB2 selects an area B link to reach AB1 > > correct, the same applies for the next area as well. > >> 2. section 4 >> >> "The exclude route identifies a list of abstract nodes that MUST NOT >> be traversed along the path of the LSP being established." >> >> while section 4.1 >> >> " The concept of loose or strict hops has no meaning in route >> exclusion. The L bit, defined for ERO subobjects in [RSPV-TE], is >> reused here to indicate that an abstract node MUST be avoided (value >> 0) or SHOULD be avoided (value 1)." > > correct. I believe it is better to say "... that should not be > traversed..." with "should" in small because the formal specification is > in the subsections. > >> 3. section 4.1 >> >> "The subobjects are identical to >> those defined in [RFC3209] and [RFC3473] for use in EROs." >> >> looking at the definitions this is not the case (moreover the SRLG >> subobject has been added) - > > Are you only referring to the SRLG subobject? If yes, then it is best to > change it into "...those defined in [RFC3209] and [RFC3473] for use in > EROs and section 3.1 of this document." -> yes, but also ERO subobjects do not include an attribute field, XRO subobjects do >> 4. section 4.1 >> >> " An Attribute octet is introduced in the subobjects that define IP >> addresses to indicate the attribute (e.g. interface, node, SRLG) >> associated with the IP addresses that can be excluded from the path." >> >> what is a subobject that define IP addresses ? > > see following subsections. Is it enough that I change "IP address" into > "IP prefix" to make it more clear? wouldn't be better to refer to the subobject types instead, something like (concerning the "An Attribute field is introduced in the subobjects Type 1, 2 and 4 to indicate the attribute (e.g. interface, node, SRLG) that is associated with the IP address included as part of the subobject and that can be excluded from the path." also definition of the attribute value should refer better to "IPv4 or IPv6 address treated as an prefix based on the prefix length value" last point but this is editorial, currently you have 4.1.1 Subobject 1: IPv4 prefix 4.1.2 Subobject 2: IPv6 Prefix 4.1.3 Subobject 32: Autonomous System Number 4.1.4 Subobject TBD: SRLG 4.1.5 Subobject 4: Unnumbered Interface ID Subobject wouldn't it be better to list them as 4.1.1 Subobject 1: IPv4 prefix 4.1.2 Subobject 2: IPv6 Prefix 4.1.3 Subobject 4: Unnumbered Interface ID Subobject 4.1.4 Subobject 32: Autonomous System Number 4.1.5 Subobject TBD: SRLG >> 5. section 4.1 >> >> " For instance, the attribute node allows a whole node to be excluded >> from the path, in contrast to the attribute interface, which allows >> specific interfaces to be excluded from the path. " >> >> but below the definition says "0 indicates that the interface or set >> of interfaces associated with the IP prefix should be excluded or >> avoided" which makes the term specific ambiguous > > Section 4.1 is an example on how to exclude a node or an interface from > a path. Section 4.1.1 contains the full specification and the example > looks to be contained in 4.1.1. indeed, this is what i understood, my question is more "how can you be specific if you remove a set of interfaces" >> 6. section 4.1.5 >> >> " node >> >> 1 indicates that the node with the Router ID should be >> excluded or avoided (this can be achieved using IPv4/v6 >> subobject as well, but is included here because it may be >> convenient to use subobjects from RRO, in specifying the >> exclusions)" >> >> until "(this can be achieved using IPv4/v6 subobject" i understand >> after i would ask you to clarify i guess you mean RRO from another >> path ? should you include this as part of the definition ? > > Can you give an example on how the exlude/avoid resources from a path > computation while the path is already computed and signaled (otherwise > you do not have an RRO)? you signal a first LSP, at the ingress you recuperate the (Resv) RRO that you inject (may be after some transformation) as part of the XRO of another LSP (load balancing for inst.) now concerning the initial point (as i do not understand what you mean by "use RRO subobjects for exclusion" to achieve the same functionality as an XRO with the Type 4 subobject) would you please provide 1) the explanation about the context of the usage of the RRO subobjects for exclusions (beside what is defined in RFC 3209 Section 4.2.2) and then 2) why do you think providing two ways to do the same thing as part of the same document is useful ? >> 7. section 4.2 - condition 1. what does happen when the L flag is not >> set and the condition is not verified ? >> > > Then the actions mentioned do not have to be done and the next step in > the processing is done. There is no explicit statement saying that in > this case the next step must be taken, neither is there a statement > saying that the processing also stops when the condition is met. See > 4.3.4.1. of RFC3209 for similar way of describing processing. > >> 8. section 4.2 - condition 3. "If they do contradict, the subobjects >> with the L flag not set, strict or MUST be excluded, respectively, in >> the ERO or XRO MUST take precedence." this sentence is cryptic i put >> in the technical part because it impacts understanding concerning the >> exact processing > > Indeed, the sentence is not understandable and even wrong (the same > applies to a similar sentence in EXRS). Irrespective of whether the ERO > subobject is strict or loose, it takes precedence togheter with exclude > subobjects in the XRO over the avoid subobjects. > >> 9. section 4.2 - condition 4. "The number of introduced SLRGs with the >> L flag set to "avoid" should be minimised." i guess you mean wrt to >> the number of "exclude" SRLGs (blocking) ? or is there an absolute >> limitation due to the message size > > The sentence you are referring to is not related to the number of > subobejcts in the XRO. It is related to the number of links belonging to > SRLGs that should be avoided. please rephrase it - because it is quite difficult to deduce this meaning (in particular, if a recommendation follows that statement) > For instance, when there is a path that > has a link with 1 SRLG to be avoided, and there is another path with a > link of 2 SRLGs to be avoided, and there are no alternative paths then > take the first path because it minimises the number of SLRGs with the L > flag set to avoid. > > To make it clear, I will change the text as follows: "The number of > introduced explicit ndoes or abstract nodes in the computed path with > the L flag set to "avoid" should be minimised. ok - and indicate a sensible reason would help in understanding why - this is not difficult to be spelled out anyway >> 10. section 4.2 - concerning the operations i would suggesting adding >> a rule suggesting that no contradicting exclusions get inserted > > What is a contradicting exclusion? Do you mean if for instance a node > appears twice in the XRO, as avoid and exclude? In that case it is > exclude. I will add a statement. Contradictions with ERO are possible > but that is mentioned. the document says "If an XRO was present, the content of the XRO can be modified." so what i mean is that THIS node does not introduce a exclusion for an subobject it has itself included as part of the ERO (as the document explains how to process such contradicting exclusions but should also have clear rules in terms of generation of XROs) >> 11. section 5. >> >> "The Explicit Exclude Route defines abstract nodes or resources (such >> as links, unnumbered interfaces or labels) that must not be used on >> the path between two inclusive abstract nodes or resources in the >> explicit route." >> >> ... "must" while the L bit means either "avoid" or "exclude" > > indeed, should be "...must not or should not be used...". > >> 12. section 5.1 >> >> " A new ERO subobject type is defined. The Explicit Exclude Route >> Subobject (EXRS) has type [TBD]. The EXRS may not be present in an >> RRO or XRO." >> >> would you clarify the meaning of the second sentence in the context of >> the first one ? (note: the doc. since far tells the reader that the >> EXRS is an ERO subobject) > > Better to make it "The EXRS MUST NOT be present in an XRO". The > subobjects of the XRO are the same as the ERO subobject. The EXRS is > also an ERO subobject, but may not be present in XRO. It is rather > obvious that EXRS can not be in the RRO, so that can be removed. ok - >> 13. section 5.1 >> >> " Note: The Most Significant Bit in the Type field could be used to >> indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating >> the need to prepend the subobject with an additional TLV header. >> This would reduce the number bytes require for each subobject by 2 >> bytes. However, this approach would reduce the ERO Type field space >> by half. This issue need WG discussion and feedback." >> >> -> i would suggest keeping existing definition (since the EXRS is to >> considered as an optimization), this said better formalization of the >> EXRS subobjects needs to be provided - as the next section mentions >> "Each EXRS may carry multiple exclusions. The exclusion is encoded >> exactly as for XRO subobjects and prefixed by an additional Type and >> Length." while with the provided alignment it looks like each >> exclusion element is encoded with this double Type/Length field > > Thanks for your feedback on this question. Concerning the alignment: > there can be multiple subobjects in an EXRS, note the plural form of > "EXRS subobjects" in the first figure of section 5.1. also "The format of this field is exactly the format of an XRO subobject and may include an SRLG subobject. Both subobjects are as described earlier in this document." ... both subobjects refers to ? > Better to make this more explicit in the specification of "EXRS subobjects": One or > more EXRS subobjects. An EXRS subobject indicates....". For a better > alignment it might be better to indeed add 2 padding bytes after the > Type and Length. ok - i do suggest making use of this padding since we speak about a list including sub-lists of subobjects and not lists including (double type/length) subobjects >> note that section 5. would probably require a revision after >> completion of the technical details > > I agree. In fact, I believe the processing can be largely removed by > referring to the XRO processing. The processing is the same except with > the limitation that it only applies to a part of the path. For instance > comment 8 above, also applies here and it makes not much sense to > duplicate things. > >> 14. section 6. >> >> " 2. The EXRS SHOULD be supported. If supported, the same >> restrictions as for the XRO apply." >> >> -> the EXRS is an optimization it should not be considered as a should >> but optional ie MAY > > Because it is about *minimal* compliance, I tend to agree. indeed >> 15. there is nothing said concerning usage of EXRS when using XRO ? > > Good point. Since there is basically not much difference in the > processing between EXRS and XRO, it is not a big deal to handle both. i would suggest carefully analyzing all the potential cases here in part. for the partial overlaps >> editorial >> --------- >> >> 1. section 2. and onward why referring to a "Explicit Exclude Route" >> and then to a "5.1 Explicit Exclusion Route Subobject (EXRS)" and not >> a "Explicit Exclude Route Subobject (EXRS)" ? -> the document would >> benefit from using a single term either "exclude" or "exclusion" >> > > ok, lets take "exclusion" > >> 2. section 2. >> >> " This subobject might also be appropriate for use within Explicit >> Routes or Record Routes, but that discussion is outside the scope of >> this document." >> >> would suggest replace this sentence with "This document does not >> assume or preclude any other usage for this subobject." > > ok > >> 3. section 2. "A new subobject type the Explicit Exclude >> Route Subobject (EXRS) is introduced to indicate an exclusion >> between a pair of included abstract nodes." >> >> would complete the last part of the sentence (as i guess you mean of >> the ERO in the present context) > > indeed, sentence should be "A new ERO subobject type ...." > >> 4. why section 3.1 is defined as "SRLG ERO Subobject" i think this >> should better be defined as an "SRLG Subobject" as i do not see a >> specific reason for having an SRLG subobject outside of the XRO, EXRS >> context ? > > not really, see 2 previous comments. It is really an ERO subobject but > the usage of this in ERO is not part of this document. would it be possible to know which document makes use of SRLG as part of an ERO ? > This comes down > to the discussion whether XRO defines new subobjects specific for XRO or > whether XRO simply reuses the ERO subobjects with some modifications > (L-flag and attribute). So far, the latter has been choosen but that > means that it is an SRLG ERO subobject. ok - but then indicate that there is no description available of the usage of an SRLG subobjects as part of an ERO >> 5. Section 4.1.x - adapt IP address to IPv4 address when defining the >> IPv4 subobject, etc. > > yes > >> 6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID, > > see rfc3477, section 4, from where we got the object. In fact, a > reference to this RFC is missing. this rfc refers to the former but i do suggest using the latter as this has already generated enough issues >> 7. section 5.1 >> >> ""Thus, an EXRO subobject for an IP hop might look as follows:..." ? >> what do you mean by might ? isn't EXRS instead of EXRO ? > > "Might" means that there other methods to do the same. For instance, if > the IP hop is IPv6, it looks different. If unnumbered links are used, it > is also different. Indeed, EXRO should be EXRS. indeed but might is not really used in a prescptive document (prefer MAY with alternatives in case) >> 8. section 5.1 >> >> "Both subobjects are as described earlier in this document." both (to >> which subobject do you refer here) ? > > should be "The format of an EXRS subobject is exactly the same as the > format of a subobject in the XRO. An EXRS may include all subobjects > defined for the XRO in this document.". > > In this way it is more clear. Becuase SRLG has been defined for XRO in > this document it may also be in the EXRS but that is implicit in the > above sentence. > >> 9 "5.2 Semantics and Processing Rules for the EXRS" -> "5.2 >> Processing Rules for the EXR Subobject and its Subobjects" > > indeed. should be "5.2 Semantics and Processing Rules for the EXRS and > its Subobjects". suggest to remove the term semantic since it should be clear from its definition in section 5.1 >> 10. section 5.2 >> >> "If the presence of EXRO Subobjects precludes further forwarding of >> the Path message, the node should return a PathErr with the error >> code "Routing Problem" and error value of "Route blocked by Exclude >> Route"." >> >> you mean EXRS ? instead EXRO ? > > yes > >> 11. section 5.2 >> >> "If a node is called upon to process an EXRS and does not support >> handling of exclusions it will return a PathErr with a "Bad >> EXPLICIT_ROUTE object" error." >> >> ... Routing Problem/Bad EXPLICIT_ROUTE object > > yes > >> note that in general definition of the subobject field could be made a >> bit more explicit > > I agree with that. > >> hope these comments will help you > > Sure. Thanks for the comments. > > regards, > > Stefaan > > > > . > From owner-ccamp@ops.ietf.org Thu Apr 7 06:56:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07707 for ; Thu, 7 Apr 2005 06:56:02 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJUob-0004qu-TS for ccamp-archive@ietf.org; Thu, 07 Apr 2005 07:04:55 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJUW5-000Aa8-IK for ccamp-data@psg.com; Thu, 07 Apr 2005 10:45:41 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJUW4-000AZs-2O for ccamp@ops.ietf.org; Thu, 07 Apr 2005 10:45:40 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IEK002IJMNMZK@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Thu, 07 Apr 2005 03:04:34 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IEK0025IMNGFU@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Thu, 07 Apr 2005 03:04:34 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Thu, 07 Apr 2005 18:08:25 +0800 Date: Thu, 07 Apr 2005 18:08:25 +0800 From: Amit 70405 Subject: About LSP Stiching To: ccamp@ops.ietf.org Message-id: <19f92a19e20e.19e20e19f92a@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7BIT Hi All, In the draft draft-ietf-ccamp-lsp-stitching-00 for LSP stitching, I think one more extension may be needed for E2e LSP. The draft suggest 2 main extensions,LSP Stitch desired bit and LSP Stitch Ready Bit. Both these extensions are for LSP Segement LSP. An LSP Segment will be treated like any other TE-Link. So TE-Link type will be hidden from E2e LSP. There is no way for LSP segment head node, to identify that a Outif selected is a LSP Segment for setting up E2e LSP. That is Some extension will be needed to RSVP that will allow RSVP message(for E2e LSP) processing at LSP segment head node to be processed according to the Sticthing needs. For Eg: LSP1-2 is an E2e LSP setup over an LSP segment LSPA-B. 1-----A--D---E--B-----2 Now if A gets the Path message for LSP1-2, and A selects LSP segment LSPA-B as outif. Then how does RSVP(at Node A) identify that the outif selected is a LSP segment? Also when A receives Resv for LSP1-2(from B), how can it ignore Label in it. There should be a way to determine at node A, that a LSP segment is in use. One possible way could be that Resv message for LSP1-2 should be sent(by B) with some special Label value. This Label value should indicate the node A that the Resv is received for a TE-Link(of type LSP Segment). This will help node A to ignore Label value in Resv msg for E2e Lsp LSP1-2. Plz let me know your view. Thanks in advance. Regards, Amit. From owner-ccamp@ops.ietf.org Thu Apr 7 13:23:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16570 for ; Thu, 7 Apr 2005 13:23:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJarv-0003N5-2Z for ccamp-archive@ietf.org; Thu, 07 Apr 2005 13:32:39 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJaae-0008z7-Tm for ccamp-data@psg.com; Thu, 07 Apr 2005 17:14:48 +0000 Received: from [62.241.162.32] (helo=ranger.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJaaZ-0008y5-V1 for ccamp@ops.ietf.org; Thu, 07 Apr 2005 17:14:44 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by ranger.systems.pipex.net (Postfix) with ESMTP id 91DC2E0002E1; Thu, 7 Apr 2005 18:14:34 +0100 (BST) Received: from Puppy ([212.43.203.111] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 18:14:32 +0100 Message-ID: <006201c53b95$855fa150$6fcb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Bill Fenner" , "Scott Bradner" Subject: Fw: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt Date: Thu, 7 Apr 2005 13:52: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-OriginalArrivalTime: 07 Apr 2005 17:14:33.0956 (UTC) FILETIME=[44C08240:01C53B95] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.8 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Please see below a response from the Counsel for Nortel Networks with regard to my enquiry about their IPR disclosure for draft-ietf-ccamp-loose-path-reopt-00.txt. The working group must now decide whether it wishes to pursue the techniques described in the I-D notwithstanding the IPR claim, or whether it should seek out an alternative technology. Discussion please. Thanks, Adrian ----- Original Message ----- From: "Michelle Lee" To: "Adrian Farrel" Cc: "'Kireeti Kompella'" ; "Richard Weiss" Sent: Wednesday, April 06, 2005 5:54 PM Subject: RE: Nortel Networks Statement on IPR claimed in draft-ietf-ccamp-loose-path-reopt-00.txt > Dear Mr. Farrel, > > Thank you for your email. > > Unfortunately, I am not in a position to answer these questions > specifically, especially since they would require my providing privileged > and/or confidential information. We believe, however, our intentions are > clearly set forth in and by our conforming disclosure and declaration > statement to IETF with respect to IETF Internet Draft > draft-ietf-ccamp-loose-path-reopt-00.txt, and that experts in the area can > probably better determine relevance of the identified patent therein. > > Kind Regards, > Michelle Lee > Counsel, IP Law > Nortel Networks > > > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Monday, March 21, 2005 4:32 PM > To: weissr@nortelnetworks.com; mleelaw@nortelnetworks.com > Cc: 'Kireeti Kompella'; ccamp@ops.ietf.org > Subject: Nortel Networks Statement on IPR claimed in > draft-ietf-ccamp-loose-path-reopt-00.txt > > > > Dear Richard and Michelle, > > Thank you for submitting your Patent Disclosure > ( > 0.txt> > http://www.ietf.org/ietf/IPR/nortel-ipr-draft-ietf-ccamp-loose-path-reopt-00 > .txt) > with respect to IETF Internet Draft > draft-ietf-ccamp-loose-path-reopt-00.txt. > > I would be grateful if you could clarify two points to help me understand > this discolsure further. > > 1. The disclosure states that: > Nortel Networks U.S. Patent No. 6,560,654 entitled "Apparatus and > method of maintaining timely topology data within a link state routing > network" may contain claims that may be necessary for practicing a > resulting IETF Standard based on this Internet Draft. > Could you provide more detail about what aspects of > draft-ietf-ccamp-loose-path-reopt-00.txt you believe may be impacted by > this disclosure? > > 2. Can you clarify whether the "fair, reasonable, reciprocal, and > non-discriminatory terms" referenced in the disclosure include the > intention, in the event that the referenced draft becomes an Internet > Standard, not to assert the patent except that some party asserts a > patent > patent it owns or controls against Nortel? > By way of an example of wording that covers this intention, can I draw > your attention to a completely unrelated IPR disclosure at > > http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-tcpm-tcpsecure.txt > > Thank you for any clarification you are able to offer. > > Please note that I am copying this email to Kireeti Kompella who co-chairs > the IETF's CCAMP working group with me. The CCAMP working group developed > the Internet-Draft in question (draft-ietf-ccamp-loose-path-reopt-00.txt) > and so I am also copying this email to the CCAMP mailing list. > > Best regards, > Adrian Farrel > -- > Adrian Farrel > Old Dog Consulting > Phone: +44 (0) 1978-860944 > Fax: +44 (0) 870-130-5411 > adrian@olddog.co.uk > > > > From owner-ccamp@ops.ietf.org Thu Apr 7 14:46:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25779 for ; Thu, 7 Apr 2005 14:46:29 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJc9y-0006NU-Nx for ccamp-archive@ietf.org; Thu, 07 Apr 2005 14:55:25 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJbsZ-000IPG-8a for ccamp-data@psg.com; Thu, 07 Apr 2005 18:37:23 +0000 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJbsU-000IOj-UJ; Thu, 07 Apr 2005 18:37:19 +0000 Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j37IbA9B031685; Thu, 7 Apr 2005 20:37:10 +0200 Received: from [138.203.197.159] ([138.203.197.159]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.12HF788) with ESMTP id 2005040720370878:5017 ; Thu, 7 Apr 2005 20:37:08 +0200 Message-ID: <42557DD4.6000206@alcatel.be> Date: Thu, 07 Apr 2005 20:37:08 +0200 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be Cc: ccamp@ops.ietf.org, kireeti Kompella , Cheng-Yin.Lee@alcatel.com, Adrian Farrel Subject: Re: WG last calls - comments on draft-ietf-ccamp-rsvp-te-exclude-route-03.txt References: <425250D8.8050809@psg.com> <4253E24B.3090109@alcatel.be> <4254E6FF.6080301@psg.com> In-Reply-To: <4254E6FF.6080301@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 04/07/2005 20:37:08, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 04/07/2005 20:37:10, Serialize complete at 04/07/2005 20:37:10 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Content-Transfer-Encoding: 7bit Hi Dimitri, see below for responses... >> >>> 3. section 4.1 >>> >>> "The subobjects are identical to >>> those defined in [RFC3209] and [RFC3473] for use in EROs." >>> >>> looking at the definitions this is not the case (moreover the SRLG >>> subobject has been added) - >> >> >> Are you only referring to the SRLG subobject? If yes, then it is best >> to change it into "...those defined in [RFC3209] and [RFC3473] for use >> in EROs and section 3.1 of this document." > > > -> yes, but also ERO subobjects do not include an attribute field, XRO > subobjects do > Correct. We use ERO subobjects with these modifications. There has been discussion in the past whether we reuse ERO subobjects and modify to make them useful for XRO, or whether we define for the XRO new subobjects. So far, the decision was to do the former but this is of course open for discussion. The consequence is that when we want to exclude something in the XRO, we also need the corresponding to include it in the ERO. For SRLGs this means that we need an SRLG ERO subobject which is not defined previously. It does not make much sense to have an SRLG ERO subobject (that is why you would not find a document describing the processing rules of such an object in the ERO), but it is needed for the corresponding subobject in the XRO. >>> 4. section 4.1 >>> >>> " An Attribute octet is introduced in the subobjects that define IP >>> addresses to indicate the attribute (e.g. interface, node, SRLG) >>> associated with the IP addresses that can be excluded from the path." >>> >>> what is a subobject that define IP addresses ? >> >> >> see following subsections. Is it enough that I change "IP address" >> into "IP prefix" to make it more clear? > > > wouldn't be better to refer to the subobject types instead, something > like (concerning the > > "An Attribute field is introduced in the subobjects Type 1, 2 and 4 to > indicate the attribute (e.g. interface, node, SRLG) that is associated > with the IP address included as part of the subobject and that can be > excluded from the path." > Sounds better. I will do that. I will also remove the word "IP address" because unnumbered (type 4) is not really an IP address. > also definition of the attribute value should refer better to "IPv4 or > IPv6 address treated as an prefix based on the prefix length value" > > last point but this is editorial, currently you have > > 4.1.1 Subobject 1: IPv4 prefix > 4.1.2 Subobject 2: IPv6 Prefix > 4.1.3 Subobject 32: Autonomous System Number > 4.1.4 Subobject TBD: SRLG > 4.1.5 Subobject 4: Unnumbered Interface ID Subobject > > wouldn't it be better to list them as > > 4.1.1 Subobject 1: IPv4 prefix > 4.1.2 Subobject 2: IPv6 Prefix > 4.1.3 Subobject 4: Unnumbered Interface ID Subobject > 4.1.4 Subobject 32: Autonomous System Number > 4.1.5 Subobject TBD: SRLG > yes >>> 5. section 4.1 >>> >>> " For instance, the attribute node allows a whole node to be excluded >>> from the path, in contrast to the attribute interface, which allows >>> specific interfaces to be excluded from the path. " >>> >>> but below the definition says "0 indicates that the interface or set >>> of interfaces associated with the IP prefix should be excluded or >>> avoided" which makes the term specific ambiguous >> >> >> Section 4.1 is an example on how to exclude a node or an interface >> from a path. Section 4.1.1 contains the full specification and the >> example looks to be contained in 4.1.1. > > > indeed, this is what i understood, my question is more "how can you be > specific if you remove a set of interfaces" > ??? Is it OK if I change it into "For instance, the attribute node allows a whole node to be excluded from the path, in contrast to the attribute interface, which allows a specific interface or set of interfaces to be excluded from the path." Note that the interfaces in the set of interfaces does not have to be on the same node. >>> 6. section 4.1.5 >>> >>> " node >>> >>> 1 indicates that the node with the Router ID should be >>> excluded or avoided (this can be achieved using IPv4/v6 >>> subobject as well, but is included here because it may be >>> convenient to use subobjects from RRO, in specifying the >>> exclusions)" >>> >>> until "(this can be achieved using IPv4/v6 subobject" i understand >>> after i would ask you to clarify i guess you mean RRO from another >>> path ? should you include this as part of the definition ? >> >> >> Can you give an example on how the exlude/avoid resources from a path >> computation while the path is already computed and signaled (otherwise >> you do not have an RRO)? > > > you signal a first LSP, at the ingress you recuperate the (Resv) RRO > that you inject (may be after some transformation) as part of the XRO of > another LSP (load balancing for inst.) > > now concerning the initial point (as i do not understand what you mean > by "use RRO subobjects for exclusion" to achieve the same functionality > as an XRO with the Type 4 subobject) would you please provide 1) the > explanation about the context of the usage of the RRO subobjects for > exclusions (beside what is defined in RFC 3209 Section 4.2.2) and then > 2) why do you think providing two ways to do the same thing as part of > the same document is useful ? > to make it more exact, I will change it into "*information* from RRO subobjects, in speficying the exclusions." toghether with a reference to the RRO-subobjects. >> >>> 9. section 4.2 - condition 4. "The number of introduced SLRGs with >>> the L flag set to "avoid" should be minimised." i guess you mean wrt >>> to the number of "exclude" SRLGs (blocking) ? or is there an absolute >>> limitation due to the message size >> >> >> The sentence you are referring to is not related to the number of >> subobejcts in the XRO. It is related to the number of links belonging >> to SRLGs that should be avoided. > > > please rephrase it - because it is quite difficult to deduce this > meaning (in particular, if a recommendation follows that statement) > >> For instance, when there is a path that has a link with 1 SRLG to be >> avoided, and there is another path with a link of 2 SRLGs to be >> avoided, and there are no alternative paths then take the first path >> because it minimises the number of SLRGs with the L flag set to avoid. >> >> To make it clear, I will change the text as follows: "The number of >> introduced explicit ndoes or abstract nodes in the computed path with >> the L flag set to "avoid" should be minimised. > > > ok - and indicate a sensible reason would help in understanding why - > this is not difficult to be spelled out anyway > ok >>> 10. section 4.2 - concerning the operations i would suggesting adding >>> a rule suggesting that no contradicting exclusions get inserted >> >> >> What is a contradicting exclusion? Do you mean if for instance a node >> appears twice in the XRO, as avoid and exclude? In that case it is >> exclude. I will add a statement. Contradictions with ERO are possible >> but that is mentioned. > > > the document says "If an XRO was present, the content of the XRO can be > modified." so what i mean is that THIS node does not introduce a > exclusion for an subobject it has itself included as part of the ERO (as > the document explains how to process such contradicting exclusions but > should also have clear rules in terms of generation of XROs) > Ok, I see, it should indeed be mentioned somewhere that nodes MUST NOT generate ERO and XRO/EXRS with conflicting information. Nevertheless it remains needed to be said what has to be done when conflicting ERO and XRO/EXRS are received by a node. > >>> 13. section 5.1 >>> >>> " Note: The Most Significant Bit in the Type field could be used to >>> indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating >>> the need to prepend the subobject with an additional TLV header. >>> This would reduce the number bytes require for each subobject by 2 >>> bytes. However, this approach would reduce the ERO Type field space >>> by half. This issue need WG discussion and feedback." >>> >>> -> i would suggest keeping existing definition (since the EXRS is to >>> considered as an optimization), this said better formalization of the >>> EXRS subobjects needs to be provided - as the next section mentions >>> "Each EXRS may carry multiple exclusions. The exclusion is encoded >>> exactly as for XRO subobjects and prefixed by an additional Type and >>> Length." while with the provided alignment it looks like each >>> exclusion element is encoded with this double Type/Length field >> >> >> Thanks for your feedback on this question. Concerning the alignment: >> there can be multiple subobjects in an EXRS, note the plural form of >> "EXRS subobjects" in the first figure of section 5.1. > > > also "The format of this field is exactly the format of an XRO subobject > and may include an SRLG subobject. Both subobjects are as described > earlier in this document." ... both subobjects refers to ? > >> Better to make this more explicit in the specification of "EXRS >> subobjects": One or more EXRS subobjects. An EXRS subobject >> indicates....". For a better alignment it might be better to indeed >> add 2 padding bytes after the Type and Length. > > > ok - i do suggest making use of this padding since we speak about a list > including sub-lists of subobjects and not lists including (double > type/length) subobjects > Ok, I will add 2 padding bytes. >> >>> 4. why section 3.1 is defined as "SRLG ERO Subobject" i think this >>> should better be defined as an "SRLG Subobject" as i do not see a >>> specific reason for having an SRLG subobject outside of the XRO, EXRS >>> context ? >> >> >> not really, see 2 previous comments. It is really an ERO subobject but >> the usage of this in ERO is not part of this document. > > > would it be possible to know which document makes use of SRLG as part of > an ERO ? > see beginning of this email. >> This comes down to the discussion whether XRO defines new subobjects >> specific for XRO or whether XRO simply reuses the ERO subobjects with >> some modifications (L-flag and attribute). So far, the latter has been >> choosen but that means that it is an SRLG ERO subobject. > > > ok - but then indicate that there is no description available of the > usage of an SRLG subobjects as part of an ERO > ok >>> 5. Section 4.1.x - adapt IP address to IPv4 address when defining the >>> IPv4 subobject, etc. >> >> >> yes >> >>> 6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID, >> >> >> see rfc3477, section 4, from where we got the object. In fact, a >> reference to this RFC is missing. > > > this rfc refers to the former but i do suggest using the latter as this > has already generated enough issues > Ok, will change it into "TE Router ID" >>> 7. section 5.1 >>> >>> ""Thus, an EXRO subobject for an IP hop might look as follows:..." ? >>> what do you mean by might ? isn't EXRS instead of EXRO ? >> >> >> "Might" means that there other methods to do the same. For instance, >> if the IP hop is IPv6, it looks different. If unnumbered links are >> used, it is also different. Indeed, EXRO should be EXRS. > > > indeed but might is not really used in a prescptive document (prefer MAY > with alternatives in case) > ok, will use "may" >> >>> 9 "5.2 Semantics and Processing Rules for the EXRS" -> "5.2 >>> Processing Rules for the EXR Subobject and its Subobjects" >> >> >> indeed. should be "5.2 Semantics and Processing Rules for the EXRS and >> its Subobjects". > > > suggest to remove the term semantic since it should be clear from its > definition in section 5.1 > It depends on how the content of this section evolves. It is similar to section 4.2, with similar title. Removign Semantic in both sections looks good to me. regards, Stefaan From owner-ccamp@ops.ietf.org Fri Apr 8 13:49:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17383 for ; Fri, 8 Apr 2005 13:49:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxkr-0002XC-Bc for ccamp-archive@ietf.org; Fri, 08 Apr 2005 13:58:55 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJxR0-000PNS-53 for ccamp-data@psg.com; Fri, 08 Apr 2005 17:38:22 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJxQx-000PNB-8N for ccamp@ops.ietf.org; Fri, 08 Apr 2005 17:38:19 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id 9C40AE000208 for ; Fri, 8 Apr 2005 18:38:09 +0100 (BST) Received: from Puppy ([212.43.203.160] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 18:38:05 +0100 Message-ID: <01cc01c53c61$faba3a10$6fcb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison received from ITU-T Q12/15 and Q14/15 on (G)MPLS Change Procedure Date: Fri, 8 Apr 2005 18:29:11 +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: 08 Apr 2005 17:38:06.0397 (UTC) FILETIME=[B90BA6D0:01C53C61] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hi, We have received the following liaison statement from ITU-T Study Group 15 Questions 12 and 14. Adrian === From: Malcolm Betts, Rapporteur Q12/15 Kam Lam, Rapporteur Q14/15 Title: Liaison Statement to ccamp and mpls WGs on (G)MPLS Change Process For: Information Thank you for your liaison on , which has started to address the issues raised in our previous liaison. We appreciate your efforts towards resolving the concerns raised, and look forward to receiving the next stable version of the draft. An electronic copy of this liaison can be found at ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html From owner-ccamp@ops.ietf.org Fri Apr 8 14:37:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17384 for ; Fri, 8 Apr 2005 13:49:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxkt-0002XG-Ia for ccamp-archive@ietf.org; Fri, 08 Apr 2005 13:58:55 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJxR1-000PNh-F5 for ccamp-data@psg.com; Fri, 08 Apr 2005 17:38:23 +0000 Received: from [62.241.163.7] (helo=blaster.systems.pipex.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DJxR0-000PNU-Fa for ccamp@ops.ietf.org; Fri, 08 Apr 2005 17:38:22 +0000 Received: from dnni.com (81-178-2-190.dsl.pipex.com [81.178.2.190]) by blaster.systems.pipex.net (Postfix) with ESMTP id D0766E00022C for ; Fri, 8 Apr 2005 18:38:18 +0100 (BST) Received: from Puppy ([212.43.203.160] RDNS failed) by dnni.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 18:38:10 +0100 Message-ID: <01cd01c53c61$fda3ec80$6fcb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Liaison received from ITU-T Q12/15 and Q14/15 on RFC 4003 Date: Fri, 8 Apr 2005 18:31:11 +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: 08 Apr 2005 17:38:11.0255 (UTC) FILETIME=[BBF0EC70:01C53C61] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Hi, We have received the following liaison statement from ITU-T Study Group 15 Questions 12 and 14. Adrian === From: Malcolm Betts, Rapporteur Q12/15 Kam Lam, Rapporteur Q14/15 Title: Liaison Statement to IETF CCAMP WG on RFC 4003 For: Information ITU-T SG15 Q14/15 would like to thank you for bringing to our attention the new RFC 4003 on Egress Control. We expect to add RFC 4003 as a reference in future specifications. We are happy to be able to contribute to the discussions of the IETF CCAMP WG and help to further the work on control plane protocols in your group. An electronic copy of this liaison can be found at ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html From owner-ccamp@ops.ietf.org Fri Apr 8 16:31:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09960 for ; Fri, 8 Apr 2005 16:31:37 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK0HV-0004uR-BJ for ccamp-archive@ietf.org; Fri, 08 Apr 2005 16:40:46 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJzzo-000LgE-3T for ccamp-data@psg.com; Fri, 08 Apr 2005 20:22:28 +0000 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DJzzn-000Lg1-4T for ccamp@ops.ietf.org; Fri, 08 Apr 2005 20:22:27 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j38KMJBm078607; Fri, 8 Apr 2005 13:22:19 -0700 (PDT) (envelope-from arthi@juniper.net) Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j38KMIe78653; Fri, 8 Apr 2005 13:22:19 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Fri, 8 Apr 2005 13:22:18 -0700 (PDT) From: Arthi Ayyangar To: Amit 70405 cc: ccamp@ops.ietf.org Subject: Re: About LSP Stiching In-Reply-To: <19f92a19e20e.19e20e19f92a@huawei.com> Message-ID: <20050408114342.W59106@zircon.juniper.net> References: <19f92a19e20e.19e20e19f92a@huawei.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Amit, > There is no way for LSP segment head node, to identify that a > Outif selected is a LSP Segment for setting up E2e LSP. ---> What do you mean ? Why would the head-end of an LSP segment not know that selected nexthop is the LSP segment ? It is the head-end of the LSP segment selecting what you call Outif. > That is Some extension will be needed to RSVP that will allow RSVP > message(for E2e LSP) processing at LSP segment head node to be processed > according to the Sticthing needs. ------> I don't think there is any need for any more extensions..see my explanation above and below. > For Eg: LSP1-2 is an E2e LSP setup over an LSP segment LSPA-B. > > 1-----A--D---E--B-----2 > > Now if A gets the Path message for LSP1-2, and A selects LSP segment LSPA-B as outif. > Then how does RSVP(at Node A) identify that the outif selected is a LSP segment? -------> A is doing nexthop (what you call outif) selection, A is the head-end of LSP segment. A knows that nexthop is an LSP segment. > Also when A receives Resv for LSP1-2(from B), how can it ignore > Label in it. > There should be a way to determine at node A, that a LSP segment > is in use. -----> A chose to stitch the e2e LSP to the LSP segment in the first place. thanks, -arthi > One possible way could be that Resv message for LSP1-2 should be > sent(by B) with some special Label value. > This Label value should indicate the node A that the Resv is > received for a TE-Link(of type LSP Segment). > This will help node A to ignore Label value in Resv msg for E2e > Lsp LSP1-2. From brent@academicplanet.com Mon Apr 11 11:52:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23838 for ; Mon, 11 Apr 2005 11:52:16 -0400 (EDT) Received: from spc1-lanc1-5-0-cust105.asfd.broadband.ntl.com ([80.3.87.105]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DL188-0003eZ-R2 for ccamp-archive@ietf.org; Mon, 11 Apr 2005 11:47:18 -0400 Message-ID: From: "Vanessa J. Smith" To: ccamp-archive@ietf.org Subject: =?iso-8859-1?B?QWRvYmUgUGhvdG9zaG9wIDguMCAtIHdob2xlc2FsZSBwcmljZQ==?= Date: Sun, 10 Apr 2005 20:30:54 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_79AE9017.B3EE5D62" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0000_79AE9017.B3EE5D62 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_FBD96203.5C30DF00" ------=_NextPart_001_0001_FBD96203.5C30DF00 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get all the software possible for unbelievably low prices! Our software is 2-10 times cheaper than sold by our competitors. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Project 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... Visit us at: http://www.bestcds.su Regards, Vanessa Smith _____________________________________________________ To change your mail preferences, go here: http://www.bestcds.su/uns.htm _____________________________________________________ ------=_NextPart_001_0001_FBD96203.5C30DF00 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Get access to all the software imaginable for prices substantially lower than in stores!
Our software is 2-10 times cheaper than sold by our competitors.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 Quark Xpress 6 Passport Multilanguage

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

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

http://www.bestcds.su

Sincerely,
Vanessa J. Smith


_____________________________________________________
To change your mail details, go: http://www.bestcds.su/uns.htm
_____________________________________________________

------=_NextPart_001_0001_FBD96203.5C30DF00-- ------=_NextPart_000_0000_79AE9017.B3EE5D62-- From owner-ccamp@ops.ietf.org Mon Apr 11 13:59:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04989 for ; Mon, 11 Apr 2005 13:59:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3Ll-0008K5-MB for ccamp-archive@ietf.org; Mon, 11 Apr 2005 14:09:32 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DL32Q-000P5V-Ud for ccamp-data@psg.com; Mon, 11 Apr 2005 17:49:30 +0000 Received: from [192.75.23.69] (helo=tm2.ca.alcatel.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DL32F-000P1n-Ss; Mon, 11 Apr 2005 17:49:20 +0000 Received: from alcatel.com (localhost [127.0.0.1]) by tm2.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j3BHn36g000309; Mon, 11 Apr 2005 13:49:03 -0400 (EDT) Message-ID: <425AB882.7C4DAD42@alcatel.com> Date: Mon, 11 Apr 2005 13:48:50 -0400 From: Cheng-Yin Lee X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: stefaan.de_cnodder@alcatel.be CC: dpapadimitriou@psg.com, dimitri.papadimitriou@alcatel.be, ccamp@ops.ietf.org, kireeti Kompella , Adrian Farrel Subject: Re: WG last calls - comments ondraft-ietf-ccamp-rsvp-te-exclude-route-03.txt References: <425250D8.8050809@psg.com> <4253E24B.3090109@alcatel.be> <4254E6FF.6080301@psg.com> <42557DD4.6000206@alcatel.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Content-Transfer-Encoding: 7bit Hi Stefaan, Dimitri, stefaan.de_cnodder@alcatel.be wrote: > Hi Dimitri, > > see below for responses... > > >> > >>> 3. section 4.1 > >>> > >>> "The subobjects are identical to > >>> those defined in [RFC3209] and [RFC3473] for use in EROs." > >>> > >>> looking at the definitions this is not the case (moreover the SRLG > >>> subobject has been added) - > >> > >> > >> Are you only referring to the SRLG subobject? If yes, then it is best > >> to change it into "...those defined in [RFC3209] and [RFC3473] for use > >> in EROs and section 3.1 of this document." > > > > > > -> yes, but also ERO subobjects do not include an attribute field, XRO > > subobjects do > > > > Correct. We use ERO subobjects with these modifications. There has been > discussion in the past whether we reuse ERO subobjects and modify to > make them useful for XRO, or whether we define for the XRO new > subobjects. So far, the decision was to do the former but this is of > course open for discussion. The consequence is that when we want to > exclude something in the XRO, we also need the corresponding to include > it in the ERO. For SRLGs this means that we need an SRLG ERO subobject > which is not defined previously. It does not make much sense to have an > SRLG ERO subobject (that is why you would not find a document describing > the processing rules of such an object in the ERO), but it is needed for > the corresponding subobject in the XRO. Perhaps it is sufficient to say something along the line : "This specification adapts ERO subobjects for use in route exclusions. The SRLG ERO subobject and its processing within an ERO have not been defined before. The SRLG ERO subobject is defined here for use with route exclusion." SRLG ERO processing for route inclusion, if required, is out of scope but I think it is better that the Exclude Route spec does not rule out/talk about the use of SRLG ERO in route inclusion for whatever reasons ... Thanks Cheng-Yin > > > >>> 4. section 4.1 > >>> > >>> " An Attribute octet is introduced in the subobjects that define IP > >>> addresses to indicate the attribute (e.g. interface, node, SRLG) > >>> associated with the IP addresses that can be excluded from the path." > >>> > >>> what is a subobject that define IP addresses ? > >> > >> > >> see following subsections. Is it enough that I change "IP address" > >> into "IP prefix" to make it more clear? > > > > > > wouldn't be better to refer to the subobject types instead, something > > like (concerning the > > > > "An Attribute field is introduced in the subobjects Type 1, 2 and 4 to > > indicate the attribute (e.g. interface, node, SRLG) that is associated > > with the IP address included as part of the subobject and that can be > > excluded from the path." > > > > Sounds better. I will do that. I will also remove the word "IP address" > because unnumbered (type 4) is not really an IP address. > > > also definition of the attribute value should refer better to "IPv4 or > > IPv6 address treated as an prefix based on the prefix length value" > > > > last point but this is editorial, currently you have > > > > 4.1.1 Subobject 1: IPv4 prefix > > 4.1.2 Subobject 2: IPv6 Prefix > > 4.1.3 Subobject 32: Autonomous System Number > > 4.1.4 Subobject TBD: SRLG > > 4.1.5 Subobject 4: Unnumbered Interface ID Subobject > > > > wouldn't it be better to list them as > > > > 4.1.1 Subobject 1: IPv4 prefix > > 4.1.2 Subobject 2: IPv6 Prefix > > 4.1.3 Subobject 4: Unnumbered Interface ID Subobject > > 4.1.4 Subobject 32: Autonomous System Number > > 4.1.5 Subobject TBD: SRLG > > > > yes > > >>> 5. section 4.1 > >>> > >>> " For instance, the attribute node allows a whole node to be excluded > >>> from the path, in contrast to the attribute interface, which allows > >>> specific interfaces to be excluded from the path. " > >>> > >>> but below the definition says "0 indicates that the interface or set > >>> of interfaces associated with the IP prefix should be excluded or > >>> avoided" which makes the term specific ambiguous > >> > >> > >> Section 4.1 is an example on how to exclude a node or an interface > >> from a path. Section 4.1.1 contains the full specification and the > >> example looks to be contained in 4.1.1. > > > > > > indeed, this is what i understood, my question is more "how can you be > > specific if you remove a set of interfaces" > > > > ??? Is it OK if I change it into "For instance, the attribute node > allows a whole node to be excluded from the path, in contrast to the > attribute interface, which allows a specific interface or set of > interfaces to be excluded from the path." > > Note that the interfaces in the set of interfaces does not have to be on > the same node. > > >>> 6. section 4.1.5 > >>> > >>> " node > >>> > >>> 1 indicates that the node with the Router ID should be > >>> excluded or avoided (this can be achieved using IPv4/v6 > >>> subobject as well, but is included here because it may be > >>> convenient to use subobjects from RRO, in specifying the > >>> exclusions)" > >>> > >>> until "(this can be achieved using IPv4/v6 subobject" i understand > >>> after i would ask you to clarify i guess you mean RRO from another > >>> path ? should you include this as part of the definition ? > >> > >> > >> Can you give an example on how the exlude/avoid resources from a path > >> computation while the path is already computed and signaled (otherwise > >> you do not have an RRO)? > > > > > > you signal a first LSP, at the ingress you recuperate the (Resv) RRO > > that you inject (may be after some transformation) as part of the XRO of > > another LSP (load balancing for inst.) > > > > now concerning the initial point (as i do not understand what you mean > > by "use RRO subobjects for exclusion" to achieve the same functionality > > as an XRO with the Type 4 subobject) would you please provide 1) the > > explanation about the context of the usage of the RRO subobjects for > > exclusions (beside what is defined in RFC 3209 Section 4.2.2) and then > > 2) why do you think providing two ways to do the same thing as part of > > the same document is useful ? > > > > to make it more exact, I will change it into "*information* from RRO > subobjects, in speficying the exclusions." toghether with a reference to > the RRO-subobjects. > > >> > >>> 9. section 4.2 - condition 4. "The number of introduced SLRGs with > >>> the L flag set to "avoid" should be minimised." i guess you mean wrt > >>> to the number of "exclude" SRLGs (blocking) ? or is there an absolute > >>> limitation due to the message size > >> > >> > >> The sentence you are referring to is not related to the number of > >> subobejcts in the XRO. It is related to the number of links belonging > >> to SRLGs that should be avoided. > > > > > > please rephrase it - because it is quite difficult to deduce this > > meaning (in particular, if a recommendation follows that statement) > > > >> For instance, when there is a path that has a link with 1 SRLG to be > >> avoided, and there is another path with a link of 2 SRLGs to be > >> avoided, and there are no alternative paths then take the first path > >> because it minimises the number of SLRGs with the L flag set to avoid. > >> > >> To make it clear, I will change the text as follows: "The number of > >> introduced explicit ndoes or abstract nodes in the computed path with > >> the L flag set to "avoid" should be minimised. > > > > > > ok - and indicate a sensible reason would help in understanding why - > > this is not difficult to be spelled out anyway > > > > ok > > >>> 10. section 4.2 - concerning the operations i would suggesting adding > >>> a rule suggesting that no contradicting exclusions get inserted > >> > >> > >> What is a contradicting exclusion? Do you mean if for instance a node > >> appears twice in the XRO, as avoid and exclude? In that case it is > >> exclude. I will add a statement. Contradictions with ERO are possible > >> but that is mentioned. > > > > > > the document says "If an XRO was present, the content of the XRO can be > > modified." so what i mean is that THIS node does not introduce a > > exclusion for an subobject it has itself included as part of the ERO (as > > the document explains how to process such contradicting exclusions but > > should also have clear rules in terms of generation of XROs) > > > > Ok, I see, it should indeed be mentioned somewhere that nodes MUST NOT > generate ERO and XRO/EXRS with conflicting information. Nevertheless it > remains needed to be said what has to be done when conflicting ERO and > XRO/EXRS are received by a node. > > > > >>> 13. section 5.1 > >>> > >>> " Note: The Most Significant Bit in the Type field could be used to > >>> indicate exclusion of IPv4/IPv6, AS and SRLG subobjects, eliminating > >>> the need to prepend the subobject with an additional TLV header. > >>> This would reduce the number bytes require for each subobject by 2 > >>> bytes. However, this approach would reduce the ERO Type field space > >>> by half. This issue need WG discussion and feedback." > >>> > >>> -> i would suggest keeping existing definition (since the EXRS is to > >>> considered as an optimization), this said better formalization of the > >>> EXRS subobjects needs to be provided - as the next section mentions > >>> "Each EXRS may carry multiple exclusions. The exclusion is encoded > >>> exactly as for XRO subobjects and prefixed by an additional Type and > >>> Length." while with the provided alignment it looks like each > >>> exclusion element is encoded with this double Type/Length field > >> > >> > >> Thanks for your feedback on this question. Concerning the alignment: > >> there can be multiple subobjects in an EXRS, note the plural form of > >> "EXRS subobjects" in the first figure of section 5.1. > > > > > > also "The format of this field is exactly the format of an XRO subobject > > and may include an SRLG subobject. Both subobjects are as described > > earlier in this document." ... both subobjects refers to ? > > > >> Better to make this more explicit in the specification of "EXRS > >> subobjects": One or more EXRS subobjects. An EXRS subobject > >> indicates....". For a better alignment it might be better to indeed > >> add 2 padding bytes after the Type and Length. > > > > > > ok - i do suggest making use of this padding since we speak about a list > > including sub-lists of subobjects and not lists including (double > > type/length) subobjects > > > > Ok, I will add 2 padding bytes. > > >> > >>> 4. why section 3.1 is defined as "SRLG ERO Subobject" i think this > >>> should better be defined as an "SRLG Subobject" as i do not see a > >>> specific reason for having an SRLG subobject outside of the XRO, EXRS > >>> context ? > >> > >> > >> not really, see 2 previous comments. It is really an ERO subobject but > >> the usage of this in ERO is not part of this document. > > > > > > would it be possible to know which document makes use of SRLG as part of > > an ERO ? > > > > see beginning of this email. > > >> This comes down to the discussion whether XRO defines new subobjects > >> specific for XRO or whether XRO simply reuses the ERO subobjects with > >> some modifications (L-flag and attribute). So far, the latter has been > >> choosen but that means that it is an SRLG ERO subobject. > > > > > > ok - but then indicate that there is no description available of the > > usage of an SRLG subobjects as part of an ERO > > > > ok > > >>> 5. Section 4.1.x - adapt IP address to IPv4 address when defining the > >>> IPv4 subobject, etc. > >> > >> > >> yes > >> > >>> 6. Section 4.1.5 - either use the term LSR Router ID or TE Router ID, > >> > >> > >> see rfc3477, section 4, from where we got the object. In fact, a > >> reference to this RFC is missing. > > > > > > this rfc refers to the former but i do suggest using the latter as this > > has already generated enough issues > > > > Ok, will change it into "TE Router ID" > > >>> 7. section 5.1 > >>> > >>> ""Thus, an EXRO subobject for an IP hop might look as follows:..." ? > >>> what do you mean by might ? isn't EXRS instead of EXRO ? > >> > >> > >> "Might" means that there other methods to do the same. For instance, > >> if the IP hop is IPv6, it looks different. If unnumbered links are > >> used, it is also different. Indeed, EXRO should be EXRS. > > > > > > indeed but might is not really used in a prescptive document (prefer MAY > > with alternatives in case) > > > > ok, will use "may" > > >> > >>> 9 "5.2 Semantics and Processing Rules for the EXRS" -> "5.2 > >>> Processing Rules for the EXR Subobject and its Subobjects" > >> > >> > >> indeed. should be "5.2 Semantics and Processing Rules for the EXRS and > >> its Subobjects". > > > > > > suggest to remove the term semantic since it should be clear from its > > definition in section 5.1 > > > > It depends on how the content of this section evolves. It is similar to > section 4.2, with similar title. Removign Semantic in both sections > looks good to me. > > regards, > > Stefaan From owner-ccamp@ops.ietf.org Tue Apr 12 03:46:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04632 for ; Tue, 12 Apr 2005 03:46:48 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGGE-0007rR-9i for ccamp-archive@ietf.org; Tue, 12 Apr 2005 03:56:42 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLFw0-000KnV-FY for ccamp-data@psg.com; Tue, 12 Apr 2005 07:35:44 +0000 Received: from [63.250.163.245] (helo=huawei.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLFvy-000Kn1-4E for ccamp@ops.ietf.org; Tue, 12 Apr 2005 07:35:42 +0000 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IET00E9DOXRIL@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 12 Apr 2005 00:32:16 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IET00F5TOXQGT@usaga01-in.huawei.com> for ccamp@ops.ietf.org; Tue, 12 Apr 2005 00:32:15 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Tue, 12 Apr 2005 15:36:16 +0800 Date: Tue, 12 Apr 2005 15:36:16 +0800 From: Amit 70405 Subject: Re: About LSP Stitching To: ccamp@ops.ietf.org Message-id: <2f49222f1619.2f16192f4922@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7BIT Hi Arthi, Thanks for replying. Below are the two main assumptions on which my query is based. Plz correct me if I am wrong. 1. E2e LSP & LSP segment are two independant LSP's. 2. TE-Link is a kind of abstraction. User of TE-Link should not know about the implementation details of the TE-Link. Whether it is a FA or a LSP segment as a TE-Link, an LSP setting up over these TE-Link should not be aware of the TE-Link setup details(whether its a FA or a LSP segment or a Physical Interface or others). So if we go by this, the below example which i gave holds true. Plz let me know your view on this. Thanks and regards, Amit. ----- Original Message ----- From: Arthi Ayyangar Date: Saturday, April 9, 2005 4:22 am Subject: Re: About LSP Stiching > Amit, > > > There is no way for LSP segment head node, to identify that a > > Outif selected is a LSP Segment for setting up E2e LSP. > ---> What do you mean ? Why would the head-end of an LSP segment > not know > that selected nexthop is the LSP segment ? It is the head-end of > the LSP > segment selecting what you call Outif. > > > > That is Some extension will be needed to RSVP that will allow RSVP > > message(for E2e LSP) processing at LSP segment head node to be > processed> according to the Sticthing needs. > ------> I don't think there is any need for any more > extensions..see my > explanation above and below. > > > > For Eg: LSP1-2 is an E2e LSP setup over an LSP segment LSPA-B. > > > > 1-----A--D---E--B-----2 > > > > Now if A gets the Path message for LSP1-2, and A selects LSP > segment LSPA-B as outif. > > Then how does RSVP(at Node A) identify that the outif selected is > a LSP segment? > -------> A is doing nexthop (what you call outif) selection, A is the > head-end of LSP segment. A knows that nexthop is an LSP segment. > > > > Also when A receives Resv for LSP1-2(from B), how can it ignore > > Label in it. > > There should be a way to determine at node A, that a LSP segment > > is in use. > -----> A chose to stitch the e2e LSP to the LSP segment in the > first place. > > thanks, > -arthi > > > > > One possible way could be that Resv message for LSP1-2 should be > > sent(by B) with some special Label value. > > This Label value should indicate the node A that the Resv is > > received for a TE-Link(of type LSP Segment). > > This will help node A to ignore Label value in Resv msg for E2e > > Lsp LSP1-2. > > From owner-ccamp@ops.ietf.org Tue Apr 12 18:05:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16646 for ; Tue, 12 Apr 2005 18:05:02 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTex-0001Z0-2w for ccamp-archive@ietf.org; Tue, 12 Apr 2005 18:15:04 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLTIU-000HaA-7q for ccamp-data@psg.com; Tue, 12 Apr 2005 21:51:50 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DLTIT-000HZr-FB for ccamp@ops.ietf.org; Tue, 12 Apr 2005 21:51:49 +0000 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DLTI7-0000wu-26; Tue, 12 Apr 2005 17:51:27 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , ccamp mailing list , ccamp chair , ccamp chair Subject: Protocol Action: 'Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification' to Proposed Standard Message-Id: Date: Tue, 12 Apr 2005 17:51:27 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 The IESG has approved the following documents: - 'Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification ' as a Proposed Standard - 'Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) ' as an Informational RFC - 'Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) ' as an Informational RFC These documents are products of the Common Control and Measurement Plane Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. Technical Summary This set of documents presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e. protection and restoration). Protocol specific formats and mechanisms will be described in subsequent documents. Working Group Summary The WG had a consensus on advancing these documents and addressed AD-review comments. Protocol Quality These documents have been reviewed for the IESG by Alex Zinin. From owner-ccamp@ops.ietf.org Wed Apr 13 11:33:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06436 for ; Wed, 13 Apr 2005 11:33:31 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLk1l-00023j-MS for ccamp-archive@ietf.org; Wed, 13 Apr 2005 11:43:42 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLjbS-0002Yk-Lf for ccamp-data@psg.com; Wed, 13 Apr 2005 15:16:30 +0000 Received: from [205.177.121.2] (helo=ns1.cpanel.btnaccess.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DLjbP-0002YF-Jj for ccamp@ops.ietf.org; Wed, 13 Apr 2005 15:16:27 +0000 Received: from cpanel by ns1.cpanel.btnaccess.com with local (Exim 4.50) id 1DLjbN-0006P7-CO for ccamp@ops.ietf.org; Wed, 13 Apr 2005 11:16:25 -0400 Received: from 65.213.193.37 ([65.213.193.37]) by isocore.com (Horde) with HTTP for ; Wed, 13 Apr 2005 11:16:25 -0400 Message-ID: <20050413111625.7oih0dfig3h8gwc0@isocore.com> Date: Wed, 13 Apr 2005 11:16:25 -0400 From: kkhanna@isocore.com To: ccamp@ops.ietf.org Subject: MPLS 2005 Call for Presentations (Oct 16-19, Wash. DC) References: <20050411103326.iapygmv6qre0o4os@isocore.com> In-Reply-To: <20050411103326.iapygmv6qre0o4os@isocore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32001 502] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_40,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit ===================================== MPLS 2005 International Conference http://www.mpls2005.com October 16-19, 2005 Washington, DC ====================================== The Program Committee of MPLS2005 () is soliciting presentation proposals for this conference. If you wish to suggest a particular topic or a contribution, please send a one page long proposal (including speaker's contact details) to the attention of the Technical Program Committee at mpls2005-cfp@isocore.com by June 10, 2005. This year's conference will include, but not be limited to, topics such as: - MPLS in multi-area and multi-AS networks - Point-to-multipoint MPLS and applications - Supporting multicast in MPLS VPNs and for VPLS - Single and Multi-hop Pseudowire placement, setup and management - Providing QoS in MPLS networks - MPLS network management - OAM for MPLS networks - MPLS in the Next Generation Network - Voice over IP/MPLS - Triple-play applications on MPLS - MPLS-enabled Advanced services and converged networks - Interworking and migration for MPLS and GMPLS - Multi-layer networks and integration with non-packet technologies - Deploying, interworking and operating L2 and L3 MPLS VPNs - MPLS deployment experience: scaling, performance and security - Testing the technology: MPLS test tools and experience - Protection, restoration and reliability - Network processors for MPLS and GMPLS - MPLS/GMPLS control plane resilience, scaling and robustness - MPLS TE applications of the Path Computation Element (PCE) - Motivations and requirements for extending MPLS into the access network The program committee is looking for original and unpublished work to continue the tradition initiated by this conference in 1998 of covering cutting-edge topics. Presentations from the vendor, service provider, research and user community are solicited on new technologies and operational experience. REGISTRATION is also now open, with extremely lucrative early-bird discounts - visit for details. Thank you for your continued support. Regards, Kavita From owner-ccamp@ops.ietf.org Wed Apr 13 20:49:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24453 for ; Wed, 13 Apr 2005 20:49:30 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLshs-0001bJ-Sh for ccamp-archive@ietf.org; Wed, 13 Apr 2005 20:59:45 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLsPW-0004jO-Hd for ccamp-data@psg.com; Thu, 14 Apr 2005 00:40:46 +0000 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DLsPV-0004j2-Dy for ccamp@ops.ietf.org; Thu, 14 Apr 2005 00:40:45 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j3E0eiBm026864; Wed, 13 Apr 2005 17:40:44 -0700 (PDT) (envelope-from arthi@juniper.net) Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j3E0eie35068; Wed, 13 Apr 2005 17:40:44 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Wed, 13 Apr 2005 17:40:44 -0700 (PDT) From: Arthi Ayyangar To: adrian@olddog.co.uk, Kireeti Kompella cc: ccamp@ops.ietf.org Subject: WG last calls - cranback ID In-Reply-To: <20050331073357.R83270@kummer.juniper.net> Message-ID: <20050413171348.I38188@zircon.juniper.net> References: <20050331073357.R83270@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Hi Adrian, Here are some comments (marked ) on the crankback ID. thanks, -arthi --------- 1.1 typo : documentaiton 2.2 Crankback routing schemes could be used to notify the upstream LSRs of the location of the failure. Do you mean "Cranback signaling schemes could be used to notify" ? ---------- I observed that in some places crankback signaling and cranback routing are used interchangeably. Need to clarify ? 4.2.2 If the crankback information can be used to compute a new route avoiding the blocking problem, the route can be signaled as an Explicit Route. How about "If the crankback information can be used to compute a new path avoiding the blocking problem, the path can be signaled with a new Explicit Route." 7.2 What is the PROPOSED_ERO for ? Why can't the node doing crankback re-routing simply figure out the new path based on constraints and failures history in the downsstream network that he probably understands best ? Why do we want the node reporting error to suggest an ERO ? Same question about 26 and 27 as well. It would be intuitive if the node reporting failures simply reports the failure and leaves the guesswork and computation to the node taking the re-routing action. That way the reponsibility of each node is well-defined. Also, it is the node doing the re-route that has the bigger picture in the end. 7.3.1 I am not too sure of the following statement:- "If crankback is being used, the sender of a PathErr, ResvErr or Notify message MUST use the IF_ID ERROR_SPEC object and MUST include at least one of the TLVs in the range 1 through 3 as described in [RFC3473], [BUNDLE], and previous paragraph." The assumption here is that IF_ID ERROR_SPEC is always being used. In section 5.1 we acknowledge that with RSVP-TE crankback re-routing can be performed explicitly avoiding the node or interface reported in ERROR_SPEC; i.e. no TLVs. So, the above sentence is only true in the context of GMPLS RSVP-TE. You may want to clarify this once somewhere. 7.3.3 An LSR that proposes to perform crankback re-routing SHOULD support receipt and processing of all of the fundamental crankback TLVs, and is RECOMMENDED to support the receipt and processing of the additional crankback TLVs. Why is the requirement for 'crankback re-routing' different from that for 'crankback' in section 7.2 ? Why isn't it enough for the LSR to support just the Error Report TLVs (1-3) in order to perform cranback re-routing ? What information does DOWNSTREAM_LABEL and UPSTREAM LABEL provide to some node several hops upstream ? How is the node doing cranback re-routing going to use this info and enforce it along the new path? 7.4.4 When Re-routing Fails However, when a node was responsible for expanding or replacing the explicit route as the LSP setup was processed it MUST update the crankback information with regard to the explicit route that it received. Only if this is done will the upstream nodes stand a chance of successfully routing around the problem. When you say "update", is the LSR replacing old crankback info with new crankback info that it generates or is it appending this to received crankback info in PathErr ? Also, is this a new PathErr (with a new src addr) or the same PathErr that was received ? The reason I bring this up is because elsewhere in the doc, you talk about intercepting and terminating the error. I think you should clarify this in this section. 7.5. Notification of Errors Is this section missing PathErr because it has been discussed in the rest of the document ? -------- > This is to initiate CCAMP WG last calls on: > > draft-ietf-ccamp-crankback-04.txt > > and > > draft-ietf-ccamp-rsvp-te-exclude-route-03.txt > > Please send your comments to the list (preferably) or to the authors > by April 14, 23:59 GMT (which is when the last calls end). > > Thanks, > Kireeti. > ------- > From owner-ccamp@ops.ietf.org Wed Apr 13 22:49:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01996 for ; Wed, 13 Apr 2005 22:49:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLuaI-0004W4-No for ccamp-archive@ietf.org; Wed, 13 Apr 2005 23:00:03 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLuJw-000Mts-Lo for ccamp-data@psg.com; Thu, 14 Apr 2005 02:43:08 +0000 Received: from [207.17.137.57] (helo=colo-dns-ext1.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.44 (FreeBSD)) id 1DLuJv-000MtW-SP for ccamp@ops.ietf.org; Thu, 14 Apr 2005 02:43:07 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j3E2gm925927; Wed, 13 Apr 2005 19:42:48 -0700 (PDT) (envelope-from arthi@juniper.net) Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j3E2gZe56750; Wed, 13 Apr 2005 19:42:38 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Wed, 13 Apr 2005 19:42:35 -0700 (PDT) From: Arthi Ayyangar To: Adrian Farrel , kireeti Kompella cc: Cheng-Yin.Lee@alcatel.com, stefaan.de_cnodder@alcatel.be, "ccamp@ops.ietf.org" Subject: WG last calls - exclude route ID In-Reply-To: <425250D8.8050809@psg.com> Message-ID: <20050413193853.O38188@zircon.juniper.net> References: <425250D8.8050809@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Hi, Here are a few comments on this ID. Sorry for the delay. Also, in case some of these comments are a repetition, please ignore those. thanks, -arthi ---------------- 1) Section 2. To convey these constructs within the signaling protocol, a new RSVP object and a new ERO subobject are introcuded respectively. ^^^^^^^^^^^ - Typo 2) Section 4.2 The number of introduced exlicit nodes or abstract nodes with ^^^^^^^^^^ the L flag set to "avoid" should be minimised. - Typo 3) 5.2 Each EXRS may carry multiple exclusions. The exclusion is encoded --------------------------------------- exactly as for XRO subobjects and prefixed by an additional Type and Length. Did you mean, there can be multiple EXRS per ERO, which I see or multiple exclusions per EXRS ? From the format of the EXRS it looks like one exclusion per EXRS. Did I miss something ? 4) Thus, an EXRO subobject for an IP hop might look as follows: ^^^^^^^^^^^^^^^^^ EXRS ? Also the S in EXRS already means sub-object, so you could get rid of sub-object following EXRS. 5) The subobjects in the ERO and EXRS SHOULD not contradict each other. If they do contradict, the subobjects with the L bit not set, strict or MUST be excluded, respectively, in the ERO or XRO MUST take pre- cedence. If there is still a conflict, the subobjects in the ERO MUST take precedence. You may want to state explicitly what you mean by contradict for EXRS. Is the scope of contradiction just the previous and next ERO sub-objects ? 6) If the presence of EXRO Subobjects precludes further forwarding of ^^^^^^^^^^^^^^^^^ the Path message, the node should return a PathErr with the error code "Routing Problem" and error value of "Route blocked by Exclude Route" 7) With respect to EXRS, it might be useful to clarify what does EXRS provide that cannot be achieved by XRO. Basically give some hints as to where EXRS may be useful versus XRO. Also, can there be conflicts between EXRS and XRO ? If yes, then how is that dealt with ? 8) Section 6 The IPv6 Prefix subobject MUST be supported with a prefix length of 128, and an attriubute value of "interface" and ^^^^^^^^^^^^ "node". - Typo ----------------- From owner-ccamp@ops.ietf.org Thu Apr 14 01:03:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10760 for ; Thu, 14 Apr 2005 01:03:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLwg7-0007sz-Cv for ccamp-archive@ietf.org; Thu, 14 Apr 2005 01:14:11 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DLwOO-000FZs-Qa for ccamp-data@psg.com; Thu, 14 Apr 2005 04:55:52 +0000 Received: from [192.75.23.69] (helo=tm1.ca.alcatel.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DLwON-000FZR-MY for ccamp@ops.ietf.org; Thu, 14 Apr 2005 04:55:51 +0000 Received: from alcatel.com (localhost [127.0.0.1]) by tm1.ca.alcatel.com (8.13.0/8.13.0) with ESMTP id j3E4tdS1011540; Thu, 14 Apr 2005 00:55:39 -0400 (EDT) Message-ID: <425DF7BE.F190CAB5@alcatel.com> Date: Thu, 14 Apr 2005 00:55:26 -0400 From: Cheng-Yin Lee X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Arthi Ayyangar CC: Adrian Farrel , kireeti Kompella , stefaan.de_cnodder@alcatel.be, "ccamp@ops.ietf.org" Subject: Re: WG last calls - exclude route ID References: <425250D8.8050809@psg.com> <20050413193853.O38188@zircon.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Hi Arthi, Thanks for your comments. Arthi Ayyangar wrote: > Hi, > > Here are a few comments on this ID. Sorry for the delay. > Also, in case some of these comments are a repetition, please ignore > those. > > thanks, > -arthi > ---------------- > 1) > Section 2. > > To convey these constructs within the signaling protocol, a new > RSVP object and a new ERO subobject are introcuded respectively. > ^^^^^^^^^^^ > - Typo > > 2) > Section 4.2 > The number of introduced exlicit nodes or abstract nodes with > ^^^^^^^^^^ > the L flag set to "avoid" should be minimised. > > - Typo Ok, we should run spell check. > > 3) > 5.2 > Each EXRS may carry multiple exclusions. The exclusion is encoded > --------------------------------------- > exactly as for XRO subobjects and prefixed by an additional Type and > Length. > > Did you mean, there can be multiple EXRS per ERO, which I see or > multiple exclusions per EXRS ? > From the format of the EXRS it looks like one exclusion per EXRS. > Did I miss something ? there can be multiple EXRS per ERO multiple subobjects can be specified in an EXRS > > > 4) > Thus, an EXRO subobject for an IP hop might look as follows: > ^^^^^^^^^^^^^^^^^ > EXRS ? Yes. > Also the S in EXRS already means sub-object, so you could get > rid of sub-object following EXRS. ok. > 5) > The subobjects in the ERO and EXRS SHOULD not contradict each other. > If they do contradict, the subobjects with the L bit not set, strict > or MUST be excluded, respectively, in the ERO or XRO MUST take pre- > cedence. If there is still a conflict, the subobjects in the ERO > MUST take precedence. > > You may want to state explicitly what you mean by contradict for > EXRS. Is the scope of contradiction just the previous and next ERO > sub-objects ? Yes. This may not be a contradiction. We will think of some text to clarify this. > > 6) > If the presence of EXRO Subobjects precludes further forwarding of > ^^^^^^^^^^^^^^^^^ > the Path message, the node should return a PathErr with the error > code "Routing Problem" and error value of "Route blocked by Exclude > Route" > > 7) > With respect to EXRS, it might be useful to clarify what does EXRS > provide that cannot be achieved by XRO. Basically give some hints as to > where EXRS may be useful versus XRO. EXRS - If we need to exclude a resource between A and B only (could be a policy thing), but may want to use the resource elsewhere in the path. > Also, can there be conflicts between > EXRS and XRO ? If yes, then how is that dealt with ? I can't think of conflicts between EXRS and XRO, if X is excluded by EXRS and XRO, then it is just redundant to specify X in EXRS. > > 8) Section 6 > > The IPv6 Prefix subobject MUST be supported with a prefix > length of 128, and an attriubute value of "interface" and > ^^^^^^^^^^^^ > "node". > - Typo > > ----------------- Thanks Cheng-Yin From owner-ccamp@ops.ietf.org Fri Apr 15 08:07:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23233 for ; Fri, 15 Apr 2005 08:07:23 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMPlh-0003Ek-VT for ccamp-archive@ietf.org; Fri, 15 Apr 2005 08:17:56 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMPPJ-000HQ5-NJ for ccamp-data@psg.com; Fri, 15 Apr 2005 11:54:45 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DMPPI-000HPn-Pf for ccamp@ops.ietf.org; Fri, 15 Apr 2005 11:54:44 +0000 Received: from du-203-126.nat.dialup.claranet.fr ([212.43.203.126] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DMPPG-000E83-IB for ccamp@ops.ietf.org; Fri, 15 Apr 2005 12:54:43 +0100 Message-ID: <034201c541b2$2cd025f0$cdcb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Last call complete on Exclude Route and Crankback Date: Fri, 15 Apr 2005 12:28: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.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Thanks all for your comments on and off the list. The editors and authors will update the drafts and answer any specific technical questions. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Apr 15 15:42:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10020 for ; Fri, 15 Apr 2005 15:42:31 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWsF-00021P-Ue for ccamp-archive@ietf.org; Fri, 15 Apr 2005 15:53:09 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMWZT-000M4E-QD for ccamp-data@psg.com; Fri, 15 Apr 2005 19:33:43 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DMWZR-000M3n-4m for ccamp@ops.ietf.org; Fri, 15 Apr 2005 19:33:43 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08196; Fri, 15 Apr 2005 15:33:38 -0400 (EDT) Message-Id: <200504151933.PAA08196@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt Date: Fri, 15 Apr 2005 15:33:38 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.4 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --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 : A Per-domain path computation method for computing Inter-domain Traffic Engineering (TE) Label Switched Path (LSP) Author(s) : J. Vasseur, et al. Filename : draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt Pages : 0 Date : 2005-4-15 This document specifies a per-domain path computation method for computing inter-domain Traffic Engineering (TE) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched (LSP) paths. In this document a domain is referred to as a collection of network elements within a common sphere of address management or path computational responsibility such as IGP areas and Autonomous Systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-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-ietf-ccamp-inter-domain-pd-path-comp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-15152449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-inter-domain-pd-path-comp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-15152449.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Apr 15 18:30:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06052 for ; Fri, 15 Apr 2005 18:30:42 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZV3-00062i-FY for ccamp-archive@ietf.org; Fri, 15 Apr 2005 18:41:22 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMZCP-000FNu-Nb for ccamp-data@psg.com; Fri, 15 Apr 2005 22:22:05 +0000 Received: from [66.129.224.36] (helo=kummer.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMZCO-000FNZ-P7 for ccamp@ops.ietf.org; Fri, 15 Apr 2005 22:22:04 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j3FMM41l031612 for ; Fri, 15 Apr 2005 15:22:04 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j3FMM4IZ031609 for ; Fri, 15 Apr 2005 15:22:04 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 15 Apr 2005 15:22:04 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Addressing doc Message-ID: <20050415151514.K30910@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 A new version of this draft has been posted as draft-shiomoto-ccamp-gmpls-addressing-01.txt . Please reply to this email on whether or not you think this should be a CCAMP WG doc. Adrian and I will gauge consensus based on the mail received until Fri April 22, 23:59 UTC. Thanks, Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Apr 15 18:31:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06146 for ; Fri, 15 Apr 2005 18:31:58 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZWH-00066i-PQ for ccamp-archive@ietf.org; Fri, 15 Apr 2005 18:42:39 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMZG8-000FhF-Cz for ccamp-data@psg.com; Fri, 15 Apr 2005 22:25:56 +0000 Received: from [66.129.224.36] (helo=kummer.juniper.net) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44 (FreeBSD)) id 1DMZG7-000Fgv-HK for ccamp@ops.ietf.org; Fri, 15 Apr 2005 22:25:55 +0000 Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id j3FMPt1l031629 for ; Fri, 15 Apr 2005 15:25:55 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id j3FMPt6b031626 for ; Fri, 15 Apr 2005 15:25:55 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Fri, 15 Apr 2005 15:25:55 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: GMPLS MIBs Message-ID: <20050415152248.V30910@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 This is to announce a two-week WG Last Call on the GMPLS MIB doc set. Please send in your comments by Fri April 29, 23:59 UTC. [Tom P, thanks for the comments you already sent. You need not send them again; they will be handled with the rest of the LC comments. If you have more comments, of course please do send them in.] Kireeti. ------- From owner-ccamp@ops.ietf.org Fri Apr 15 22:39:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11210 for ; Fri, 15 Apr 2005 22:39:48 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMdO9-0001Zi-B4 for ccamp-archive@ietf.org; Fri, 15 Apr 2005 22:50:30 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMd4v-000D9g-3l for ccamp-data@psg.com; Sat, 16 Apr 2005 02:30:37 +0000 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DMd4t-000D9K-8s for ccamp@ops.ietf.org; Sat, 16 Apr 2005 02:30:35 +0000 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 15 Apr 2005 22:40:49 -0400 X-IronPort-AV: i="3.92,106,1112587200"; d="scan'208"; a="44834227:sNHT24690758" Received: from zaliwxp (che-vpn-cluster-1-242.cisco.com [10.86.240.242]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3G2UVRQ018949; Fri, 15 Apr 2005 22:30:32 -0400 (EDT) Message-Id: <200504160230.j3G2UVRQ018949@rtp-core-1.cisco.com> From: "Zafar Ali" To: "'Kireeti Kompella'" , Subject: RE: Addressing doc Date: Fri, 15 Apr 2005 22:30:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20050415151514.K30910@kummer.juniper.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVCCgwZKHX05+v7SCSdOzTM5k6MJQAIiaig X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Friday, April 15, 2005 6:22 PM > To: ccamp@ops.ietf.org > Subject: Addressing doc > > A new version of this draft has been posted as > draft-shiomoto-ccamp-gmpls-addressing-01.txt . > > Please reply to this email on whether or not you think this > should be a CCAMP WG doc. Yes, Thanks Regards... Zafar >Adrian and I will gauge consensus > based on the mail received until Fri April 22, 23:59 UTC. > > Thanks, > Kireeti. > ------- > From owner-ccamp@ops.ietf.org Sat Apr 16 06:27:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10324 for ; Sat, 16 Apr 2005 06:27:32 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMkgr-0007Pj-U0 for ccamp-archive@ietf.org; Sat, 16 Apr 2005 06:38:19 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMkN9-00096J-MN for ccamp-data@psg.com; Sat, 16 Apr 2005 10:17:55 +0000 Received: from [80.168.70.141] (helo=relay1.mail.uk.clara.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DMkMz-00095P-Bm for ccamp@ops.ietf.org; Sat, 16 Apr 2005 10:17:45 +0000 Received: from du-203-30.nat.dialup.claranet.fr ([212.43.203.30] helo=Puppy) by relay1.mail.uk.clara.net with smtp (Exim 4.46) id 1DMkMx-0008GU-Gd for ccamp@ops.ietf.org; Sat, 16 Apr 2005 11:17:44 +0100 Message-ID: <049c01c5426d$cb102ab0$cdcb2bd4@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <148601c5361e$77d62990$dccb2bd4@Puppy> Subject: Re: Considering draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt as a WG draft Date: Sat, 16 Apr 2005 11:19:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit OK. No objections received. Authors, please submit as a WG draft with no changes. We will liaise this document to the ITU-T and hope to finish with it pretty soon. Thanks, Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Thursday, March 31, 2005 6:06 PM Subject: Considering draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt as a WG draft > Hi, > > This draft is the product of a DT set up by the WG so it is appropriate > that the draft become a WG draft. > > Please speak up now if you feel strongly against this. > > Thanks, > Adrian > > ----- Original Message ----- > From: > To: > Sent: Wednesday, March 23, 2005 10:10 PM > Subject: I-D ACTION:draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > > Title : Evaluation of existing Routing Protocols against > > ASON routing requirements > > Author(s) : J. Drake, et al. > > Filename : draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt > > Pages : 0 > > Date : 2005-3-23 > > > > The Generalized MPLS (GMPLS) suite of protocols has been defined to > > control different switching technologies as well as different > > applications. These include support for requesting TDM connections > > including SONET/SDH and Optical Transport Networks (OTNs). > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-dimitri-ccamp-gmpls-ason-routing-eval-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. After logging in, > > type "cd internet-drafts" and then > > "get draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > /internet-drafts/draft-dimitri-ccamp-gmpls-ason-routing-eval-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > ------------------------------------------------------------------------ -- > ------ > > > > _______________________________________________ > > 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 Sat Apr 16 08:18:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19298 for ; Sat, 16 Apr 2005 08:18:02 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMmPo-0003vS-6c for ccamp-archive@ietf.org; Sat, 16 Apr 2005 08:28:48 -0400 Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1DMm64-0000iQ-8u for ccamp-data@psg.com; Sat, 16 Apr 2005 12:08:24 +0000 Received: from [65.205.166.188] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1DMm63-0000i4-7X for ccamp@ops.ietf.org; Sat, 16 Apr 2005 12:08:23 +0000 Received: by jera.movaz.com (Postfix, from userid 30) id AAEBD1709; Sat, 16 Apr 2005 08:08:22 -0400 (EDT) Received: from 68.100.80.11 (SquirrelMail authenticated user ibryskin) by webmail.movaz.com with HTTP; Sat, 16 Apr 2005 08:08:22 -0400 (EDT) Message-ID: <3044.68.100.80.11.1113653302.squirrel@webmail.movaz.com> In-Reply-To: <20050415151514.K30910@kummer.juniper.net> References: <20050415151514.K30910@kummer.juniper.net> Date: Sat, 16 Apr 2005 08:08:22 -0400 (EDT) Subject: Re: Addressing doc From: ibryskin@movaz.com To: "Kireeti Kompella" 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 X-Priority: 3 Importance: Normal X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) 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.1 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 1.2 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 8bit > A new version of this draft has been posted as > draft-shiomoto-ccamp-gmpls-addressing-01.txt . > > Please reply to this email on whether or not you think this should be > a CCAMP WG doc. Adrian and I will gauge consensus based on the mail > received until Fri April 22, 23:59 UTC. > > Thanks, > Kireeti. > ------- > > Yes, Igor Bryskin